Descarga la aplicación para disfrutar aún más
Vista previa del material en texto
Universidad Nacional Autónoma de México Facultad de Ingeniería “Guía de Referencia para el Desarrollo y Distribución de Software en Plataformas Móviles” Tesis Profesional que para obtener el título de Ingeniero en Computación presenta: Héctor Zárate Rea Asesora: Laura Sandoval Montaño Ciudad de México, Septiembre de 2010. UNAM – Dirección General de Bibliotecas Tesis Digitales Restricciones de uso DERECHOS RESERVADOS © PROHIBIDA SU REPRODUCCIÓN TOTAL O PARCIAL Todo el material contenido en esta tesis esta protegido por la Ley Federal del Derecho de Autor (LFDA) de los Estados Unidos Mexicanos (México). El uso de imágenes, fragmentos de videos, y demás material que sea objeto de protección de los derechos de autor, será exclusivamente para fines educativos e informativos y deberá citar la fuente donde la obtuvo mencionando el autor o autores. Cualquier uso distinto como el lucro, reproducción, edición o modificación, será perseguido y sancionado por el respectivo titular de los Derechos de Autor. Agradecimientos A las personas que inventaron y han hecho posible: Y por supuesto, a mi padre, a la maestra Laura Sandoval, a Flor Aguilar y a todas las personas increíbles que han estado cerca de mi y que me han apoyado: mis amigos. :) Héctor Zárate Rea Licencia Una guía de referencia sería de poca utilidad si encontrarla, consultarla y distribuirla fuera difícil. Lamentaría que este fuera el caso. Guía de Referencia para el Desarrollo y Distribución de Software en Plataformas Móviles by Héctor Zárate Rea is licensed under a Creative Commons Attribution-NonCom- mercial-ShareAlike 2.5 Mexico License. http://creativecommons.org/licenses/by-nc-sa/2.5/mx/ http://creativecommons.org/licenses/by-nc-sa/2.5/mx/ http://creativecommons.org/licenses/by-nc-sa/2.5/mx/ http://creativecommons.org/licenses/by-nc-sa/2.5/mx/ Tabla de Contenidos Introducción 1 La Visión de un Producto de Software 1 Más allá del bit y del byte 2 Advertencia 3 Objetivo 4 Desarrollar un Producto 5 Sobre la Ingeniería en general 5 El Proceso de Diseño en la Ingeniería 6 La tarea del software 7 Dispositivos Móviles 8 Nuevas Plataformas Móviles, Distribución y el Contexto Actual 9 Android 11 iOS 12 Blackberry 13 Hacer un Producto de Software Valioso 15 Planeación 16 Planeación 16 Scrum 18 Roles Importantes dentro de Scrum 19 El Ciclo Scrum 20 Planeación y Bitácora del Producto 20 2. Iteraciones (Sprints) 20 3. Juntas Diarias (¡pfff!) 20 Demostraciones 21 5. Retrospectiva 21 Algunas Buenas Prácticas para Cada Iteración 22 Claridad en el Código 22 Comentar el Código 22 Wikis 23 Respaldos de Seguridad 23 Control de Versiones 24 Tips de Verificación y Validación para cada iteración 25 Probar la aplicación en dispositivos físicos 26 Usuarios ßeta 26 Errores Fatales 26 Verificar la interfaz de usuario 27 Verificar problemas de conectividad 27 Interfaces de Usuario 28 Pasos para Crear una Interfaz de Usuario 29 Arte y Diseño Gráfico 30 Elementos de Diseño en las Interfaces de Usuario 30 Color 31 Tipografía 31 Imágenes 32 Distribución y Agrupación 33 Sonidos 33 Principios Básicos para el Diseño de Interfaces 34 Internacionalización y Localización 35 Accesibilidad 37 Consideraciones Particulares para Plataformas Móviles 37 Pantallas Pequeñas 38 Menos Memoria y Menores Capacidades de Procesamiento 38 Batería 38 Conexiones Costosas 39 Servicios de Posicionamiento 39 Gestos y Nuevas Formas de Interacción 39 Ayuda Mínima 40 Duración de la Interacción 40 Interacción Individual con las Aplicaciones 40 Integración con el Sistema del Dispositivo 41 Medir Resultados: Tests de Usabilidad 41 ¿Qué esperar de una buena interfaz? 43 Marketing 44 1. Conocer a la audiencia 45 2. Elementos Importantes de Marketing Dentro de la Aplicación 46 Nombre de la Aplicación 47 Look’n Feel 48 Ícono 48 Pantalla Splash 49 Actualizaciones 50 3. Elementos de Marketing dentro de la Tienda Electrónica: 51 Screen-shots 51 Copy (Descripción) 52 Categoría 54 Precio 56 4. Tener un sitio web para el producto 58 Información indispensable del sitio 58 Algunas Estrategias de SEO 59 5. Mantenerse en Comunicación 60 Blog 61 Redes Sociales 62 Facebook 63 Twitter 64 5. Hacer una Marca 65 ¿Qué es una Marca? 66 Registro de una marca en México 67 Estudios de Caso 70 Ubícate! 70 Inventando el Producto 70 Fijar las necesidades del consumidor 70 2. Definir el conjunto de acciones que el artefacto de software hará 71 Determinar funciones específicas 71 Planeación del Producto 77 Interfaces de Usuario 78 Proponer la Presentación y Asignar Acciones 78 Marketing 82 Website 83 Publicación 84 Recepción y Resultados 84 Historial de Actualizaciones85 Conclusiones 86 Glosario 88 Bibliografía 90 / Introducción1 “Ladies and Gentlemen please take your seats. The show is about to begin.” - ? La Visión de un Producto de Software La producción de software2 en México es generalmente hecha bajo la demanda de un cliente que solicita una solución específica para un problema específico. Resultando generalmente en software que una empresa utilizará para su operación. Esta práctica, la producción de software "In-House", ha sumergido al ingeniero en computa- ción mexicano en un trabajo técnico de limitada creatividad donde adapta e implementa solu- ciones existentes para resolver un listado de requisitos de un cliente. Este tipo de trabajo, concentrado en resolver un set de problemas de un cliente en particular, no ofrece la oportunidad de hacer un software tan refinado y atractivo porque este tipo de ca- racterísticas no son costeables3. Aunque es una actividad redituable, la mayoría de las veces se limita a perseguir el cumplimiento y aprobación de los requerimientos mínimos acordados con el cliente. En contraste, un producto de software comercial, disponible a usuarios finales en el mercado, requiere un esfuerzo continuo de innovación y creatividad los cuales impactarán directamente a los usuarios, traduciéndose directamente en su satisfacción y a su vez generando más ventas. 1 1 Toda la vida me he preguntado si en verdad hay alguien leyendo los capítulos introductorios de los libros. 2 Software es un término completamente válido en la lengua española y aparece en el Diccionario de la Real Academia Española (RAE) vigésimo segunda edición. Aunque puede sustituirse por expresiones españolas como “programas in- formáticos” esto es tan alienante como decir “pantaloncillos cortos” en lugar de “shorts”. Los anglicismos que aún no están contemplados en la RAE son incluidos en un glosario y son escritos en cursivas. 3 Spolsky, Joel. “Yale Talk” en More Joel on Software. Estados Unidos: Apress, 2008. Pero hacer un producto de software en México era una tarea prácticamente imposible y una visión ajena a muchos desarrolladores. Hacer un producto requería de una infraestructura im- portante para realizar la distribución física de los productos o en el caso de optar por una dis- tribución en línea, los trámites para aceptar pagos con tarjetas de crédito, las medidas anti-pi- ratería y la infraestructura tecnológica para hacer la entrega virtual del producto eran una su- matoria de obstáculos suficientemente grande como para hacer desistir a cualquiera. Pero en los últimos años, junto con los dispositivos móviles, aparecieron nuevas plataformas que resolvieron todos los problemas anteriores; revolucionando por completo algunos escena- rios adversos como el caso de México. Esto ha abierto nuevas posibilidades para el ingeniero, pero al mismo tiempo lo hace enfrentarse a nuevos retos de los que tiene que ser consciente y que a primera vista, podrían parecer de poca incumbencia para la ingeniería. Más allá del bit y del byte Esta tesis tiene la intención de ser un estudio útil para una creciente comunidad de universitarios y personas de habla hispana que quieren incursionar en el desarrollo de aplicaciones móviles. Pero su análisis no está centrado en “el bit y el byte”, sino en presentar el conjunto de prácti- cas determinantes para obtener un producto de software exitoso en el mercado y crear cons- ciencia acerca del deber de invención de la Ingeniería. Se ha dividido en 5 capítulos que pueden o no ser leídos consecutivamente. De hecho, el lector con déficit de atención (o meramente cansado de la linealidad) es libre de consultar cualquier capítulo aleatoriamente o de hojear el libro para leer solamente los párrafos con las imágenes más interesantes. Los capítulos son los siguientes: 1. Desarrollar un Producto Una excursión teórica acerca de la ingeniería, su tarea, el proceso de invención, el contexto del cómputo móvil y las plataformas actuales. 2. Planeación Descripción de una metodología ágil para la planeación de un proyecto y algunas buenas prácticas. 2 3. Interfaces de Usuario Uno de los elementos más importantes en la comercialización de un producto. Se mencio- nan consideraciones particulares de los dispositivos móviles, sus elementos, una metodolo- gía para proponer interfaces y una metodología para verificarlas. 4. Marketing Estrategias básicas para lograr la exposición de la aplicación y alcanzar a los compradores. 5. Casos de Estudio ¿Cómo aplicar realmente el contenido de este trabajo? Se estudia un caso de éxito que ha implementado la mayoría de las prácticas aquí mencionadas. Advertencia Ante la convención, podría parecer un texto sobrado de humor e iconografía, pero esto no es arbitrario, se ha hecho con la intención de que sea un trabajo consumible por una comunidad que requiere textos prácticos, directos y cercanos a ella. De cualquier forma, la academia en- contrará descanso en saber que la investigación fue tan cuidadosa y formal como en la tesis más notable y aburrida del acervo. Así que sin más preámbulos, “Guía de referencia para el desarrollo y distribución de software en plataformas móviles”. 3 / Objetivo Analizar las prácticas que constituyen una aplicación exitosa dentro de los escaparates virtua- les de las plataformas móviles y presentar a la Comunidad Universitaria una guía de referencia que contenga información clave para el desarrollo y distribución exitosos de un producto de software comercial dentro de estas nuevas plataformas . 4 / Desarrollar un Producto “An amazing invention - but who would ever want to use one?” - Rutherford B. Hayes Sobre la Ingeniería en general La ingeniería es un conjunto de actividades metódicas, científicas y conscientes basadas en la apreciación y aplicación de las ciencias, la experiencia y la técni- ca. Estas actividades se orientan a crear herramientas y adaptar el entorno del ser humano para su bienestar y comodidad, pero ocurren determinadas por el contexto socio-político en el que se llevan a cabo. Varios resultados de la ingeniería como estructuras, máquinas, aparatos o nuevos procesos (hardware, reglas y sistemas4) pueden ser llamados tecnología, la cual a su vez, puede definirse como el arte y conocimiento de “hacer las cosas”5. Un proce- so en parte ciencia y en parte arte, llevado a cabo dentro de los márgenes del método y la exactitud, pero acompañada de ingenio, creatividad e innovación. Dentro de esta invención deliberada se producen artefactos tecnológicos orientados a que las personas extiendan sus capacidades físicas naturales y así, satisfagan necesidades prácticas, logren objetivos concretos y (en el mejor de los casos) mejoren su calidad de vida. Estos artefactos son objetos físicos hecho por humanos para otros humanos, que tienen una función particular y están acompañados de un plan de uso. En una definición más extendida y actualizada, son objetos (ya no necesariamente físicos, pudiendo ser también abstracciones) muchas veces inconcebidos que tienen un propósito de uso, una descripción bien definida de su estructura compositiva e instrucciones acerca de cómo usarlos. 5 4 Dusek, Val. Philosophy of technology: an introduction. Reino Unido: Blackwell Publishing. 2006. Páginas 31-33. 5 Bird, Michael S. Art and interreligious dialogue: six perspectives. Estados Unidos: University Press of America. 1995. Pagina 60. El Proceso de Diseño en la Ingeniería La ingeniería concibe estos artefactos en un proceso conocido como “diseño”, varias actividades metódicas y sistemáticas para crear cosas nuevas y que en contraste con los esfuerzos hechos por la investigación científica, requieren ser una tarea plau- sible: con un pronóstico claro de éxito y con certidumbre acerca de la dura- ción y el costo que representará, acotaciones insalvables y presentes en cualquier proyecto de diseño para la ingeniería. Este proceso desdeuna perspectiva general consta de 5 etapas, al final de las cuales el artefacto será, además, un objeto disponible a la compra con un ciclo de vida en el mercado. Es decir, un “producto”. 1. Convertir necesidades en funciones. 2. Convertir las funciones en descripciones específicas. 3. Llevar a cabo la construcción de un artefacto según las descripciones propuestas. 4. Probar el artefacto. 5. Producir el artefacto (prototipo) en una escala masiva6. Hasta este punto, debería tenerse un producto que presente una solución a algún problema real y que al utilizarlo para esta tarea, hiciera la vida de quien lo use (el usuario) más productiva, saludable o feliz. No obstante, hacer un gran producto sería inútil sin consumidores que costearan su desarrollo: hoy en día el diseño de producto debe contemplar también la forma de conseguir y mantener esos consumidores, tarea que es conocida como marketing. 6 6 Este paso es la diferencia entre un prototipo y un producto. Koren, Yoram. The Global Manufacturing Revolution: Product-Process-Business Integration and Reconfigurable Systems. Estados Unidos: John Wiley and Sons. 2010. Página 5-6. La tarea del software El software es precisamente un artefacto que ha adquirido gran importancia para la sociedad y que hoy se utiliza en forma masiva para mejorar la calidad de vida y soportar actividades como el trabajo, la transportación y el entrete- nimiento. En teléfonos, automóviles, Furbys7, aviones y línea blanca entre otras cosas, el software es virtualmente omnipresente en la vida moderna. Pero decir que el software es una herramienta que simplifica las tareas del hombre es ahora una definición insuficiente. Se ha convertido en un componente de la socie- dad que, más allá de contribuir aisladamente, está transformando todas las actividades de ella como la política, la economía, los negocios, la comunicación y la socialización8. La transforma- ción que está efectuando en la sociedad es tan profunda, que podría ser comparada con la re- volución industrial en el siglo XVIII y XIX. ¿Y qué es exactamente el software? El software puede ser visto como una maquinaria virtual construida mediante instrucciones en un lenguaje formal de computadora para ser ejecutadas por otras computadoras. Esencialmente se divide en dos categorías: software de aplicación (aplicaciones) que sirve para hacer tareas útiles y software operativo, el cual está encargado de la operación misma de la computadora donde se ejecuta. La primera categoría, las aplicaciones, tienen un valor importante y directo para el usuario por- que éstas determinan cómo realizará determinadas tareas. Por lo que el reto más importante de desarrollar una aplicación hoy, no está en el aspecto técnico, sino en proveerle a los usua- rios herramientas significativas para ellos. 7 7 Thrift, N. J. Knowing capitalism. India: SAGE. 2005. Páginas 190-191. 8 Barkhuus, Louise. Student Socialization in the Age of Facebook. Universidad de California, San Diego. 2010. Dispositivos Móviles Los dispositivos móviles de hoy como teléfonos, tablets o iPods son el último capítulo de una larga historia de distintas tecnologías que han convergido para otorgar movilidad física a los entornos computacionales. A cambio de otorgarle al usuario la posibilidad de movilidad física, estos dispositivos tienen interfaces de entrada menos cómodas, pantallas pequeñas y menores presta- ciones de hardware, pero esto no debe hacer pensar que su potencial es por de facto me- nor al de una computadora de escritorio. Muy al contrario, su portabilidad, duración de la batería, servicios de posicionamiento y capacidad de comunicación y conectividad los hacen más podero- sos y adecuados para ciertas tareas que cualquier computadora portátil o de escritorio. Existe una clara tendencia de que el uso de la computación se está inclinando hacia el uso de estos dispositivos móviles: el mercado de las computadoras móviles ha continuado creciendo significativamente en los últimos años9, al grado de sobrepasar las ventas de computadoras de escritorio10; 3 de cada 4 personas en el mundo utilizan la telefonía celular11, superando la pro- porción del 33% de personas que tienen acceso a internet; su uso y capacidades son cada vez más parecidos al de una computadora de escritorio; y en internet hay cada vez más teléfonos conectados12, con un pronóstico que apunta a que estos superen a las computadoras de escri- torio y laptops en poco tiempo. 8 9 Wauters, Robin. Smartphones Lead Global Mobile Market to 20% Growth in Q1. Seeking Alpha. 29 de Abril de 2011. Consultado el 5 de Mayo de 2011. <http://seekingalpha.com/article/266539-smartphones-lead-global-mobile-market-to-20-growth-in-q1> 10 Arthur, Charles. Android dominance of worldwide smartphone sales goes on, says Canalys. guardian.co.uk. Consulta- do el 5 de Mayo de 2011. <http://www.guardian.co.uk/technology/blog/2011/may/04/android-smartphone-worldwide-dominates> 11 Internet and mobile phone usage data published by UN. Royal Statistical Society eNEWS. 1ero. de Febrero de 2009. Consultado el 5 de Mayo de 2011. <http://www.rssenews.org.uk/articles/20110131_2> 12 Ingram, Mathew. Mary Meeker: Mobile Internet Will Soon Overtake Fixed Internet. GigaOm - Tech News and Analysis. 12 de Abril de 2010. Consultado el 5 de Mayo de 2011. <http://gigaom.com/2010/04/12/mary-meeker-mobile-internet-will-soon-overtake-fixed-internet/> http://seekingalpha.com/article/266539-smartphones-lead-global-mobile-market-to-20-growth-in-q1 http://seekingalpha.com/article/266539-smartphones-lead-global-mobile-market-to-20-growth-in-q1 http://www.guardian.co.uk/technology/blog/2011/may/04/android-smartphone-worldwide-dominates http://www.guardian.co.uk/technology/blog/2011/may/04/android-smartphone-worldwide-dominates http://www.rssenews.org.uk/articles/20110131_2 http://www.rssenews.org.uk/articles/20110131_2 http://gigaom.com/2010/04/12/mary-meeker-mobile-internet-will-soon-overtake-fixed-internet/ http://gigaom.com/2010/04/12/mary-meeker-mobile-internet-will-soon-overtake-fixed-internet/ Nuevas Plataformas Móviles, Distribución y el Contexto Actual El 11 de Julio de 200813 Apple inauguró el “App Store”. Una tienda virtual disponible des- de cualquier dispositivo iPhone, iPod Touch o iPad en la cual se puede descargar soft- ware para estos dispositivos de una forma muy sencilla. Este nuevo escaparate electrónico y su programa de desarrollo, le dio a todos los desarrolladores de software una forma más simple de crear aplicaciones innovado- ras y de distribuirlas a un nivel global sin preocuparse por aspectos como la imple- mentación de números de serie o la forma de distribución y pago. Esto posibilitó a un grupo particular y de interés en este trabajo, desarrolladores individuales o grupos de desarrollo muy pequeños, con la oportunidad de comercializar un producto de software ante usuarios finales: desde tener una idea, hasta hacer llegar su última y más refinada versión a millones de usuarios. Esta nueva tendencia presentó un éxito inimaginable, reportando ventas de 1.5 mil millones14 de des- cargas en su primer año. Naturalmente, varias compañías replicaron el modelo. Entre ellas estuvieron Android Market para Android (Octubre de 200815), App World de RIM (1ero. de Abril de 200916), Nokia con Ovi Store (26 de Mayo de 200917) y App Catalog de Palm (6 de Junio de 200918). Al respecto, el dominio del mercado para cada plataforma en Estados Unidos19: 9 13 Quinn, Michelle. Apple: App Store still coming July 11. CNET News . 11 de Junio de 2008. Consultado el 2 de Mayo de 2011. <http://news.cnet.com/8301-13579_3-9966086-37.html> 14 Antony, Bruno. “Change In The Air”. Billboard, Agosto 15 de 2009. 15 Horn, Leslie. Want Free Apps? Try the Android Market. PC Mag. 28 de Abril de 2011. Consultado el 2 de Mayo de 2011. <http://www.pcmag.com/article2/0,2817,2384594,00.asp> 16 Patel,Nilay. BlackBerry App World to launch April 1, says BusinessWeek. Engadget.26 de Marzo de 2009. Consultado el 2 de Mayo de 2011. <http://www.engadget.com/2009/03/26/blackberry-app-world-to-launch-april-1-says-businessweek/> 17 Eric. Update on Ovi Store opening. Ovi by Nokia - Blog. 26 de Mayo de 2009. Consultado el 2 de Mayo de 2011. <http://blog.ovi.com/2009/05/26/update-on-ovi-store-opening/> 18 Barletta, Bryan. Palm Pre App Catalog Reaches 1 Million Downloads. Medialets. 24 de Junio de 2008. Consultado el 2 de Mayo de 2011. <http://www.medialets.com/palm-pre-app-catalog-reaches-1-million-downloads> 19 Arthur, Charles. Nokia and RIM bleeding smartphone share while Android cleans up. guardian.co.uk . 18 de Abril de 2011. Consultado el 29 de Abril de 2011. <http://www.guardian.co.uk/technology/2011/apr/18/smartphone-market-android-win-nokia-rim-lose> http://news.cnet.com/8301-13579_3-9966086-37.html http://news.cnet.com/8301-13579_3-9966086-37.html http://www.pcmag.com/article2/0,2817,2384594,00.asp http://www.pcmag.com/article2/0,2817,2384594,00.asp http://www.engadget.com/2009/03/26/blackberry-app-world-to-launch-april-1-says-businessweek/ http://www.engadget.com/2009/03/26/blackberry-app-world-to-launch-april-1-says-businessweek/ http://blog.ovi.com/2009/05/26/update-on-ovi-store-opening/ http://blog.ovi.com/2009/05/26/update-on-ovi-store-opening/ http://www.medialets.com/palm-pre-app-catalog-reaches-1-million-downloads http://www.medialets.com/palm-pre-app-catalog-reaches-1-million-downloads http://www.guardian.co.uk/technology/2011/apr/18/smartphone-market-android-win-nokia-rim-lose http://www.guardian.co.uk/technology/2011/apr/18/smartphone-market-android-win-nokia-rim-lose Figura 1: Dominio del mercado de smartphones por sistema operativo Esta información revela que las plataformas más importantes hoy en día son Android, iOS de Apple y los dispositivos Blackberry de RIM; aunque para un país en desarrollo como México, estas cifras son ligeramente distintas: los dispositivos de gama baja (como los producidos por Nokia) tendrán un mayor dominio del mercado por su menor costo. A continuación se analizarán brevemente las tres plataformas más representativas por su im- portancia en el mercado: Android iOS RIM Symbian Windows Otros 1%5%1% 11% 27% 55% 10 Android Android es un set de software open-source basado en Java que opera en un kernel de Linux. Este incluye un sistema operativo, middleware y otras apli- caciones. La programación de aplicaciones se realiza en Java (utilizando preferentemente Eclipse) y aunque las interfaces pueden definirse también en Java, pueden definirse en XML utilizando herramientas más cómodas. Los componentes de una aplicación son: • Actividades Análogas a ventanas y diálogos. • Proveedores de Contenido Abstracciones para generar, acceder y disponer de data en las aplicaciones, información que puede ser contenida entre aplicaciones. • Servicios Aplicaciones que no tienen un ciclo de vida corto y finito, sino que continúan ejecutándose en el background independientemente de otras actividades. • Intentos (Intents) Notificaciones internas que avisan a las aplicaciones de cambios de estado del hardware o "mensajes" enviados por otras aplicaciones. Como una característica especial, las aplicaciones de terceros se ejecutan con la misma priori- dad que los procesos del sistema, y todas las aplicaciones pueden tener acceso a los mismos recursos de los que dispone el sistema operativo. Como recursos comunes se tiene almacenamiento, conectividad a internet, multimedia (imáge- nes, audio y video), servicios de posicionamiento (GPS) y telefonía. Ya que hay distintos fabri- 11 cantes produciendo dispositivos con Android (los más importantes20: Motorola, HTC y Samsung), sus características de hardware (velocidad del procesador, tamaño de la pantalla, etc.) pueden variar enormemente entre cada dispositivo. El canal oficial para a distribución y venta de aplicaciones es Android Market. iOS iOS es el sistema operativo basado en Darwin con el que cuentan los dispositivos móviles comercializados por Apple. El primer dispositivo de este sistema operativo fue el iPhone, puesto a la venta el 29 de Junio de 200721. Tras este primer dispositivo continuaron nuevas ge- neraciones, otro dispositivo idéntico en su funcionalidad exceptuando el teléfo- no y la localización GPS, iPod Touch y más recientemente una tablet llamada iPad. Los recursos físicos con los que cuentan estos dispositivos son acelerómetros, cámaras, servi- cios de posicionamiento, pantalla táctil (todos), multimedia y telefonía. El desarrollo sobre esta aplicación se hace en el lenguaje Objective-C. Las herramientas de de- sarrollo son gratuitas, pero para la publicación de una aplicación, el desarrollador necesita rea- lizar un proceso de registro y el pago de una cuota. Antes de su publicación, todas las aplica- ciones son revisadas personalmente y evaluadas en términos de usabilidad y desempeño. Una de las ventajas de la plataforma iOS (iPhone, iPod Touch y iPad) es la poca segmentación que hay entre dispositivos, con lo que se evita tener que considerar distintos tamaños de pan- talla o diferencias sustanciales en el hardware. 12 20 Warren, Christina. Motorola Droid Is Android’s Dominant Device [STATS]. Mashable. 27 de Abril de 2011. Consultado el 2 de Mayo de 2011. <http://mashable.com/2010/04/27/admob-stats-march-2010/> 21 Block, Ryan. iPhone release date confirmed: yours on June 29th. Engadget. 3 de Junio de 2007. Consultado el 30 de Abril de 2011. <http://www.engadget.com/2007/06/03/iphone-release-date-confirmed-yours-on-june-29th/> http://mashable.com/2010/04/27/admob-stats-march-2010/ http://mashable.com/2010/04/27/admob-stats-march-2010/ http://www.engadget.com/2007/06/03/iphone-release-date-confirmed-yours-on-june-29th/ http://www.engadget.com/2007/06/03/iphone-release-date-confirmed-yours-on-june-29th/ La venta y distribución de aplicaciones se hace a través del Apple Store, la cual gestiona todo el proceso de compra, instalación y actualización de las aplicaciones. El pago en esta tienda puede hacerse con tarjetas de crédito o con tarjetas prepagadas que se venden en tiendas de servicio. Apple anunció en su reporte financiero del segundo cuarto de 2011 que había vendido un total acumulado de 189 millones22 de dispositivos con el sistema iOS. Blackberry Blackberry es una línea de smartphones comercializada por la compañía canadiense Research in Motion (RIM). El nicho de mercado de estos dispositivos es el sector em- presarial23, aunque desde el lanzamiento del modelo Pearl 8100 está inten- tando tener una mayor penetración en el mercado de consumo24. Aunque son hechos por un mismo fabricante, las características físicas de los dispositivos son variables: tamaño y resolución de pantalla, si es táctil o no, disposición del teclado físico, velo- cidad del procesador, memoria, velocidad de la conexión a internet y el sistema operativo, también es diferente entre cada uno, pudiendo existir diferencias considerables. Las plataforma de desarrollo para los smartphones Blackberry es Java, pudiendo usar varios IDE’s como Eclipse o NetBeans. La distribución y venta de las aplicaciones se hace en la tienda App World, desde el explorador del dispositivo o desde una aplicación de escritorio especial. Después de evaluar estas 3 plataformas, el estudio de esta guía de referencia será enfocado hacia la plataforma iOS por ser una plataforma innovadora, fácil de usar y de gran potencial. 13 22 Jordan, Jon. Apple has sold a total of 189 million iOS devices. Pocket Gamer. 20 de Abril de 2011. Consultado el 30 de Abril de 2011. <http://www.pocketgamer.co.uk/r/Various/Apple+news/news.asp?c=29297> 23 McIntyre, Douglas. Is BlackBerry Maker RIM Ripe for a Rebound? Daily Finance. 5 de Febrero de 2011. Consultado el 2 de Mayo de 2011. <http://www.dailyfinance.com/2011/05/02/blackberry-rim-research-in-motion-stock-shares-rebound-outlook/> 24 Wargo, John. BlackBerry Development Fundalmentals.Estados Unidos: Addison-Wesley Proffesional. 2009. Página 4. http://www.pocketgamer.co.uk/r/Various/Apple+news/news.asp?c=29297 http://www.pocketgamer.co.uk/r/Various/Apple+news/news.asp?c=29297 http://livepage.apple.com/ http://livepage.apple.com/ Sin embargo, será escrita de la forma más general posible para que todos los principios men- cionados sean aplicables a las demás plataformas de hoy. En cada una de estas plataformas se han facilitado varios procesos como el de la distribución y pago, pero al mismo tiempo ha surgido un reto importante: como existe un único canal oficial para la venta de aplicaciones, en cada tienda ocurre una feroz competencia directa25: más de un nego- cio ofrece el mismo producto o servicio en el mismo mercado a través de los mismos canales de venta. Pero esta competencia no debe ser entendida como algo negativo, ya que impulsa la innova- ción por parte de los que ofrecen un bien o servicio y permite a los consumidores tener más opciones y mejores productos a un mejor precio. Además, conocer a la competencia es una de las mejores formas de entender el mercado y saber qué es lo que necesita y cuáles son las ne- cesidades que no han sido atendidas. Otro cambio está en la forma en que los usuarios consumen el software: ahora están me- jor informados y ya no tienen que atenerse a algunas pocas opciones independientemen- te de si buenas o malas. Por si fuera poco, ahora tienen expectativas muy altas sobre la calidad de las aplicaciones que compran. Todo esto coloca al ingeniero en entorno muy competitivo, globalizado y extremadamente di- námico en el que puede ofrecer sus propios productos a potencialmente miles o millones de usuarios al mismo tiempo y en el mismo canal en el que lo hacen grandes corporaciones, inge- nieros de otros países y equipos de trabajo más grandes o con más experiencia 14 25 Pinson, Linda. Steps to Small Business Start-Up. Estados Unidos: Kaplan Publishing. 2006. Página 22. Hacer un Producto de Software Valioso La invención de un producto de software de este tipo comienza con el in- geniero (supuestamente aquel hombre con el deber de desarrollar ingenie- ría) haciendo un esfuerzo consciente por observar su entorno, anticipar, inter- pretar y adaptar las necesidades de las personas para visualizar nuevas formas de hacer las cosas y dar con un producto útil. A continuación, se deben: 1. Fijar las necesidades del consumidor y definir quiénes son los consumidores del producto. 2. Definir un conjunto de acciones que el artefacto de software hará para que el usuario cumpla estas necesidades. 3. Partiendo de esas acciones, determinar funciones específicas (y la capacidad de esas fun- ciones) para que el consumidor cumpla esas necesidades. 4. Diseñar, planear e implementar el producto de software ideado. Las funciones específicas que el producto realice serán, junto con la usabilidad y la interfaz de usuario, los parámetros de comparación más importantes con otras aplicaciones similares. Todas estas funciones deben poder traducirse en beneficios directos para el consumidor, como por ejemplo: horas de diversión, ganar tiempo al hacer cierta tarea o bajar de peso más rápidamente. Entre estas funcionalidades se debe identificar aquella (o aquellas) que son únicas en la aplica- ción y que la caracterizan frente a la competencia. Saber esto sirve para tener una mejor idea de como invertir los recursos disponibles durante el desarrollo y tener una idea clara de los mensajes que quieren darse durante las actividades de marketing. Por último, debe pensarse en la factibilidad monetaria del proyecto; debe ser una solución a una necesidad generalizada o si se trata de una aplicación con un nicho de mercado, éste de- be ser lo suficientemente grande para generar ventas suficientes con las cuales costear el pro- yecto (y unas fascinantes vacaciones en un lugar remoto y paradisíaco). 15 / Planeación “Life is what happens to you while you're busy making other plans” - John Lennon Planeación La planeación de un proyecto es una actividad centrada en completar un resultado dentro de un tiempo y costo determinado satisfaciendo las expectativas del cliente. Esta guía presupone que los proyectos realizados por sus lectores presenta- rán características particulares como: • Serán realizados por un individuo o un equipo pequeño de individuos. • La dimensión del proyecto es relativamente pequeña y la primera fase de desarrollo es corta. • El resultado del proyecto se presentará en un mercado competitivo que requiere velo- cidad y flexibilidad. • Probablemente se efectuará sin horarios ni espacios bien definidos, utilizando el tiempo libre y localizándose en casa de uno de los colaboradores, la biblioteca de la escuela o el Starbucks más cercano. • No es un trabajo solicitado por un cliente, sino un esfuerzo particular por colocar un producto en el mercado. • Sus integrantes cuentan con poca experiencia en la producción comercial de software. • Se ejecutan con un presupuesto muy limitado. • Todos los miembros del equipo comparten responsabilidades a un nivel similar. 16 Distintos proyectos y contextos requieren distintos tipos de planeación: una página web hecha por una persona, no requiere el mismo tipo de planeación que el software tolerante a errores utilizado en aviones y hecho por un equipo de cientos de personas con un presupuesto de millones de dóla- res. Por lo general, entre mayor sea la complejidad y mayor el número de colaboradores de un pro- yecto, se requerirá una mayor estructura en su planeación. Por esto, aunque la mayoría de las me- todologías comparten algunos principios, no hay “metodología panacéica” aplicable a todos los tipos de proyectos y aún la utilización de “mejores prácticas” no es garantía de éxito26. Las consideraciones anteriores apuntan a utilizar nuevas metodologías (como el enfoque ágil) en lugar de las metodologías tradicionales, las cuales están íntimamente vinculadas con los procesos y estructuras del negocio. Estas últimas, fueron diseñadas para equipos de trabajo mucho más grandes o proyectos de mayor duración y complejidad, haciendo muchos de sus procesos y documentación un esfuerzo innecesario para proyectos más pequeños. Las metodologías ágiles surgieron como respuesta a metodologías que en teoría son efectivas, pero que en la práctica no lo son tanto. En el enfoque ágil, se persigue la mejora continua, en- contrar la calidad desde la primera vez, producir únicamente lo que es necesario y enfocarse en el desarrollo del software en lugar de en la extensiva documentación, midiendo el progreso del proyecto en unidades de software funcional. Scrum es uno de los métodos de desarrollo más populares para el desarrollo ágil y uno muy adecuado para las características de proyectos de este tipo, razones por las cuales será anali- zado con detalle y sugerido para planear la ejecución de un proyecto. 17 26 McGuire, Eugene. Software process improvement: concepts and practices. Londres : Idea Group Inc. 1999. Página 19. Scrum Scrum extiende el método de desarrollo incremental a algo llamado proceso de control empírico, en donde los ciclos de retroalimentación se convierten en el elemento nuclear. Está inspirado en varias áreas de conocimiento como teoría de complejidad, sistemas dinámicos y la teoría de creación del conocimiento de Nonaka y Takeuchi, adaptándolas al desarrollo de software. A grandes rasgos, las fases de desarrollo se dividen en pequeñas iteraciones llamadas “sprints”, las cuales duran típicamente entre una y cuatro semanas. Primero, se identifican y capturan las tareas requeridas en una bitácora que es actualizada, es- timada y priorizada al principio de cada una de estas iteraciones. El equipo mantiene breves juntas durante cada día de desarrollo para discutir el progreso, plan y potenciales problemas del proyecto y se trabaja en las tareas definidas en la bitácora. Finalmenteal término del sprint, se demuestran y recapitulan los avances obtenidos y se inicia uno nuevo para repetir el ciclo hasta haber terminado la totalidad del proyecto. Figura 2: El ciclo scrum Planeación Sprint Demostración Retrospectiva 18 Antes de explicar a detalle cada una de estas fases, hay que conocer los roles principales que existen en ellas: Roles Importantes dentro de Scrum • Equipo Scrum: Trabajan efectivamente en los problemas del software. Se sugiere como máximo 9 personas. Los miembros del equipo deben decidir cómo se distribuye el trabajo y cómo se define. • Product Owner Representa la voz del cliente y administra la bitácora del producto, una lista de tareas priori- zada por su rentabilidad hacia el negocio. Por lo general se trata de un cliente, pero también puede ser alguien que sea parte de la organización. En un enfoque completo, su labor requie- re conocimiento de procesos de ingeniería, marketing y negocios. • Scrum Master Scrum Master es un nombre más divertido para quien en la normalidad sería conocido como “Project Manager”. Su tarea es la de poner al equipo de trabajo en las mejores circunstancias posibles y, des- pués de cada iteración, hacer una retrospectiva para revisar las conclusiones y experiencias con el fin de motivar y mejorar el conocimiento del equipo para atacar la siguiente iteración. 19 El Ciclo Scrum 1. Planeación y Bitácora del Producto En el primer sprint del proyecto, el “Product Owner” compila todos los requerimien- tos y especificaciones de un nuevo producto para plasmarlas en algo llamado “his- torias”, las cuales son una descripción de funcionalidades de alto nivel escritas de forma breve. En el caso de planear la actualización de un producto se escribirían nuevas funciones y parches. Después de esto y al principio de los siguientes sprints, se seguirán los siguientes pasos: A. Cada “historia” que no ha sido implementada, es puesta en la bitácora del producto y el rol de “Product Owner” les asigna prioridades. B. El equipo asigna una valoración de complejidad para cada historia (Ej: 1, 2, 3, 5, 8), se estiman cuántas historias pueden ser realizadas durante una iteración y el equipo se compromete a ha- cer su mejor esfuerzo para terminar todo el trabajo propuesto durante el siguiente sprint. 2. Iteraciones (Sprints) A. Todas las historias son implementadas progresivamente en orden de importancia, por- que son las que representan más valor desde la perspectiva del negocio. Cada equi- po (o individuo) es responsable de cumplir las historias que ha escogido. 3. Juntas Diarias (¡pfff!) Durante cada día de desarrollo, el Scrum Master se reúne con el equipo de trabajo para responder, en una junta breve, tres preguntas: • ¿Qué avances se han hecho desde la última junta? • ¿Qué va a hacerse desde ese punto hasta la siguiente junta? • ¿Hay algún conflicto o situación que impida llevar a cabo el plan? De esta forma se logra que todo el equipo esté informado acerca del progreso del proyecto y que los problemas que se han encontrado, sean resueltos. 20 4. Demostraciones Al final de cada iteración se hace una demostración de todo el software fun- cional que se haya realizado: todas las historias son demostradas ante el rol de “Product Owner”, quien las aceptará o rechazará. Como esta metodología está basada en la iteración de componentes de software funcional, en este punto las historias deberán operar en su totalidad y estar libres de errores. El último apartado de este capítulo, menciona la tarea de verificación y validación. Buena Idea: Aún mejor es presentar las historias terminadas apenas se hayan completa- do, evitando una historia rechazada que se traslapa a la siguiente iteración. 5. Retrospectiva Tras la demostración, los miembros del equipo y su juicioso Scrum Master responden las siguientes preguntas: • ¿Qué se llevó a cabo bien? • ¿Qué puede ser mejorado? • ¿Qué acciones pueden tomarse para mantener una alta calidad en el futuro trabajo? Realimentando la siguiente iteración con los resultados aplicables. 21 Algunas Buenas Prácticas para Cada Iteración Claridad en el Código Algunos programadores escriben código conciso, complicado e indescifrable para denotar su basto conocimiento acerca de la sintaxis del lenguaje y sus trucos más recónditos. Es- tos intentos desesperados por llamar la atención deben ser sustituidos por la escritura de un código claro, simple y entendible en el que distintas personas con distinta experiencia pueden trabajar fácilmente. Un código entendible es más fácil de mantener; y durante su manutención, se reduce el riesgo de introducir nuevos errores porque su lógica no sea clara. Comentar el Código Los comentarios27 son notas dentro del mismo código del programa que seña- lan pasos y características claves del mismo y que están escritas de tal forma que la computadora pueda ignorarlas para la ejecución del programa. Esta práctica genera un tipo de documentación interna que, implementada correctamente, permite entender más fácilmente el código en cuestión y es- to a su vez facilita el mantenimiento y actualización del proyecto, así como la re-utilización de código mediante la legendaria práctica del copy-paste. Tampoco hay necesidad de caer en una sobre-explicación innecesaria: los comentarios son empleados cuando el código no puede ser más claro mediante otros medios. 22 27 Morley, Deborah. Understanding Computers: Today and Tomorrow, Comprehensive. Estados Unidos: Cengage Learning. 2009. Páginas 561-562. Buena Idea: Escribir los comentarios del código al mismo tiempo que se codifica. Escri- birlos tiempo después de codificar es más complicado ya que probablemente requerirá re-entender el código. Wikis Un wiki28 es un software en línea que permite a todos sus visitantes cambiar su contenido mediante la edición de las páginas dentro de un explorador; convirtiéndola en una plataforma simple y fácil de usar para el trabajo colecti- vo de textos e hipertextos. Un wiki privado para los participantes del proyecto puede utilizarse para escribir toda la documentación referente al proyecto: bitácoras, resultados de pruebas de verificación y validación, tareas a completar, etc. En la red existen varias alternativas disponibles y la mayoría de ellas son gratuitas29. Respaldos de Seguridad Discos duros dañados, archivos corruptos, virus, empleados vengativos borran- do archivos sensibles, laptops hurtadas a manos de bandidos sin escrúpulos: parecería que la posibilidad de perder todo el trabajo invertido en una aplicación es ineludible. Aunque ciertamente no lo es, sí vale la pena tener un plan en que, ante un infortunio como los antes mencionados, permitiera reanudar el trabajo sobre el proyecto de manera rápida, sencilla y económica (en términos de tiem- po y dinero) y sin tener que repetir ningún esfuerzo. W 23 28 Ebersbach, Anja. Wiki: Web Collaboration. Berlin: Springer. 2008. Pagina 12. 29 :) Por fortuna, un proyecto para una plataforma móvil tenderá a ser un conjunto de archivos y re- cursos de tamaño relativamente pequeño y que fácilmente podría respaldarse sobre un CD, DVD, Disco Duro, memoria USB o un servidor remoto. Además de los recursos y archivos del proyecto mismo, es útil hacer copias de seguridad de la documentación del proyecto. Se exponen algunos principios básicos: • Ordenar la información backup.tar.gz o backup2.tar.gz no son títulos muy descriptivos. Un buen orden y una buena deno- minación de los archivos de respaldo, hacen una recuperación de datos mucho más simple. • Distintas Locaciones Lejos de detallar ejemplos como huracanes u otras catástrofes remotas , existe el caso mucho más cotidiano de que un ladrón entrara a una casa u oficina. Además de llevarse todas las computadoras del lugar, es probable que decidiera equiparse también con accesorios como discos duros y memorias, convirtiera cualquier práctica del respaldo de información en un es- fuerzoabsolutamente fútil. Control de Versiones Los sistemas de control de versiones (CVS) pueden considerarse como parte de las estrategias de backups y respaldos de seguridad, aunque incluye mayores alcances y beneficios. El mercado oferta un sinnúmero de posibilidades, varias de ellas gratuitas, cada una con una comunidad de adeptos y fanáticos que defienden religiosamente las virtudes de cada sistema y se ocupan en se- ñalar las faltas y deficiencias de aquellos que no utilizan30. Aunque existen diferencias funcionales y filosóficas entre cada sistema, todos los CVS deberían poder hacer lo siguiente31: • Mantener y permitir el desarrollo de un repositorio de contenido. • Llevar un registro de todos los cambios hechos sobre cada recurso del repositorio. • Proveer acceso al historial de ediciones de cada uno de estos recursos. 24 30 Un vistazo fugaz a este recurso ejemplifica claramente el punto: http://atomized.org/2005/09/subversion-sucks/ 31 Loeliger, Jon. Version Control with Git. Estados Unidos: O'Reilly Media, Inc. 2009. Página 1. http://atomized.org/2005/09/subversion-sucks/ http://atomized.org/2005/09/subversion-sucks/ Tomando en cuenta las consideraciones enunciadas al principio del capítulo, la elección del Siste- ma de Control de Versiones queda prácticamente reducida a la comodidad que pudiera significar un sistema sobre otro: como si el equipo tiene experiencia con algún sistema particular o si el CVS esta integrado al Entorno de Desarrollo (IDE) y supondría un uso mucho más simple del mismo. Tips de Verificación y Validación para cada iteración Como se mencionó anteriormente los componentes completados al término de cada iteración son componentes funcionales y libres de bugs. Lo que implica que deben haber sido probados y se ha verificado que su comportamiento es exactamente el esperado. En este tipo de aplicaciones la verificación y validación del programa tiene un objetivo muy concre- to: buscar la satisfacción del cliente por la compra que ha hecho. Los compradores de software son cada vez más intolerantes a productos con errores y ahora tienen altas expectativas que de no ser cumplidas, resultan en comentarios negativos en la tienda, o peor aún, en medios como blogs o redes sociales que podrían impactar negativamente en las ventas y percepción del producto. Estas demostraciones justificadas de frustración son causadas principalmente por dos causas: un desempeño deficiente y falta de usabilidad. El equipo de desarrollo debe invertir todo es- fuerzo necesario para eliminar o reducir de forma drástica cualquiera de estas deficiencias. Debe considerarse que un producto final distribuido en una tienda, será puesto a prueba por un gran número de usuarios en un amplio conjunto de posibilidades impredecibles acerca su uso. Entre mayor sea su uso, mayores las probabilidades de que bugs “ocultos” o difíciles de encontrar sean, de hecho, encontrados. Existe un sinnúmero de técnicas y procedimientos detallados para probar código, pero este trabajo se acotará a señalar algunas estrategias que den una perspectiva general y práctica de la calidad del producto y sus componentes: 25 Probar la aplicación en dispositivos físicos Probar la aplicación permite verificar dos aspectos importantes de la aplicación: • Primero, que la interfaz sea funcional (tamaño y disposición de los botones y texto) en un entorno real. • Segundo, los simuladores no representan fidedignamente el desempeño de los dispositivos, uso de memoria, conectividad, sistema operativo y otros recursos de hardware. Puede haber diferencias importantes en la velocidad del programa o incluso no funcionar del todo. Acelerómetros o servicios de posicionamiento tampoco están disponibles en los simuladores. Usuarios ßeta El equipo de desarrollo (o desarrollador) están demasiado involucrados y conocen demasiado el producto para detectar todos los bugs por sí mismos. Solicitar algunos usuarios beta a través de redes sociales o en el círculo de amigos de uno mismo, permite encontrar bugs difíciles de en- contrar y hacer mejoras en su usabilidad. Como una ventaja adicional se tiene acceso a nuevas perspectivas para descubrir nuevos segmentos de mercado y nuevas funcionalidades. Errores Fatales No hay frustración más grande para el usuario que una aplicación que termina abrup- ta e inexplicablemente. Si este tipo de errores son detectados, la aplicación está todavía lejos de poder llegar al mercado. 26 Buena Idea: Errores fatales que se presentan de maneras misteriosas, ocurren común- mente debido a problemas con la disponibilidad de memoria. Verificar la interfaz de usuario La interfaz del usuario debe ser obvia y consistente. En el capítulo “Interfaces de Usuario” se sugiere una metodología simple, pero valiosa para la verificación de la interfaz de usuario. Am- pliamente recomendable. ;) Verificar problemas de conectividad Si la aplicación depende de conectividad con la red para funcionar, deben pro- barse casos en donde ésta sea nula o deficiente. La aplicación debe ser tole- rante a este tipo de “eventualidades” no tan eventuales en los móviles. Buena Idea: Poner el dispositivo dentro de una caja de zapatos forrada de papel alumi- nio32 permite probar un enlace degradado de Wi-Fi o de datos; además de dar al desarro- llador un romántico aire científico-experimental. 27 32 Scholz, Fritz. Electroanalytical Methods: Guide to Experiments and Applications. Berlin: Springer. 2010. Página 335. / Interfaces de Usuario “It is far better to adapt the technology to the user than to force the user to adapt to the technology” - Larry Marine Las interfaces de usuario33 son todo aquel espacio gráfico y físico en donde los usuarios inte- ractúan con el software. Dentro de este espacio se le presenta información, la cual él debe en- tender, evaluar e interpretar para decidir qué hacer con ella. Una vez que decide qué hacer, és- te crea un plan de acción y retroalimenta a la interfaz con entradas de acuerdo a este plan. En- tonces, el software interpreta esas entradas y genera cambios internos en los modelos que re- presentan la información con la que el usuario está interactuando. Todos estos cambios, deben ser reflejados nuevamente en la interfaz para que el ciclo pueda iniciarse nuevamente. La interfaz de un producto de software es una de las partes más críticas del mismo y no es un aspecto que deba dejarse hasta el final del desarrollo, sino que muy al contrario, deberá contem- plarse desde el inicio del mismo, ya que una interfaz mal diseñada puede hacer que el uso de una aplicación se convierta en algo verdaderamente tortuoso y en un entorno en donde existen cientos de competidores, el usuario no dudará ni un momento en buscar una aplicación con una funcionalidad similar (o incluso menor) a cambio de una interfaz más atractiva y cómoda. Además de ser una parte crítica del desarrollo, también es uno de los procesos más divertidos de todo el ciclo, puesto que: existen reglas claras y bien definidas acerca de cómo lograr una buena interfaz; no representan un reto técnico insalvable o algoritmos desafiantes que imple- mentar y finalmente; los esfuerzos invertidos en este proceso son inmediatamente observables y profundamente satisfactorios. 28 33 Olsen, Dan. Developing user interfaces. Estados Unidos: Morgan Kaufmann. 1998. Páginas 11 y 12. Pasos para Crear una Interfaz de Usuario Pero, ¿cómo comenzar con el diseño de una interfaz? El primer paso para hacer una buena interfaz es conocer perfectamente a quienes van a usarla y entender cuáles son las tareas que querrán llevar a cabo. Teniendo esto claro, se puede proceder a definir un modelo de funcio- nalidad, el cual describirá las acciones que puede hacer el usuario sobre los datos, el estado del sistema y la capacidad de acción que puede ejercer sobre los mismos. Una definición de la funcionalidad cuidadosa puede hacer que implementar futuras innovacionesen la aplicación sea más simple. Al terminar de especificar el listado de funcionalidades del programa se puede evaluar y realizar alguna retroalimentación junto con algunos usuarios potenciales a fin de verificar que las funcionalidades propuestas estén satisfaciendo sus expectativas y necesidades. En esta fase no deben contemplarse aún pantallas, comandos, etc. Una vez que se ha definido toda la funcionalidad involucrada a través de la aplicación, se pueden empezar los bosquejos de la presentación visual. En este punto, deben hacerse varias consideraciones respecto a los elementos de diseño gráfico (consideraciones enunciadas más adelante) y respecto al rendimiento y prestaciones del dispositivo: po- dría ser que los autores del software deseen darle una interfaz con animaciones y millones de colores, pero que muchos de los dispositi- vos donde se ejecutará el programa sean de gama baja y que cuenten con pantallas pequeñas con 256 colores. Casi a la par de la presentación, se definen las acciones que pueden realizarse en ella. En fechas actuales, esto no debe limitarse a un as- pecto visual, sino que de ser posible, debería utilizar las nuevas formas de interacción de los dispositivos móviles (sensores, gestos en pantallas táctiles, etc.). Definir Funcionalidad Proponer Presentación Asignar Acciones Conocer al Usuario Integrar Arte 29 Finalmente, teniendo el aspecto funcional de la aplicación, este debe integrarse con el diseño gráfico y arte de la aplicación, buscando siempre la cooperación y el balance entre función y forma. Al respecto, el arquitecto Louis Sullivan dijo: “la forma sigue la función”. El sentido origi- nal de esta frase radica en que Sullivan estaba convencido de que las formas físicas más bellas resultan de diseños que expresen la naturaleza esencial del material en cuestión y que ésta es una regla simple común en la naturaleza. Arte y Diseño Gráfico El arte y diseño gráfico de una aplicación hacen que sea atractiva y que la actividad de utili- zarla no solamente sea útil sino también placentera. Muy pocas veces se considera la estéti- ca como un aspecto relevante, pero en un entorno tan competitivo como estas nuevas plata- formas de comercialización, la estética puede ser el diferenciador determinante en la elección entre varias aplicaciones similares. El arte de una aplicación incluye mensajes, íconos, colores e imágenes y estas consideraciones deben estar presentes durante todo el desarrollo de la aplicación y no solo en las últimas eta- pas. Un resultado notable y competitivo es prácticamente imposible de lograr sin la colabora- ción de profesionales de las artes gráficas. Elementos de Diseño en las Interfaces de Usuario Todos los elementos que se describen a continuación deberán utilizarse con el fin de comuni- car más claramente un mensaje al usuario, al mismo tiempo deben considerarse los lineamien- tos de Interfaz Humana específicos para cada plataforma, ya que aunque existen tendencias universales, puede llegar a haber variaciones entre plataformas. 30 Color La vida diaria está plagada de colores que transmiten mensajes importan- tes, como los semáforos o colores en carteles de advertencia; también existe el caso de colores que no apelan a un fin utilitario, sino que tienen un fin estético como los colores en la ropa que usamos. Las interfaces de usuario no son la excepción en el dominio del color: este puede ser usado para resaltar y estructurar la información que se presenta al usuario y para hacer la interfaz más atractiva. Buena Idea: El uso excesivamente desinhibido del color produce estéticas incongruen- tes, de mal gusto e incompatibles con su funcionalidad. En una palabra, kitsch34. Tipografía La tipografía es el “arte de disponer correctamente el material de imprimir, de acuerdo con un propósito específico: el de colocar las letras, repartir el espacio y organizar los tipos con vistas a prestar al lector la máxima ayuda para la com- prensión del texto”35. Es una disciplina que ha estado presente desde las prime- ras interfaces con el propósito de tener una mejor y más rápida legibilidad. Deben elegirse fuentes que sean legibles y al mismo tiempo atractivas. Su tamaño debe ser suficientemente grande para que pueda ser leído con comodidad por personas de distintas edades y sus variantes de peso, inclinación y color deben ayudar a resaltar y organizar la in- formación que se presenta ante el usuario. A 31 34 Ejemplos, historia y un extenso debate acerca del término alemán “kitsch” pueden ser disfrutados en el libro “A Com- panion to Aesthetics” de Stephen Davies. 35 Morison, Stanley. Principios fundamentales de la tipografía. España: Ediciones del bronce. 1998. Buena Idea: En la red hay miles de fuentes disponibles para descargar, pero no por esto hay que utilizarla todas. Distintas fuentes transmiten distintos mensajes; usar más de 2 o 3 fuen- tes por pantalla (4 o 5 por aplicación) resulta en caóticos y confusos popurrís tipográficos. Imágenes Las imágenes en las interfaces son ahora tan importantes como el texto que contienen y el avance en el hardware de los dispositivos permite usar imágenes de mejores resoluciones y mayores profundidades de color. Pero no solo debe prestarse atención a la calidad del archivo en términos de su resolución y color, sino que también al contenido pictórico y lo que este representa hacia el usuario: íconos e imágenes dentro de la aplicación pueden representar comandos, estados, objetos y resulta- dos del modelo de datos. Todas estas imágenes e íconos deberán ser obvias para los usuarios exper- tos y evidentes para los nuevos usuarios. Para íconos e imágenes que tengan una relación directa con la funcionalidad del programa se pueden evaluar mediante el mismo método que los diseñadores del American Insitute of Graphic Arts (AIGA) utilizaron en 1981 para evaluar señales utilizadas en medios de transporte público de Estados Uni- dos36. Esta evaluación contempla 3 dimensiones diferentes: • Sintaxis: Es la relación entre las imágenes utilizadas. ¿Cómo se relaciona este símbolo con otros símbolos? ¿Es entonces consistente en la forma en que está dibujado? ¿Sus características como dimensión, orientación, formato, color, etc. son consistentes con los demás símbolos? • Pragmatismo: Describe la relación de la imagen con el usuario. ¿Las personas pueden leer clara- mente el símbolo? ¿El símbolo es afectado por condiciones de luz, ángulo de visión u otro tipo de ruido? ¿El símbolo es igualmente efectivo al ser muy pequeño o muy grande? • Semántica: Es la relación de la imagen con su significado. ¿Qué tan bien representa este símbolo a su significado? ¿Personas de distintas culturas entienden bien este símbolo? ¿Personas de distintas edades entienden el mismo significado? ¿Este símbolo es utilizado universalmente? 32 36 AIGA. Symbol Signs: The System of Passenger / Pedestrian Oriented Symbols Developed for the US Department of Transportation. Estados Unidos: Hasting House. 1981. Un gran ejemplo de lo anterior es el trabajo iconográfico del Sistema de Transporte Colectivo Metro de la Ciudad de México del diseñador Lance Wyman hecho en los años sesenta. Wyman trabajó bajo la consigna de hacer pictogramas de cada una de las estaciones para que los visi- tantes extranjeros (y analfabetas mexicanos) de los juegos olímpicos de 1968 pudieran identifi- car las estaciones independientemente del idioma que hablaran. Distribución y Agrupación Al disponer controles y textos dentro de la interfaz, deben mantenerse márgenes consistentes entre los bordes de las pantallas y los controles relacionados entre si deben mantenerse en grupo. Contro- les que no tengan relación con otros deben mantenerse ligeramente separados. Al hacer uso de márgenes se debe intentar usar una misma medida para que el usuario reconozca y visualice la información más fácilmente. Sonidos Los estímulos auditivosinforman a las personas de señales importantes que ocurren a su alrededor, como alarmas contra incendios o bebés al borde de la inanición. Es un sentido fuertemente ligado a la experiencia de vida de las personas mediante el cual reciben información (no necesariamente crucial) del medio que los rodea. Las apli- caciones pueden hacer uso de este sentido para: 1. Llamar la atención del usuario y alertarlo de un cambio de estado relevante para él (por ejemplo, batería baja); 2. Envolverlo en la experiencia de la aplicación (como lo hace la música de los video-juegos); 3. Dar más retroalimentación acerca de las acciones que realiza el usuario sobre el sistema (¿el mejor ejemplo? los tonos que se escuchan al marcar un número telefónico) y finalmente, pero no menos importante; 4. Hacer la interfaz de usuario más divertida :) 33 Como todo en esta vida, debe hacerse un uso moderado de este recurso para evitar que sea demasia- do invasivo hacia el usuario y los archivos deberán ser de la máxima calidad posible evaluando también que no sobredimensionen innecesariamente el tamaño final de la aplicación. Principios Básicos para el Diseño de Interfaces Además de las consideraciones enunciadas en la sección anterior, vale la pena mencionar una de las listas de principios de diseño más universales, útiles y, al mismo tiempo, más actualiza- das hasta el momento: 8 principios investigados y depurados durante veinte años por Shnei- derman y Plaisant y nombradas “Las Ocho Reglas de Oro para el Diseño de Interfaces”37. 6. Buscar Consistencia: Esto quiere decir homogeneizar las propiedades de los elementos visuales como por ejem- plo: fuentes, distribución y tamaños; y unificar todos los términos utilizados a lo largo del producto: menús, ventanas, avisos, documentación, etc.. 7. Atender la Usabilidad Universal Durante el diseño de la usabilidad de un producto, se debe tener en mente que los usua- rios, por lo general, difieren en edad, experiencia y capacidades. Los usuarios inexpertos agradecerán algunos mensajes de ayuda mientras que los usuarios expertos preferirán co- mandos o atajos para realizar más rápidamente sus tareas. 8. Ofrecer Retroalimentación Informativa Las acciones del usuario sobre el sistema, deben provocar alguna retroalimentación por parte de éste, y esta retroalimentación debe ser proporcional a la magnitud de las acciones del usuario. 9. Agrupar las interacciones para indicar su fin Las interacciones secuenciales con el sistema deben organizarse en grupo de tal forma que un inicio y un fin puedan ser identificados y que al llegar a este, el usuario del sistema pue- da encontrar el alivio emocional de “haber terminado una tarea” (esto también hace refe- rencia al punto No. 3). 34 37 Shneiderman, Ben. Designing the User Interface: Strategies for Effective Human-Computer Interaction. Estados Uni- dos: Addison-Wesley. 2009. 10. Prevenir Errores El sistema debe ayudarle al usuario a evitar errores, por ejemplo: evitar caracteres alfabéti- cos dentro de un campo destinado a “Código Postal”. 11. Permitir la fácil retracción de las acciones A todos nos gustaría que la vida tuviera un botón de “CTRL-Z” que aliviara la ansiedad y miedo de cometer errores y explorar nuevas posibilidades. Dentro de lo posible, las accio- nes efectuadas dentro de un sistema deben ser reversibles. 12. Hacer sentir al usuario que tiene el control Un automóvil que no responde a la operación del usuario es un automóvil que nadie le gus- taría usar (y una peligrosa situación que a nadie le gustaría vivir). Este fenómeno se presen- ta también durante el uso de cualquier software. 13. Reducir la carga en la memoria de corto plazo La memoria a corto plazo de las personas comunes esta limitada a retener 7 ± 2 ele- mentos38. Esta es una consideración importante para el diseño de menús, opciones e información dentro del producto. Internacionalización y Localización Estas nuevas plataformas de distribución permiten al desarrollador colocar sus aplicaciones dentro de un alcance global. Salvo excepciones donde la aplicación se dirija a una audiencia delimitada a una región de composición afín entre sí (idioma, cultura, etc), habrá que considerar Oh là là! 35 38 Miller, George. The Magical Number Seven, Plus or Minus Two Some Limits on Our Capacity for Processing Informa- tion. Psychological Review, Vol. 101, No. 2. Páginas 343-352. adaptar la aplicación, su contenido y recursos, para ser consumidos dentro de distintas culturas. A este proceso, la estrategia de diseño en la que se soporta a la comunidad global de usuarios del cómputo mediante variaciones sistemáticas entre regiones y culturas, se le denomina localiza- ción39. Por otro lado, la internacionalización significa “habilitar una aplicación o un sistema, para pre- sentar distintos formatos y lenguajes sin cambios en su código fuente”40. El proceso de locali- zación no se refiere únicamente al lenguaje escrito, sino a describir y alinear todo contenido de una aplicación dentro de la familiaridad de la ubicación geográfica, el lenguaje, sensibilidades particulares y los formatos numéricos de una cultura. La lista de items a considerar para una localización incluye principalmente: • Menús y cualquier texto estático dentro de la aplicación • Íconos y gráficas, • Archivos de sonido que incluyan palabras • Ayuda en línea (si es que la hay) • Texto dinámico como fechas, horas y valores numéricos En la mayoría de los casos, no será indispensable contar una localización que incluya 125 idiomas, pero se deberá identificar perfectamente la audiencia a la que va dirigida el producto y a partir de esto, evaluar qué idiomas y localizaciones son los más importantes para la comer- cialización del producto y hacerlo de los más inclusivos o generales hacia los más particulares. Una localización prácticamente indispensable es la del idioma inglés, pero algunos casos es- pecíficos requerirán alguna otra con la misma urgencia: un diccionario francés-español / espa- ñol-francés, deberá estar localizado (al menos) para el idioma francés y español. 36 39 Rosson, Mary Beth. Usability engineering: scenario-based development of human-computer interaction. Estados Uni- dos: Morgan Kaufmann. 2002. Página 352. 40 Kogent Solutions Inc. Java Server Programming Java Ee5 Black Book. Estados Unidos: Dreamtech Press. 2008. Apéndice H. Buena Idea: La primera localización que uno debería pensar en hacer es para el idioma inglés. Accesibilidad 41 Accesibilidad42 se refiere al conjunto de características que debe proveer un entorno, producto o servicio para ser usado en términos de confort, seguridad e igualdad para todas las personas, particularmente para todas aquellas personas con discapacidades. El diseño de las interfaces de usuario debe ser pensado bajo la idea de diversidad y no en función de la persona co- mún, promedio o joven: cualquier persona de cualquier edad debe ser capaz de poder utilizar cualquier interfaz sin tener que enfrentar ningún problema. Es deseable que si la plataforma provee algún componente para mejorar la accesibilidad de la aplicación (como etiquetas especiales para un lector de voz) estos sean utilizados. Consideraciones Particulares para Plataformas Móviles Los dispositivos móviles son también un equipo de cómputo y como tal, comparte algunas ca- racterísticas con computadoras de escritorio, laptops o servidores. Pero también presentan características únicas y diferencias funcionales que requieren un enfoque nuevo al desarrollar aplicaciones para ellos: 37 41 Macías, José A. New trends on human-computer interaction: research, development, new tools and methods. Estados Unidos: Springer. 2009. Página 133. 42 1st National Accessibility Plan 2004-2012. España. 2004. Pantallas Pequeñas Las resoluciones actuales de los dispositivos móviles más modernos se encuen- tran alrededor de los 320 x 480 (iPhone 2G, 3G, 3GS, iPod Touch 2G, 3G)y 640 x 960 pixeles (iPhone 4). Resoluciones 3 o 4 veces más pequeñas comparadas con la resolución del monitor de una computadora de escritorio común. Como consecuencia, se requiere que el diseño de la interfaz de usuario presente únicamente los elementos indispensables y que los mantenga en una cantidad mínima para evitar un producto poco atractivo y difícil de usar. Menos Memoria y Menores Capacidades de Procesamiento Vivimos una época en la que el precio de las memorias RAM y los procesado- res han permitido ser más indulgentes en la evaluación del desempeño y aprovechamiento de los recursos que tienen nuestras aplicaciones. Sin em- bargo, cualquier dispositivo móvil cuenta con una cantidad de memoria RAM mucho más limitada y una capacidad de procesamiento aproximadamente 3 veces menor que el de una computadora de escritorio. Debe ponerse espe- cial atención a fugas de memoria y uso ineficiente de la misma; de igual forma debe mantenerse al margen el tamaño de todos los recursos multimedia. Batería Un teléfono o cualquier otro dispositivo móvil tiene una cantidad limitada de energía provista por baterías. Un buen diseño en una aplicación debe pro- curar evitar hacer cálculos innecesarios, conexiones redundantes a internet o un uso innecesariamente intensivo de los servicios de posicionamiento (GPS) que pudieran agotar la carga de las baterías del dispositivo y dejar al usua- rio desprovisto de su inseparable gadget en una situación de vida o muerte. < 38 Conexiones Costosas En México, la conectividad en los dispositivos móviles (tanto voz y datos) tie- nen un costo monetario muy alto43. La aplicación debe minimizar (sin com- prometer su función) el número de conexiones a internet o el tamaño de los datos que descarga, porque esto representa un costo para el usuario. Servicios de Posicionamiento Casi es obvio señalar que un dispositivo móvil implica movimiento. Esto le puede dar al desarrollador nuevas posibilidades respecto a otras plata- formas: saber la localización del usuario puede derivar en funcionalida- des de mucho valor para este. Gestos y Nuevas Formas de Interacción Hasta hace no mucho tiempo, la interacción con los dispositivos electróni- cos (no solo móviles) estaba limitada a las puntas de los dedos. Afortuna- damente, las interfaces más recientes empiezan a incluir nuevas dimen- siones entre esta interacción entre dispositivos e individuos: reconocimien- to efectivo de voz, sensibilidad a gestos táctiles más complejos, sensibili- dad al movimiento, cámaras, etc. Para lograr una experiencia total y actualizada de la aplicación, se requiere pen- sar en todas estas nuevas formas de interacción y buscar aprovecharlas de forma que hagan la interacción con el usuario más natural, rápida y dinámica. 39 43 “[altas tarifas], las cuales son 43.5% superior al promedio de las que aplican los países miembros de la OCDE,” Alonso, Ramiro. "Cofetel envía modelo de costos a la Cofemer" El Universal. 3 de Marzo de 2011. Consultado el 25 de Marzo de 2011. <http://www.eluniversal.com.mx/finanzas/84947.html> http://www.eluniversal.com.mx/finanzas/84947.html http://www.eluniversal.com.mx/finanzas/84947.html Ayuda Mínima Una aplicación móvil tiene la intención de poder ser accedida fácilmente y ser utilizada de manera rápida y efectiva. Por esta misma razón y el limitado espacio en pantalla, se prefiere evitar la necesidad de mostrar una ayuda en pantalla, el diseño de la interfaz de la aplicación puede recurrir a los con- troles estándar de la plataforma, con los cuales el usuario estará familiariza- do, disponiéndolos de una manera lógica y obvia, que lleve al usuario a intuir fá- cilmente el funcionamiento de la aplicación. Duración de la Interacción La interacción de los dispositivos móviles ocurre en intervalos de tiempo muy cortos y de manera paralela a las actividades cotidianas del usuario. Esto quiere decir que las aplicaciones móviles se usan mientras el usuario con- duce su automóvil44, usa el transporte público o espera formado en una lí- nea al borde de un aburrimiento paralizador y que por esta misma razón de- berán ser breves, rápidas y altamente funcionales ya que el usuario no tiene la capacidad de invertir mucha atención mientras las utiliza. Interacción Individual con las Aplicaciones El usuario de un dispositivo móvil utiliza una única aplicación a la vez mientras utiliza su dispo- sitivo. Aunque es posible que viaje entre una y otra, esta tarea esta aún lejos de ser igual de eficiente que una computadora de escritorio; este suplicio debe ser evitado a toda costa. Por ejemplo: que el usuario deba abrir una sesión de su explorador para registrarse en un for- mulario y después de eso, regresar a la aplicación en cuestión. 40 44 Se estima que 28% de los accidentes automovilísticos en EU están relacionados con el uso de teléfonos. Halsey III, Ashley. "28 percent of accidents involve talking, texting on cellphones" The Washington Post. 13 de Enero de 2010. Consultado el 4 de Marzo de 2011. <http://www.washingtonpost.com/wp-dyn/content/article/2010/01/12/AR2010011202218.html> http://www.washingtonpost.com/wp-dyn/content/article/2010/01/12/AR2010011202218.html http://www.washingtonpost.com/wp-dyn/content/article/2010/01/12/AR2010011202218.html Integración con el Sistema del Dispositivo Este punto apela al primer principio básico para el diseño de interfaces de usuario: consisten- cia. El usuario de un dispositivo móvil, estará familiarizado con los menús y ventanas que pre- sente su sistema operativo y la aplicación deberá intentar adaptar estos elementos y sus para- digmas dentro de ella con naturalidad. Poner poca atención a las características y lineamientos particulares de cada plataforma deja al usuario con una sensación inconsciente de que su apli- cación está pobremente desarrollada o incompleta. Medir Resultados: Tests de Usabilidad Una prueba de usabilidad intenta caracterizar el Look’n Feel de la aplicación y sus aspectos de uso desde el punto de vista del usuario. Por lo tanto estas pruebas (más correctamente valida- ciones), son subjetivas y varían entre usuario y usuario. A grandes rasgos, lo que esperarían evaluar es: 1. Facilidad de uso 2. Velocidad 3. Satisfacción visual (estética) Hacer un test de usabilidad a gran escala y de la forma tradicional es costoso y requiere un gran esfuerzo, pero existen formas alternativas de llevar a cabo “tests de usabilidad caseros” que mejorarán notablemente el resultado de cualquier aplicación. Basada en una descripción de David Barnard45, una guía rápida para realizar tests de usabilidad: 41 45 Mark, Dave. IPhone User Interface Design Projects. Estados Unidos: Apress. 2009. Capítulo 3. 1. Primero lo primero: hay que encontrar algunos usuarios de la plataforma para que analicemos los resultados que tienen nuestras interfaces sobre ellos46. Estamos buscando al usuario común de la plataforma, no un power-user o mucho menos al hacker experto que le ha hecho intrincadas modi- ficaciones al sistema operativo de su teléfono. Al mismo tiempo, estamos buscando usuarios que sean representativos del mercado al que nos estamos dirigiendo. Amigos, amigos de amigos o extraños con caras amigables en un restaurante de comida rápida usando un dispositivo de la plataforma en cuestión, son buenos sujetos para pruebas de usabilidad. Buena Idea: Nada mejor para despertar el interés de los sujetos de estudio que recompensar su participación con algún atractivo incentivo como: una copia gra- tuita del producto, cerveza gratis, una comida o tarjetas pre-pagadas para una al- guna tienda electrónica de música. 2. Encontrado algún sujeto de estudio, comienza la prueba de usabilidad. En este segundo paso se limitaría a presentarle la aplicación junto con una descripción breve de lo que hace y a explicarle que en la prueba no hay respuestas buenas o malas y que sus errores son valiosos para el resul- tado.
Compartir