domingo, 27 de febrero de 2005

10 Tips para el Desarrollo de Aplicaciones Móviles (Parte 1)

En diferentes ocasiones he tenido la oportunidad de visitar clientes para conocer y opinar sobre diferentes aplicaciones móviles.

Independientemente de la funcionalidad específica de cada aplicación, la mayoría de estas visitas me hacen reflexionar sobre lo común que sigue siendo el diseñar soluciones móviles como si fueran una variante “chiquita” de aplicaciones en PC.

No tomar en cuenta las particularidades de una solución móvil desde su diseño puede provocar con facilidad que una buena idea de negocios no dé los resultados esperados. Por esta razón, decidí escribir esta lista de 10 tips a considerar para compartir algunos elementos de nuestra experiencia. Esta semana publico los primeros 5:

1. Conoce la Operación en el Ambiente Real

Esto es indispensable. Hay que “ensuciarse las manos”. Mientras más alejado está un elemento de operación de las oficinas centrales de una empresa, más variantes vas a encontrar entre la forma como los jefes dicen que funcionan las cosas y la realidad. Cliente tras cliente nos hemos encontrado con esto. El personal de campo siempre va a descubrir formas de optimizar su trabajo de acuerdo con sus objetivos específicos y es indispensable entender esto. Tómalo en cuanta para tu aplicación cuando tenga sentido de negocio y oponte firmemente a diseñar una aplicación de alguna forma sólo porque el jefe dice que así debe ser. Súbete a la camioneta, sal a caminar con él, pregunta de todo y analiza que está pasando. Debate tus opciones con el dueño de tu presupuesto y llega a acuerdos que permitan que cuando salga al campo tu aplicación realmente de el beneficio de negocio esperado.

La mayor parte de los procesos en campo se dan con estrictas limitaciones de tiempo ya que las empresas (en la mayoría de los casos con razón) relacionan el número de visitas realizadas con el nivel de productividad de su personal en campo. Entiende y conoce las “mañas” que se desarrollan para ahorrar tiempo o simplificar el trabajo. Busca una forma de que tu aplicación le agregue valor y/o le simplifique el trabajo al personal que la va a operar. De otra manera la resistencia al cambio cuando sea momento de desplegar va a ser mucho mayor.


2. Estudia la Plataforma que vas a usar y sus Capacidades

El desarrollo para dispositivos móviles es cada vez más fácil. Las herramientas de software convergen con las de escritorio. Hoy puedes usar Visual Studio 2003 y trabajar en C# o en VB.NET para dispositivos móviles. En Visual Studio 2005 lo podrás hacer también con C++.

Sin embargo, a veces esto puede ser una trampa. Nos venden la idea de que podemos empezar a trabajar en dispositivos móviles sin ningún esfuerzo. No es así. Es necesario tomarse el tiempo para estudiar las diferencias entre la plataforma de escritorio y la móvil. Así diseñarás mejor y te ahorrarás mucho tiempo después (“es que ya vi que el Compact Framework no trae el XML Serializer y me estoy atrasando…”)

Por ejemplo, ¿sabías que si escribes una función que al compilarse mida más de 64K en el Compact Framework te va a provocar una falla general de protección de memoria (GPF)? ¿piensas que sólo un loco escribiría una función tan grande? ¿has pensado que ese loco puedes no ser tú, sino el diseñador de formas de Visual Studio 2003?

La misma idea aplica en otras plataformas de desarrollo móvil como J2EE vs. JME.

3. Planea la Sincronización de Datos

La gran mayoría de las aplicaciones móviles para corporativos son extensiones de sistemas existentes. Aplicaciones de ventas, CRM, mantenimiento, servicio, etc. Todas deben conectarse a sistemas centrales y sincronizar la información.

¿Está la información disponible? Verifica como la vas a extraer/depositar en sistemas centrales. Checa si los datos que extraes son validos. ¿Necesitan alguna limpieza? ¿Hay alguien que sabe como sacar la información? ¿Está documentado o tenemos que hablarle al experto que hizo el sistema original en RPG?

Combina bien la sincronización planeada con las capacidades de los sistemas de negocio. ¿O vas a poner pedidos en línea vía GPRS para que se suban en batch diariamente al ERP?

El tema de sincronización da para varios artículos completos. Asegúrate de investigar, planear y probar el desempeño. Hazlo fácil para tu usuario. Que tu meta siempre sea que para el usuario se transparente; que no tenga que hacer nada. Si, nada. No, apretar un botón no es nada. NADA.


4. Diseña una Interfaz Adecuada para Dispositivos Móviles

Este punto parece sencillo pero no lo es tanto. La mayoría de nosotros estamos acostumbrados a desarrollar para una PC, cada vez con mayor espacio en la pantalla para presentar nuestra interfaz y con los usuales dispositivos de entrada: teclado, mouse, etc. La primera reacción ante las limitaciones de un dispositivo móvil (Como una PDA) suele ser intentar hacer lo mismo pero “en chiquito”. Esto puede provocar serios problemas. ¿Han intentado atinarle a la flecha de scrolling en una PocketPC? ¿Qué tal capturar un texto largo? Es indispensable pensar diferente cuando trabajamos en estas aplicaciones y una buena forma de hacerlo es intentar usar nuestra propia PDA cada vez más para actividades de nuestra vida diaria y preguntarnos continuamente ¿Cómo podrían haber hecho esta aplicación más fácil de usar?

Algunos lineamientos generales son: minimiza la captura, piensa como la usarías si se te pierde la pluma, simplifica la navegación, estudia los controles gráficos especiales para PDA y sácales provecho, muestra sólo la información realmente indispensable, y trata de integrarte cuando haga sentido con las aplicaciones de la PDA con las que el usuario ya está familiarizado como el calendario o el cliente de correo electrónico.


5. Piensa en el Soporte a tu Aplicación Móvil

“Ya desplegamos nuestra aplicación móvil y estamos vendiendo a través de ella. Es una maravilla tecnológica y acabamos el proyecto antes del tiempo planeado, la primera vez que usamos el .NET Compact Framework 2.0. Tenemos 150 vendedores en todo el país. Todo es felicidad. Vamos a sacar una nueva versión con varias mejoras. Para desplegarla mandamos un mail a todas nuestras sucursales con la nueva versión. Total, ya entrenamos a nuestro personal de soporte en todos lados y saben instalar la nueva versión. LOL. Nos tardamos 15 días en instalar la nueva versión. Y un mes en el caso de la sucursal de Tijuana que se resuelve hasta que mandamos a alguien en avión a hacerlo. Bueno, no importa, valió la pena; la nueva versión funciona bien, todo mundo feliz porque las ventas van en aumento. Es el día primero de Abril. Ehem, la aplicación truena porque tiene una pequeña falla que solo se manifiesta cuando la fecha es el día primero de mes y no probamos ese escenario. No se alarmen, es una línea de código. Ya está. Toda la fuerza de ventas deja de hacer pedidos y los captura a mano. Los clientes cancelan. Le decimos al Director Comercial que ya dominamos el proceso de despliegue y esta vez nos tardaremos cuando mucho dos semanas en actualizar todo. Nos invita a pasar a recursos humanos por nuestra liquidación.”

Evita repetir esta historia. No es fácil actualizar dispositivos dispersos por todos lados. Desarrolla un mecanismo automatizado de actualización y soporte o mejor aún, evalúa una opción existente que se adapte a tus necesidades. Support Everywhere es un ejemplo que podría funcionar para ti.

miércoles, 16 de febrero de 2005

Plática de “Visual Studio Tools for the Microsoft Office System” (VSTO)

Hoy tuve el honor de dar una sencilla plática sobre este tema en la reunión mensual del grupo de usuarios de MSDN en la Ciudad de México. Puedes bajar las láminas de la presentación y el demo principal de el sitio web de emLink.

El demo utiliza un web service que apunta a la base de datos demo de SQL Server de Northwind. Para que funcione tienes que configurar el web service (VSTODemoService) para que apunte a un SQL Server válido.

¿De que se trata todo esto?

“Visual Studio Tools for the Microsoft Office System” (VSTO en lo sucesivo) es una herramienta interesante que extiende el Visual Studio .NET 2003 para permitirme desarrollar aplicaciones .NET que aprovechan la funcionalidad de Office 2003.

¿Qué requiero?

Microsoft Office 2003

Visual Studio .NET 2003

VSTO (OMG, hasta hace 10 mins. tenía entendido que era gratis pero al buscar la liga de download ¡encuentro que tiene costo!)

¿Cuándo vale la pena usarlo para desarrollar?

Cuando voy a desarrollar una aplicación cliente o “front-end” donde se dan una o más de estas condiciones:

  1. Requiero integrar datos de negocio a documentos de Word o Excel.
  2. Quiero aprovechar el conocimiento que ya tienen mis usuarios de Office para reducir el costo de entrenamiento y soporte.
  3. Quiero aprovechar la funcionalidad de Excel ó Word para ser más productivo en mi desarrollo.

¿Cuáles son las ventajas de esta opción sobre otras opciones disponibles anteriormente como Visual Basic para Aplicaciones?

  1. Puedes trabajar en C# o VB.NET dentro de VS 2003 aprovechando todo el poder y las ventajas del .NET Framework en general.
  2. Cuentas con un modelo de despliegue mucho mejor que el de VBA ya que puedes desplegar por separado el documento y el código.
  3. La seguridad es mucho más robusta y flexible porque se basa en el modelo CAS del framework.
  4. Estás trabajando dentro de la plataforma “oficial” hacia delante para hacer soluciones profesionales para Office y te será fácil sacarle ventaja a la versión 2005 que se liberará próximamente.

Puedes encontrar mucho más información en el sitio de Microsoft aquí.

jueves, 10 de febrero de 2005

Amor a la Programación

Amo programar. Me encanta el mundo simbólico y lógico de la computadora. Tener una máquina que te obedece. Es divertido, ¿no?

Es sin duda una actividad creativa. Además de que siempre encuentras mil formas diferentes de hacer algo. Para mi programar es jugar. Es una experiencia personal entre la máquina y yo.

Aún cuando en mi vida en diferentes ocasiones me he obsesionado con algún videojuego, la idea de los juegos en "linea" me ha costado asimilarla. Yo usaba la computadora para aislarme en un mundo personal y ahora la computadora es más que nada una herramienta de comunicación, ¿no?

¿Y los nerds?

LOL