Repositorio Institucional de Documentos

Proyecto Fin de Carrera Diseño e implementación de prototipo front end con estructura adaptativa para un portal de reserva de hoteles Autor Pablo Gil Torres Director Chris Anderson Ponente José Javier Merseguer Escuela de Ingeniería y Arquitectura 2014 Agradecimientos Quiero agradecer a mi familia su apoyo y comprensión durante este largo proceso. A José Merseguer por su apoyo, motivación y paciencia durante estos seis años. Y a Chris Anderson y BoomWorks por hacerme parte de su equipo y brindarme la oportunidad de llevar a cabo este proyecto. I Diseño e implementación de prototipo front end con estructura adaptativa para un portal de reserva de hoteles Resumen Este proyecto es producto de la respuesta de la empresa BoomWorks a las necesidades de la empresa Youth Hostelling Asociation Australia (YHA Australia). Estas necesidades son un rediseño de su web móvil para Australia y la creación de portales con la capacidad de realizar reservas para países del continente asiático. Ya que ambos proyectos eran similares en términos de funcionalidad y requisitos se decidió aunar los esfuerzos bajo una misma solución: Implementar un sistema basado en el diseño adaptativo con las mismas características y contenido a través de dispositivos. Debido a lo novel de la metodología de responsive design en 2012 y la falta de experiencia de BoomWorks con la misma en proyectos de larga escala, se decidió gestionar la parte de estructura, estilo y comportamiento de interacción de manera aislada y controlada, en un prototipo PHP. Este prototipo debía habilitar las siguientes funciones: ● Buscar un hotel. ● Inspeccionar habitaciones y tarifas en el hotel seleccionado. ● Seleccionar habitación o cama. ● Comprobar disponibilidad. ● Llevar a cabo la reserva. Los detalles concretos del sistema de plantillas incluyen:  Campo de búsqueda inteligente por geolocalización, sugerencias o cadenas de texto.  Utilidad dinámica de calendario para comprobar disponibilidad de fechas.  Gestión de mapas y localización de resultados.  Validación de formulario y habilitación de elementos de formulario HTML5  Compatibilidad con navegadores con soporte limitado.  Gestión de imágenes en entornos con resoluciones reducidas. II III Índice de contenidos Resumen ............................................................................................................................ I Introducción ...................................................................................................................... 1 1. Motivación y contexto del proyecto ......................................................................... 1 Diseño ............................................................................................................................... 5 1. Generación de requisitos y estrategia de implementación front end ........................ 5 2. Diseño de la arquitectura .......................................................................................... 7 2.1 Páginas y módulos del prototipo ........................................................................ 7 2.3 Estructura de la arquitectura de página............................................................. 11 2.4 Gestión de resoluciones de dispositivo ............................................................. 13 Implementación .............................................................................................................. 15 1. Campo de búsqueda ................................................................................................ 15 2. Calendario ............................................................................................................... 16 3. Gestión de mapas .................................................................................................... 18 4. Validación de formularios de la fase de reserva ..................................................... 20 5. Graceful degradation ............................................................................................. 22 6. Gestión de imágenes ............................................................................................... 24 7. Retos y problemas .................................................................................................. 25 Pruebas del sistema ......................................................................................................... 27 1. Estrategia ................................................................................................................ 27 2. Entorno de pruebas ................................................................................................. 27 3. Roles ....................................................................................................................... 27 4. Tipos de pruebas ..................................................................................................... 28 5. Problemas destacados ............................................................................................. 28 5.1 Comportamiento errático de la pantalla al interactuar con elementos de tipo input en Android 2.2 ............................................................................................... 28 5.2 Google Maps imposibilita la navegación de la pantalla en entornos móviles .. 29 5.3 Funcionalidad de restaurado de fechas en el calendario................................... 29 5.4 Aspect ratio en los carruseles de imágenes ...................................................... 30 Conclusiones ................................................................................................................... 32 1. Resultados obtenidos .............................................................................................. 32 2. Lecciones aprendidas .............................................................................................. 32 3. Líneas de trabajo futuras......................................................................................... 33 Anexos ............................................................................................................................ 35 Anexo A: Investigación de competidores móviles ..................................................... 35 Anexo B: Bocetos de wireframes móviles ................................................................. 40 IV B1 Resultados de búsqueda .................................................................................... 40 B2 Herramienta de filtrado ..................................................................................... 41 B3 Herramienta de búsqueda .................................................................................. 42 B4 Detalles de hotel ................................................................................................ 43 B5 Calendario ......................................................................................................... 44 B6 Herramienta de filtrado ..................................................................................... 45 Anexo C: Wireframes móviles ................................................................................... 46 C1 Map browse ....................................................................................................... 46 C2 String search ..................................................................................................... 47 C3 Calendar ........................................................................................................... 48 C4 Hostel details .................................................................................................... 49 C5 Select rooms and guests .................................................................................... 50 C6 Payment ............................................................................................................ 51 C7 Confirmation ..................................................................................................... 52 Anexo D: Wireframes de escritorio ............................................................................ 53 D1 Home ................................................................................................................. 53 D2 Map Search ....................................................................................................... 53 D3 String Search .................................................................................................... 54 D4 Hostel details .................................................................................................... 54 D5 Select Rooms ..................................................................................................... 55 D6 Select guests ...................................................................................................... 55 D7 Payment ............................................................................................................ 56 D8 Confirmation ..................................................................................................... 56 Anexo E: Diseños visuales móviles ........................................................................... 57 E1 Página de inicio ................................................................................................. 57 E2 Resultados de búsqueda por localización .......................................................... 58 E3 Resultados de búsqueda filtrados por disponibilidad ........................................ 59 E4 Calendario ......................................................................................................... 60 E5 Detalles de hotel ................................................................................................ 61 E6 Selección de habitación ..................................................................................... 62 E7 Selección de huéspedes ..................................................................................... 63 E8 Detalles de huésped y pago ............................................................................... 64 E9 Confirmación de la reserva ............................................................................... 65 Anexo F: Ejemplos visuales de resolución de escritorio y lenguaje japonés ............. 66 F1 Página de inicio ................................................................................................. 66 F2 Resultados de búsqueda por localización en lenguaje japonés ......................... 67 Anexo G: Distribución de horas de trabajo mensuales............................................... 68 V Referencias ..................................................................................................................... 70 4 5 Diseño 1. Generación de requisitos y estrategia de implementación front end La metodología adoptada por BoomWorks es el diseño iterativo centrado en el usuario [10]. Para el proyecto con YHA se realizó una ronda de análisis de negocio (business analysis) que consistió en entrevistas con los responsables del negocio, análisis de competidores y testeo de guerrilla con usuarios para validar los conceptos iniciales. A través de estas actividades preliminares se obtuvo una serie de requisitos de alto nivel y resultados deseados (outcomes) que fijaron la dirección del diseño. Una vez completado dicho diseño, y tras la consiguiente validación vía testeo de usuarios, se genera una serie de requisitos más concretos que describen las necesidades de la implementación. Requisitos funcionales: ● Buscar hoteles: El sistema permitirá al usuario realizar una búsqueda de hoteles por palabras clave sugeridas, geolocalización y entrada libre de texto. También permitirá buscar hoteles mediante selección de zona geográfica a través de un mapa. ● Seleccionar fechas: El sistema permitirá al usuario elegir las fechas de su estancia. ● Visualización de detalles de hotel: El sistema presentará al usuario una página con los detalles del hotel seleccionado. Dichos detalles incluirán la posición del hotel en un mapa de coordenadas, las características del alojamiento y puntuación y reseñas de viajeros. ● Selección de habitación: El sistema presentará al usuario las habitaciones disponibles basadas en las fechas introducidas y las características de las instalaciones. El sistema permitirá seleccionar una habitación al usuario. ● Introducción de número de huéspedes: El sistema permitirá introducir el número de huéspedes. El sistema permitirá introducir dichos datos en las categorías de miembro y no miembro y calculará el precio total correspondiente. ● Recopilación detalles de reserva: El sistema permitirá introducir los detalles necesarios para completar una reserva: ○ Detalles de huésped. ○ Detalles de huésped principal basados en el campo anterior. ○ Detalles de llegada. ○ Detalles de tarjeta de crédito. ● Validación del formulario: El sistema recogerá las entradas introducidas y las comprobará de acuerdo a las reglas del negocio. Si alguno de los valores no pasa la validación el sistema detendrá el proceso de pago y devolverá un mensaje de error, indicando los campos pertinentes. 6 Requisitos no funcionales: ● Diseño adaptativo: La página debe mantener la misma funcionalidad, adoptando el diseño visual pertinente dependiendo del dispositivo usado para acceder a la misma. La página debe hacer uso del mismo código independientemente de dicho dispositivo. ● Mapas: La página debe presentar los resultados de búsqueda y los detalles de hotel representados en Google Maps [11]. ● Gestión de interfaces de formulario nativos: En entornos móviles el sistema operativo debe ser el encargado de gestionar la entrada de datos. ● Gestión de idioma de página: El sistema debe habilitar mecanismos para actualizar toda referencia escrita al idioma de la página. ● Gestión de imágenes: El sistema debe ser capaz de referenciar tamaños máximos de imagen basados en la resolución de la página. ● Compatibilidad entre navegadores: Conforme a los interfaces para sistemas operativos para IE7+, Android 2.2+, iOS 5+ y navegadores modernos (Firefox, Chrome, Safari y Opera). La experiencia de BoomWorks con la tecnología de responsive design hasta el momento se había limitado a proyectos de pequeña envergadura y módulos promocionales de sitios existentes. Asimismo, como parte del proyecto YHA era necesario desarrollar funcionalidad back end desligada e independiente del componente de presentación. Por otro lado, y debido a la metodología de diseño iterativo seguida por BoomWorks, era posible obtener parte de los diseños de interfaz durante el ciclo de diseño sin que la estructura back end o la totalidad de los requisitos funcionales estuviese presente. Por lo tanto se decidió abordar la implementación de la página de la siguiente manera: El desarrollo back end en EKTRON (.NET) y el desarrollo front end se llevarían a cabo de manera independiente. Todos los componentes de parte cliente se desarrollarían como plantillas modulares en un prototipo en PHP y más tarde se integrarían en .NET. Esta decisión tenía como objetivo: ● Crear un entorno controlado para el desarrollo y testeo. El proyecto YHA exponía BoomWorks a campos poco explorados internamente. El diseño basado en responsive design era la piedra angular de la propuesta, cuyo peso caía casi enteramente en la parte del navegador. Tanto el estado de la tecnología responsive a través de diferentes navegadores de escritorio y móvil como las soluciones alternativas (fallbacks y polyfills) en 2012 estaban en proceso de maduración. El prototipo front end proveía un entorno de desarrollo con variables bajo control y eliminaba elementos de incertidumbre externos. ● Aprovechar al máximo la sinergia con el diseño iterativo. Secciones de la página podían empezar a ser desarrolladas sin esperar al conjunto de diseños ni al estado del back end. De la misma manera, las páginas completadas podían ser 7 utilizadas en testeo de guerrilla para ser validadas por usuarios a medida que se iban completando. ● Independencia de las restricciones del CMS. En proyectos al uso el sistema de gestor de contenidos (CMS) tiene una serie de mecanismos predefinidos para publicar y actualizar contenido que afectan a la estructura de la página. En un sistema adaptativo la estructura de la página es fundamental para la correcta visualización de diseños en diferentes resoluciones. Al desarrollar de los componentes back end para adaptarse a las plantillas construidas y validadas nos aseguramos de que la estructura del sistema no se vea comprometida. ● Mejor comunicación con el desarrollo back end. Al apartarse de la práctica tradicional de realizar el desarrollo de manera conjunta sobre el mismo conjunto de ficheros, se adoptó una estrategia de desarrollo modular basada en el formato de consumición óptima por parte del sistema EKTRON. 2. Diseño de la arquitectura Como se ha visto el procedimiento a seguir fue el de crear un prototipo en PHP para validar los elementos front end. Dicho prototipo no puede ser construido de manera arbitraria ya que ha de ser transportado al entorno EKTRON. El formato sugerido por los desarrolladores de back end fue el de componentes modulares, fácilmente convertibles en widgets. 2.1 Páginas y módulos del prototipo El prototipo se compone de las siguientes páginas. Secciones de búsqueda de hoteles: ● Homepage.php: Página de inicio. Contiene mapa de búsqueda por Estados (geolocalización) y carrusel con hoteles más populares. No contiene calendario. ● SearchResults.php: Página de resultados de búsqueda por geolocalización. Contiene mapa con markers de resultados. ● TextSearchResults.php: Página de resultados de búsqueda por entrada de texto. ● HostelDetails.php: Página de detalles del hotel. Contiene mapa con localización, reseñas de viajeros, detalles del hotel y carrusel con fotos de las instalaciones. Secciones de reserva de hotel (no contienen calendario): ● SelectRoom.php: Contiene los tipos de habitación disponibles para las fechas y el hotel elegidos. ● RoomSelected.php: Permite introducir el número de huéspedes y su estado de afiliación con YHA. Calcula el precio total a pagar. ● PaymentDetails.php: Recoge los datos de los huéspedes y de pago. 8 ● Confirmation.php: Página final del proceso. Informa al usuario de que la reserva se ha realizado con éxito, presenta datos de reserva, detalles del hotel y de contacto y mapa con la localización del hotel. Los diferentes componentes de las páginas se pueden diferenciar en tres tipos de módulos. Módulos de estructura: ● Header.php: Contiene la cabecera HTML y la cabecera de estructura de página. ● Footer.php: Contiene el pie de estructura de página, los scripts de JavaScript de página y los componentes no asociados a elementos (componentes dinámicos, pop-ups). ● Módulos de formulario de reserva: ○ ArrivalDetails.php ○ GuestDetails.php ○ MainContact.php ○ PaymentDetails.php ○ PaymentDetailsErrorOverview.php ○ SelectGuests.php ● ProgressBar.php: Contiene los pasos del proceso de reserva. Módulos funcionales: ● Map.php: Gestiona la presentación y funcionalidad de mapas Google Maps. ● Calendar.php: Gestiona la presentación y funcionalidad de selección de fechas. ● SearchByText.php: Gestiona la presentación y funcionalidad de la búsqueda de hoteles. Módulos de contenido: ● HostelDetails.php: Contiene los detalles del hotel. ● HostelOverview.php: Contiene los detalles principales del hotel. Nombre, precio, lugar. ● ImageRotator.php: Contiene las imágenes del carrusel. ● AvailabilityRoomList.php: Contiene las habitaciones disponibles para unas determinadas fechas y hotel. ● BookingDetails.php: Contiene los detalles de la reserva. Los módulos funcionales son acompañados por el script JavaScript que gobierna su comportamiento. En el caso de los otros módulos, si hay alguna interacción o funcionalidad menor gobernada por JavaScript ésta se incluye a nivel de página. En ambos casos el script PHP <?php scripts(); ?>, ejecutado al final de la página recoge las referencias a los scripts y los ejecuta en última instancia para optimizar la carga de la web [12]. 9 Así mismo, y en base a la funcionalidad en cuestión, el módulo puede necesitar parámetros para definir las particularidades de la situación y para adaptar elementos del lenguaje al idioma de la versión del sitio. Dichos parámetros se pasan como atributos del objeto global “YHAMobile” declarados localmente en el cuerpo de la página: <?php include 'modules/Map.php'; ?> <script> // Map data // User Control codebehind will generate this YHAMobile.mapData = [{ latlng : { lat: -32.9291279, lng: 151.7851346 }, infoWindow : '<p id="infoWindowContent"><a href="">Newcastle Beach</a><br>30 Pacific Street<br>Newcastle , 2300<br>(+612) 4925 3544</p>', id : 4294968358 }]; </script> Código 1 Ejemplo de paso de parámetros a la funcionalidad de módulo 2.2 Patrón de diseño Módulo en JavaScript El patrón de diseño Módulo [13] es un mecanismo conocido y extendido de encapsular funcionalidad de manera robusta, privada y modular en aplicaciones JavaScript. Fue creado por Richard Cornford en 2003 y popularizado por Douglas Cockford. El patrón Módulo se utiliza para simular funcionalidad de clase en el lenguaje JavaScript, que carece de la estructura de tipado fuerte de otros lenguajes. De esta manera JavaScript permite crear un objeto al que se le asignan variables y funciones de cariz privado y público. Las razones para adoptar dicho patrón son las siguientes: ● Protección mediante encapsulado: El patrón módulo nos permite encapsular la funcionalidad en su entorno de ejecución particular, protegiendo sus variables y funciones internas del resto de scripts presentes en la página. Esto se traduce en módulos independientes y que no entran en conflicto. ● Interfaz público: El control UpdatePanel [14] de .NET elimina los eventos JavaScript de sus elementos DOM asociados [15][16]. El patrón módulo permite exponer al entorno global variables y funciones al extender el objeto YHAMobile de tal manera que dichos eventos se pueden volver a asignar a la estructura web. 10 ● Importación: El objeto YHAMobile que actúa como patrón es declarado previamente en el cuerpo HTML. Dicho objeto se puede extender con atributos, que a su vez serán accesibles desde el interior del patrón, ya que la función de creación pasa el propio objeto YHAMobile como parámetro. ● Exportación y extensión: El patrón no sólo recoge el objeto YHAMobile declarado sino que le atribuye toda la funcionalidad expresada en su interior, y lo asigna a una variable global de su mismo nombre. En términos prácticos el objeto se ha actualizado con una serie de funciones y atributos, lo que permite un desarrollo modular de la funcionalidad, ya que el objeto no se destruye o sobrescribe sino que se extiende. El código que implementa el patrón descrito es el siguiente: var YHAMobile = (function(_this, $, window){ _this.initialise = function(){ $(function(){ _this.publicFunction(); }); return _this; }; _this.publicFunction = function(){ privateFunction(); }; var privateFunction = function(){ }; return _this.initialise(); })(YHAMobile || {}, jQuery, window); Código 2 Estructura de la implementación del patrón de diseño módulo 11 2.3 Estructura de la arquitectura de página La página sigue una estructura clásica de cabecera, cuerpo y pie. La filosofía seguida a la hora de presentar el contenido es utilizar una columna centrada con dos subcolumnas donde se reparte contenido y funcionalidad en la resolución de escritorio. Para la versión móvil dichas subcolumnas colapsan en un único componente central y la columna principal pierde sus propiedades como elemento fijador de anchura y adopta un comportamiento fluido. El patrón visual para los diferentes partes de la estructura de la página es mantener el estilo a lo largo de la anchura de la página. Para conseguir este efecto, los elementos correspondientes han sido envueltos en contenedores que abarcan el 100% de la extensión de la página. Figura 1 Esquema de la estructura de la página 12 Figura 2 Ejemplo de estilos extendidos a través de la anchura de la página La cabecera contiene dos conjuntos de elementos diferentes: El banner y logotipo de la página, y los pasos del proceso de reserva. También contiene la selección de idioma en la resolución de escritorio. Dicha selección desaparece entornos móviles y se transfiere al pie. Ya que esta recolocación de la funcionalidad es drástica en términos de posicionamiento dentro de la estructura de la página, la solución seguida es duplicar el elemento, dando la visibilidad a uno u otro elemento. Figura 3 Cabecera de escritorio El último elemento que contiene la cabecera es el del campo de búsqueda. El posicionamiento de este elemento en resoluciones de escritorio parece pertenecer al cuerpo principal de la página, junto con la funcionalidad de calendario. Sin embargo, su diferente naturaleza se hace patente en la versión móvil, donde aparece debajo del título de la página. Figura 4 Cabecera móvil El cuerpo de la página contiene la sección de calendario, que no está incluido en la columna principal al poseer características de estilo diferentes al resto de elementos. A continuación aparece el elemento contenedor columnWrapper, que fija el cuerpo en una resolución establecida para entornos de escritorio. En su interior los elementos se ordenan en las dos subcolumnas previamente mencionadas por medio de la propiedad CSS float [17]. Las clases columnLeft y ColumnRight establecen qué valor de la propiedad se aplica. 13 El pie de la página cierra la estructura, con un contenedor que aplica los estilos a lo ancho de la resolución. Como se ha mencionado anteriormente, el pie posee una versión de la funcionalidad para elegir idiomas, que aparece en entornos móviles en lugar de su equivalente en la cabecera. La página a su vez está envuelta en un elemento HTML form, para simular y adaptarse a las restricciones del entorno .NET en el que será construida. Dicha configuración es relevante ya que el lenguaje HTML no permite anidar elementos form [18], presentes en los pasos de reserva. 2.4 Gestión de resoluciones de dispositivo La propuesta principal de este proyecto es aunar bajo una misma base de código contenido y funcionalidad enfocado a dispositivos diferentes. El proyecto YHA tiene dos diseños de interfaz: ● Móvil: Diseñada para una anchura de 320px basada en el iPhone, con estructura fluida. Los elementos de la página se ensanchan para abarcar el ancho del dispositivo contenedor. ● Escritorio: Diseñada entorno a una columna central de 1024px de anchura. Estructura fija. Los elementos internos adoptan anchuras establecidas. Las resoluciones superiores a 1024px centran la columna y dejan espacio a los lados. Entre estos dos diseños se debía cubrir todo el espectro de resoluciones posibles. Dado que el diseño móvil está basado en una estructura fluida, se decidió llevar el umbral de las hojas de estilo a la resolución de escritorio y no al revés: /* Desktop */ @media only screen and (min-width: 1024px) { ... } Código 3 Ejemplo de break point para resolución de 1024px especificado con media queries 20 4. Validación de formularios de la fase de reserva Para la validación del formulario y la habilitación de atributos de HTML5 de formulario no soportados se utilizó el plugin de terceros h5validate [23] de Eric Elliot. Dicho plugin analiza los atributos de los elementos de formulario, les asigna parámetros de evaluación donde corresponda y captura el evento de envío del formulario para evaluar su validez. Figura 9 Detalle del formulario de pago En este caso el atributo HTML5 utilizado por defecto fue el de required, que indica que el campo debe contener información. Otros elementos requerían de condiciones de evaluación más robustas o situacionales. Cuando dicha condición podía ser expresada o recogida por una expresión regular, se utilizó el atributo HTML5 pattern al que el plugin daba soporte. 21 Condiciones más complejas, como la validez de la tarjeta de crédito, el género del huésped en relación al tipo de dormitorio elegido o la coincidencia de emails introducidos se implementaron específicamente, haciendo uso de la funcionalidad de inyección de funciones de validación personalizadas del plugin: ● cardNumber: valida el número de la tarjeta de crédito. ● securityCode: valida el código de seguridad de la tarjeta de crédito. ● expiryDate: comprueba la fecha de expiración. ● matches-prev: comprueba que el campo es igual al campo similar anterior. Utilizado para validación de direcciones de correo electrónico. ● room-age: comprueba que menores de 17 años no estén en habitaciones mixtas, ● room-gender: comprueba que los huéspedes no estén en habitaciones de género único distinto al suyo. Figura 10 Ejemplo de validación de formulario no superada La funcionalidad del módulo toma los siguientes parámetros: ● validationFormID: Indica que elemento es el responsable de recoger los valores del formulario. ● roomType: en la fase final de la reserva especifica qué tipo de habitación se ha elegido, seleccionada en el paso anterior. Se modificó el plugin h5validate para incluir la funcionalidad de asignar un elemento padre para el formulario, indicado con el valor de validationFormID, ya que las páginas .NET implementan el elemento form a nivel de página. 22 5. Graceful degradation Dado que la gran mayoría de los visitantes asiáticos --en especial China, que provee gran parte del segmento de mercado-- utilizan versiones antiguas de Internet Explorer se decidió desarrollar el proyecto con el soporte de IE7 y versiones superiores en mente. A través de la metodología conocida como Graceful degradation [24] se habilita un sistema para funcionar en otro con menos soporte de características, entendiendo que se llega a un compromiso y una serie de mínimos aceptables. Sin embargo, dichas versiones presentan una serie de problemas: ● Media queries: Las media queries, pieza fundamental de un sistema responsive, como hemos visto, no se introducen en Internet Explorer hasta su versión 9. Para subsanar el problema, la funcionalidad se simuló con herramientas de front end a través de la librería JavaScript css3-mediaqueries.js [25]. ● HTML 5: La mayoría de elementos semánticos HTML5 soportados por IE fueron introducidos también en su versión 9. Para hacer que dichos elementos fueran reconocidos por estos navegadores se utilizó la librería html5shiv [26]. Como medida adicional, se dotó de estilo de bloque a los nuevos elementos semánticos en el CSS y se reiniciaron sus estilos [27]. ● Gradientes y opacidad: Las versiones 8 y 7 de Internet Explorer no aceptan estilos CSS para gestionar las propiedades de CSS3 relativas a gradientes en las imágenes de fondo ni opacidad de elemento. Para replicar dicha funcionalidad se ha de hacer uso de filtros propietarios que invalidan el CSS estándar: .calendarFilter-overlay { filter: alpha(opacity=50); -msfilter:"progid:DXImageTransform.Microsoft.Alpha(Opacity=50)"; } Código 4 Ejemplo de filtro propietario de Microsoft para implementar transparencia en Internet Explorer ● Block-inline: Block-inline es un valor de la propiedad CSS display [28] que permite utilizar elementos de tipo bloque haciendo que se comporten y se alineen siguiendo las reglas de elementos de tipo línea. Esta propiedad tiene gran utilidad a la hora de posicionar elementos con objetivos estructurales y visuales. Sin embargo un conocido bug de IE7 impide ser presentado apropiadamente. Se resuelve con el siguiente hack: {display: inline-block; *display: inline!important; zoom: 1;} Código 5 Inline-block hack para dotar comportamiento inline-block a elementos en Internet Explorer 7 23 Las soluciones se incluyen en la página por medio de etiquetas HTML condicionales para separar los elementos no estándar del código general y preservar su integridad: <!--[if lt IE 9]><script src="js/html5-shiv.js"></script><![endif]--> <!--[if lte IE 8]><link rel="stylesheet" media="screen,projection" href="css/style_ie8.css"><![endif]--> <!--[if lte IE 7]><link rel="stylesheet" media="screen,projection" href="css/style_ie7.css"><![endif]--> Código 6 Ejemplo de hojas de estilo cargadas condicionalmente basadas en versiones de Internet Explorer 24 6. Gestión de imágenes En la implementación tradicional de responsive design se asigna propiedades de estructura fluida a las imágenes, que se encogen y ensanchan manteniendo su relación de aspecto. Sin embargo esto significa que las imágenes tienen que ser transferidas a la mayor resolución a la que puedan ser vistas para que no haya pérdida de calidad. En términos generales se intentó introducir imágenes con tamaños fijos y reducidos (i.e., miniaturas de resultados), pero las imágenes de los carruseles eran de una calidad y tamaño suficientes como para afectar de manera negativa la descarga y rendimiento de los dispositivos móviles. Por lo tanto se decidió tomar una solución combinada de front end y back end. Figura 11 Carrusel de página de inicio redimensionado para entornos móviles El sistema back end implementó una función que reescala una imagen basada en el atributo “query” de su dirección. El sistema front end recoge los elementos de imagen presentes en el carrusel, calcula la anchura de la página para el dispositivo en cuestión y reescribe el atributo src añadiendo el parámetro correspondiente como atributo de query. De esta manera la imagen descargada será de la resolución apropiada: $('#carrousel img').each(function () { var src = $(this).data('src'); $(this).attr('src', src + '?w=' + originalWidth); }); Código 7 Demonstración de la reescritura dinámica de la referencia a imágenes para adaptarlas a la resolución del dispositivo El sistema vuelve a realizar el cálculo si se produce un cambio de orientación en el dispositivo que da lugar a una mayor anchura de página. 25 7. Retos y problemas La dificultad del proceso de implementación fue fruto de la propia naturaleza de la metodología de diseño adaptativo. Según los requisitos no funcionales el sistema debía asegurar la integridad funcional y visual para IE7+, Android 2.2+, iOS 5+ y navegadores modernos (Firefox, Chrome, Safari y Opera) de sobremesa. En la práctica este requisito hacía necesario desarrollar para 12 navegadores a través de 5 entornos diferentes, 4 de ellos móviles:  Internet Explorer 7  Internet Explorer 8  Internet Explorer 9  Firefox  Chrome  Safari  Opera  Android 2.2.1  Android 2.3  Android 4.0.4  iOS 5  iOS 6 En este sentido se tuvo que llevar a cabo un exhaustivo ejercicio de disciplina y control. El desarrollo de elementos se realizó de manera progresiva a lo largo de los diferentes navegadores. Una vez finalizada la implementación de un componente se iteraban las implementaciones previas para controlar el impacto de los cambios introducidos. En los casos en los que las diferencias introducidas eran irreconciliables se realizaba una ponderación de los resultados obtenidos por navegador para llegar a una solución de compromiso. Este trabajo se vio acompañado por la necesidad de realizar sesiones específicas de investigación y estudio en detalle de las particularidades de los motores de presentación y las implementaciones de JavaScript a lo largo de los 12 navegadores, con el objeto de entender la raíz de las diferencias y encontrar la solución menos intrusiva a nivel de sistema para problemas específicos. Algunas de las soluciones adoptadas se han visto en el apartado anterior y una incidencia especialmente compleja se detalla en el apartado 5.1 de la sección “Pruebas del sistema”. En líneas generales es esta característica del proyecto la responsable por la complejidad, esfuerzo necesario y horas invertidas en el mismo. 26 27 Pruebas del sistema En este apartado se presenta el plan de pruebas utilizado para asegurar la calidad del producto final y su conformidad con los requisitos del sistema. 1. Estrategia Las pruebas de sistema se realizaron de manera progresiva a medida que las páginas y sus módulos asociados se iban completando. La validación se realizó a nivel de módulo, ya que varios de ellos aparecen a lo largo del portal y porque esa es la estructura utilizada por los desarrolladores back end para consumir las plantillas producidas. Por cada módulo a comprobar se realizaban pruebas en los diferentes entornos objetivo y sus correspondientes navegadores. Las pruebas se realizaron de manera manual, ya que las pruebas automatizadas no se acoplaban a la naturaleza dinámica del proceso de diseño y desarrollo. Al acabar el proceso de creación del prototipo se realizó otra serie de pruebas a nivel de portal para asegurar la consistencia y robustez de la solución. 2. Entorno de pruebas Para facilitar el proceso de prueba se habilitó un sitio web en el servidor de la compañía, BoomShed [29]. Los desarrolladores dispusieron de un entorno de trabajo local donde realizar pruebas y correcciones. Al acabar con un error, el código correspondiente se añadía al repositorio en BoomShed. El equipo de pruebas tenía a su disposición ordenadores equipados con versiones de los navegadores especificados en los requisitos y varios dispositivos móviles con las versiones correspondientes de iOS y Android. 3. Roles Los perfiles de los participantes en las pruebas del sistema son los siguientes: ● Desarrollador: El propio desarrollador del sistema realiza pruebas en su entorno local para comprobar que cumplen los requisitos. ● Diseñador visual: El diseñador visual del proyecto comprueba que las páginas producidas se adhieren a los estilos visuales. ● Diseñador de experiencia de usuario. El diseñador UX comprueba que los elementos funcionales se comportan de acuerdo al diseño y que el usuario puede realizar las tareas del sistema. ● Project manager: El project manager vela por la integridad de la solución a lo largo del sistema y comprueba que cumple con los requisitos del cliente. 28 4. Tipos de pruebas ● Pruebas unitarias: Para cada elemento funcional producido se ejecutaron diferentes escenarios de uso para comprobar que la multiplicidad de interacciones posibles no producía errores en el funcionamiento. ● Pruebas de integración: A medida que se completaban las pruebas unitarias se construían las páginas con los módulos funcionales correspondientes y se comprobaba que no se había comprometido la integridad de la página ni las distintas funcionalidades de los módulos. ● Pruebas de sistema: ○ Pruebas funcionales: Una vez completadas las pruebas de integración se recorrió el proceso de reserva de un hotel bajo varios escenarios para comprobar que los diferentes componentes no rompían el flujo de la reserva. ○ Pruebas no funcionales: Se realizaron pruebas de usabilidad, conformidad con el diseño visual, rendimiento de carga de imágenes y de traducción. 5. Problemas destacados 5.1 Comportamiento errático de la pantalla al interactuar con elementos de tipo input en Android 2.2 Problema: En móviles Android 2.2 la pantalla saltaba de lado a lado al interactuar con elementos de formulario HTML, haciendo imposible completar el proceso. Solución: El problema venía dado por la utilización de la propiedad CSS backface-visibility [30]. El rendimiento de una web con animaciones CSS3 mejora considerablemente si se utiliza el motor 3D hardware del dispositivo en lugar del motor nativo del navegador [31]. Para asegurarse de que la animación se realiza por hardware se añade al elemento a animar propiedades que utilicen dicho motor, pero de forma inocua. Las propiedades a utilizar por sus efectos a través de los diferentes navegadores son backface-visibility:hidden y translateZ(0). Sin embargo, en versiones Android 2.2 y anteriores el motor 3D contenía errores que daban lugar al comportamiento errático descrito [32]. En este caso el padre del formulario era un elemento compactor que hacía uso de animación al abrirse. La solución fue utilizar otras propiedades 3D, siendo translate3d(0,0,0) la que proporcionó el resultado deseado. 29 5.2 Google Maps imposibilita la navegación de la pantalla en entornos móviles Problema: Google Maps captura los eventos en el mapa en base a sus especificaciones de comportamiento. En entornos móviles dicho mapa abarca casi la totalidad de la pantalla y al interactuar con él, se mueve el interior del mapa y no la página. Esto dificulta mucho la navegación hacia partes inferiores de la página. Figura 12 Capa de protección para la interacción con Google Maps Solución: Se decidió crear una capa especial para entornos móviles que capturase la interacción con el elemento de manera natural. La capa en sí tiene un mensaje que informa al usuario de que debe hacer tap en el elemento si desea utilizar la funcionalidad de Google Maps. 5.3 Funcionalidad de restaurado de fechas en el calendario Problema: Al probar la funcionalidad del calendario desde distintos escenarios se comprobó que no era posible restaurar el filtrado por fechas. Solución: Se incluyó la funcionalidad para restaurar la selección de fechas, se posicionó un link en el calendario para activarla y se añadió el parámetro clearDates(response) como función callback para facilitar la gestión por parte del sistema back end. 36 BOOMWORKS.COM.AU 3 Search hostels and dates Both apps and mobile sites offer search by current location Most of the reviewed sites/apps lets users choose both place and dates before searching. We hostels and Airbnb allows a search for city and hostel before specifying dates. The Kayak interface has large buttons to add guests and rooms that are easy to interact with. A majority of sites/apps lets the user specify the check in and check out dates while others use arrival date together with number of nights BOOMWORKS.COM.AU 4 Search results The most common way to display hotels/hostels is a list with a small images together with some info and price. A couple of apps were a bit more engaging with the use of images, location and social media. Many sites/apps have filters and sorting available across the top. Airbnb have collected all filters in one button that opens up a new page. Both Hostelworld and Airbnb includes an indicator of reviews and ratings. Hostel world lets you “like” a hostel and save it for later. 37 BOOMWORKS.COM.AU 5 View The majority of apps/sites lets you flick through images horizontally in the hotel/hostel details. There is a mix of compactor, tabs and links to separate pages used for information, reviews and location. hostel details BOOMWORKS.COM.AU 6 Book rooms The apps/sites for hostels let you navigate the various rooms available before going ahead with the booking. We hostels lets you choose dates at this stage while users have to perform a new search in Hostelworld to change the dates. We hostels lets you choose the number of nights, but also reveals the departure date. 38 BOOMWORKS.COM.AU 7 Book rooms Hostel world separates personal details and payment details while we hostels shows everything on one page. Kayak hides information in compactors and users can easily go back and change information if needed. BOOMWORKS.COM.AU 8 Fun and engaging details The Hipmunk mascot does a little dance next to the progress bar while the app loads the search results onto the map We hostels focuses on social media and lets users chat with other users that have booked at the same hostel. They also have an animated menu that pops out when you press the pluss icon. Airbnb uses a large calendar that is easy to use for both check in and check out. You can save hotels to a shortlist by pressing a little heart in the Hotels.com application. 39 BOOMWORKS.COM.AU 9 Multi lingual support The images show how the interface can change drastically depending on language. Adding several tabs or buttons horizontally could present problems especially with languages like German where the words tend to be longer. 40 Anexo B: Bocetos de wireframes móviles El equipo de diseño de experiencia de usuario creó una serie de bocetos para demostrar la estructura y funcionalidad de la página. Estos bocetos se testearon con viajeros en hoteles de la cadena YHA para validar las propuestas. B1 Resultados de búsqueda 41 B2 Herramienta de filtrado 42 B3 Herramienta de búsqueda 43 B4 Detalles de hotel 44 B5 Calendario 45 B6 Herramienta de filtrado 52 C7 Confirmation 53 Anexo D: Wireframes de escritorio Los wireframes de escritorio se crearon a partir de los móviles, que sirven como base para documentar la estructura, progresión y funcionalidad. Los wireframes de escritorio describen la transición a la nueva resolución desde el los diseños móviles. D1 Home D2 Map Search 54 D3 String Search D4 Hostel details 55 D5 Select Rooms D6 Select guests 56 D7 Payment D8 Confirmation 57 Anexo E: Diseños visuales móviles Diseños visuales para el entorno móvil basados en los wireframes anteriores y preparados para ser utilizados en las plantillas. E1 Página de inicio 58 E2 Resultados de búsqueda por localización 59 E3 Resultados de búsqueda filtrados por disponibilidad 60 E4 Calendario 61 E5 Detalles de hotel 68 Anexo G: Distribución de horas de trabajo mensuales Horas de desarrollo fron end empleadas por el autor del proyecto. Septiembre 2012 Octubre 2012 Noviembre 2012 Diciembre 2012 Horas de trabajo 36.00 137.00 144.50 91.00 Total 408.50 69 70 Referencias [1] YHA Australia, 2014. Página oficial YHA Australia. http://www.yha.com.au/ [2] Hostelling International, 2014. Página oficial HI. https://www.hihostels.com/ [3] Jakob Nielsen, 2009. Página oficial de Nielsen Norman Group. http://www.nngroup.com/articles/mobile-usability-first-findings/ [4] Daniel Roberts, 2010. Página oficial de Usability.gov. http://www.usability.gov/getinvolved/blog/2010/05/mobile-device-usability.html [5] A List Apart, 2014. Página oficial A List Apart. http://alistapart.com/ [6] Ethan Marcotte, 2009. Página oficial A List Apart. http://alistapart.com/article/fluidgrids [7] Ethan Marcotte, 2010. Página oficial A List Apart. http://alistapart.com/article/responsive-web-design [8] W3C, 2012. Página oficial W3C. http://www.w3.org/TR/css3-mediaqueries/ [9] W3C, 2014. Página oficial W3C. http://www.w3.org/Style/CSS/Overview.en.html [10] ISO Standard 9241-210:2010. Página oficial ISO. http://www.iso.org/iso/catalogue_detail.htm?csnumber=52075 [11] Google Maps para desarrolladores, 2014. Página oficial Google Maps. https://developers.google.com/maps/ [12] Steve Souders, 2007. Página oficial Yahoo Developer Network. https://developer.yahoo.com/blogs/ydn/high-performance-sites-rule-6-move-scriptsbottom-7200.html [13] Addy Osmani (2014). Learning JavaScript Design Patterns Online Edition. ISBN: 978-1-4493-3486-4 http://addyosmani.com/resources/essentialjsdesignpatterns/book/#modulepatternJavaScr ipt [14] .Net Framework 4, 2007. Página oficial MSDN Library. http://msdn.microsoft.com/en-us/library/vstudio/bb399001(v=vs.100).aspx [15] Embedded JavaScript does not work after async postback from UpdatePanel. Respuesta en Stack Overflow. http://stackoverflow.com/questions/8092728/embeddedJavaScript-does-not-work-after-async-postback-from-updatepanel [16] Hajan Selmani, 2010. Weblog personal de Hajan Selmani http://weblogs.asp.net/hajan/make-them-to-love-each-other-asp-net-ajax-updatepanelsamp-JavaScript-jquery-functions [17] W3C, 2008. Página oficial W3C. http://www.w3.org/wiki/CSS/Properties/float 71 [18] W3C, 2011. Página oficial W3C. http://www.w3.org/TR/2011/WD-html520110525/forms.html#the-form-element [19] Plugin jQuery Autocomplete. Página oficial jQuery UI http://jqueryui.com/autocomplete/ [20] W3C, 2014. Página oficial W3C. http://www.w3.org/TR/geolocation-API/ [21] Plugin Moment. Página oficial Moment.js http://momentjs.com/ [22] Plugin Markerclusterer v3. http://google-maps-utility-libraryv3.googlecode.com/svn/trunk/markerclusterer/docs/reference.html [23] Plugin h5validate. http://ericleads.com/h5validate/ [24] Graceful degradation. Página oficial de Wikipedia http://en.wikipedia.org/wiki/Fault_tolerance [25] Plugin mediaqueries.js. https://code.google.com/p/css3-mediaqueries-js/ [26] Plugin html5shiv. https://code.google.com/p/html5shiv/ [27] Richard Clark, 2009. Página oficial HTML5 Doctor. http://html5doctor.com/html5-reset-stylesheet/ [28] W3C, 2011. Página oficial W3C. http://www.w3.org/TR/CSS21/visuren.html [29] Servidor BoomShed (root directory empty) http://boomshed.com/ [30] W3C, 2013. Página oficial W3C. http://www.w3.org/TR/css-transforms-1/ [31] Increase Your Site’s Performance with Hardware-Accelerated CSS. http://blog.teamtreehouse.com/increase-your-sites-performance-with-hardwareaccelerated-css [32] ANDROID BROWSER: Page scrolls to bottom when user focuses or types in an INPUT field that has parent with CSS value: -webkit-backface-visibility: hidden; https://code.google.com/p/android/issues/detail?id=13048 [33] Content Delivery Network. Página oficial Wikipedia http://en.wikipedia.org/wiki/Content_delivery_network [34] Window.matchMedia(), 2014. Pagina official Mozilla Developer Network https://developer.mozilla.org/en-US/docs/Web/API/Window.matchMedia