Patrones de Diseño.

Como se ha destacado anteriormente en este mismo libro, los patrones de diseño son un buen método para resolver pequeños problemas que pueden adaptarse a una variedad mucho más amplia de problemas específicos. En el contexto de los sistemas y aplicaciones basados en Web, los patrones de diseño pueden aplicarse en el nivel jerárquico, nivel de componentes y nivel de hipertexto (de navegación).

Cuando dentro de una WebApp se requiere la funcionalidad del proceso de datos, pueden aplicarse los patrones de diseño arquitectónicas a nivel de componentes propuestas por [BUS96], [GAM95] y otros. Los patrones de diseño a nivel de hipertexto se centran en el diseño de las características de navegación que permiten al usuario moverse por el contenido de la WebApp fácilmente. Entre muchos de los patrones de diseño de hipertexto propuestos en literatura sobre este tema se encuentran los siguientes :

Ciclo: una configuración que devuelve al usuario al nodo de contenido visitado anteriormente.

Anillo de Web: una configuración que implementa un «gran ciclo que enlaza hipertextos enteros viajando por un tema». 

Contorno: un patrón que aparece cuando varios ciclos inciden en otro, permitiendo navegar por rutas definidas por los ciclos.

Contrapunto: un patrón que añade comentarios de hipertexto interrumpiendo la narrativa del contenido para proporcionar más información o más indagación.

Mundo de espejo: el contenido se presenta utilizando diferentes hilos narrativos, cada uno con un punto de vista o perspectiva diferente. Por ejemplo, el contenido que describe una computadora personal podría permitir al usuario seleccionar una narrativa «técnica » o «no técnica» que describa la máquina.

Tamiz: una configuración que va guiando al usuario a través de una serie de opciones (decisiones) con el fin de llevar al usuario a un contenido específico e indicado por la sucesión de opciones elegidas o decisiones tomadas.

Vecindario: una configuración que abarca un marco de navegación uniforme por todas la páginas Web para permitir que un usuario tenga una guía de navegación consecuente independientemente de la localización de la WebApp.

Las configuraciones de diseño de hipertexto aue se han descrito anter iormente se pueden rekilizar a medida que el contenido va adquiriendo el formato que permitirá la navegación a través de una WebApp.

Diseño de navegación.

 
Una vez establecida una arquitectura de WebApp, una vez identificados los componentes (páginas, guiones, applets y otras funciones de proceso) de la arquitectura, el diseñador deberá definir las rutas de navegación que permitan al usuario acceder al contenido y a los servicios de la WebApp. Para que el diseñador pueda llevarlo a cabo, debe (1) identificar la semántica de la navegación para diferentes usuarios del sitio; y (2) definir la mecánica (sintaxis) para lograr la navegación. 

Generalmente una WebApp grande tendrá una variedad de roles de usuarios diferentes. Por ejemplo, los roles podrían ser el de visitante, cliente registrado ocliente privilegiado. Cada uno de estos roles se pueden asociar a diferentes niveles de acceso al contenido y de servicios diferentes. Un visitante puede tener acceso sólo a un contenido limitado, mientras que un cliente registrado puede tener acceso a una variedad mucho más amplia de información y de servicios. La semántica de la navegación de cada uno de estos roles sería diferente.

El diseñador de WebApps crea una unidad semántica de navegación (USN) para cada una de las metas asociadas a cada uno de los roles de usuario [GNA99]. Por ejemplo, un cliente registrado puede tener seis metas diferentes, todas ellas con un acceso a información y servicios diferentes. Para cada meta se crea una USN. Gnaho y Larcher [GNA99] describen la USN de la siguiente manera:

La estructura de una USN se compone de un conjunto de subestructuras de navegación que llamarnosformas de navegación [WoN (Ways of navigating)]. Una WoN representa la mejor forma de navegación o ruta para que usuarios con ciertos perfiles logren su meta o submeta deseada. Por tanto, el concepto de WoN se asocia al concepto de Perfil de Usuario. 

La estructura de una WoN se compone de un conjunto de nodos de navegación (NN) relevantes conectados a enlaces de navegación, entre los que algunas veces se incluyen las USNs. Eso significa que las USNs pueden agregarse para formar una USN de nivel superior, o anidarse en cualquier nivel de profundidad.

Durante las etapas iniciales del diseño de navegación, para determinar una o más WoNs para cada meta de usuario, se evaluará la estructura de la WebApp (arquitectura y componentes). Como se ha destacado anteriormente, una WoN identifica los nodos de navegación (por ejemplo, páginas Web), y entonces los enlaces que hacen posible la navegación entre ellos. La WoN entonces se organiza en USNs.

A medida que avanza el diseño, se va identificando la mecánica de cada enlace de navegación. Entre otras muchas opciones se encuentran los enlaces basados en texto, iconos, botones, interruptores y metáforas gráficas. El diseñador deberá elegir los enlaces de navegación adecuados para el contenido y consecuentes con la heurística que conduce al diseño de una interfaz de alta calidad.

Además de elegir la mecánica de navegación, el diseñador también deberá establecer las convenciones y ayudas adecuadas. Por ejemplo, los iconos y los enlaces gráficos deberán tener un aspecto «clickable (capacidad de accederse)» con los bordes biselados, y dar así una
imagen en tres dimensiones. La realimentación visual o de sonido se deberá diseñar para proporcionar al usuario una indicación de que se ha elegido una opción de navegación. Para la navegación basada en texto, se deberá utilizar el color que indica los enlaces de navegación
y proporcionar una indicación de los enlaces por los que se ha navegado. Estas son solo unas pocas convenciones de las docenas que hacen que la navegación por la red sea agradable. Además de las convenciones, en este punto también se deberán diseñar ayudas de navegación tales como mapas de sitios, tablas de contenidos, mecanismos de búsqueda y servicios dinámicos de ayuda.

Diseño de la interfaz.

 
Los conceptos, principios y métodos de diseños de interfaz que se presentaron en el Capítulo 15 son todos aplicables al diseño de interfaces de usuario para WebApps. Sin embargo, las características especiales de los sistemas y aplicaciones Web requieren otras consideraciones adicionales.

La interfaz de usuario de una WebApp es la «primera impresión». Independientemente del valor del contenido la sofisticación de las capacidades, los servicios de procesamiento y el beneficio global de la WebApp en sí, una interfaz con un diseño pobre decepcionará al usuario potencial y podrá de hecho hacer que el usuario se vaya a cualquier otro sitio. Dado el gran volumen de WebApps que compiten virtualmente en todas las áreas temáticas, la interfaz debe «arrastrar» inmediatamente al usuario potencial. Nielsen y Wagner sugieren unas cuantas líneas generales y sencillas en el rediseño de una WebApp:

Probabilidad de que los errores del servidor, incluso los más pequeños, hagan que el usuario abandone el sitio Web y busque información y servicios en algún otro sitio.

¿Cuáles son algunas de las líneas generales básicas para el diseño de la interfaz de un sitio Web?

La velocidad de lectura del monitor de una computadora es aproximadamente un 25 por 100 más lento que leer una copia impresa. Por tanto, no hay que obligar al usuario a leer cantidades voluminosas de texto, particularmente cuando el texto explica la operación de la WebApp o ayuda a navegar por la red. 

 
Evite los símbolos «bajo construcción» -levantan expectación y provocan un enlace innecesario que seguramente sea decepcionante.

 
Los usuarios prefieren no tener que recorrer la pantalla.Dentro de las dimensiones normales de una ventana del navegador se deberá incluir información importante.

Los menús de navegación y las barras de cabecera se deberán diseñar consecuentemente y deberán estar disponibles en todas las páginas a las que el usuario tenga acceso. El diseño no deberá depender de las funciones del navegador para ayudar en la navegación.

 
La estética nunca deberá sustituir la funcionalidad. Por ejemplo, un botón sencillo podría ser una opción de navegación mejor que una imagen o icono estéticamente agradables, pero vagos cuya intención no es muy clara.

Las opciones de navegación deberán ser obvias, incluso para el usuario casual. El usuario deberá buscar la pantalla para determinar cómo enlazar con otro contenido o servicio.

Una interfaz bien diseñada mejora la percepción del contenido o de los servicios del usuario que proporciona el sitio Web. No tiene que ser necesariamente deslumbrante, pero deberá estar siempre bien estructurada y ergonómica. 

¿Qué pasos hay que seguir para la comprobación de una WebApp?

El enfoque de las pruebas de las WebApps adopta los principios básicos de todas las pruebas del software (Capítulo 17) y aplica estrategias y tácticas que ya han sido recomendadas para los sistemas orientados a objetos (Capítulo 23). Este enfoque se resume en los pasos siguientes:

1. El modelo de contenido de la WebApp es revisado para descubrir errores. Esta actividad de <<prueba»se asemeja en muchos aspectos a la de un corrector ortográfico de un documento escrito. De hecho, un sitio Web grande tendrá la capacidad de construir un listado de los servicios de correctores profesionales para descubrir errores tipográficos, errores gramaticales, errores en la consistencia del contenido, errores en representaciones gráficas y de referencias cruzadas.

2. El modelo de diseño para la WebApp es revisado para descubrir errores de navegación. Los casos prácticos derivados como parte de la actividad de análisis permite que un ingeniero Web ejercite cada escenario de utilización frente al diseño arquitectónico y de navegación. En esencia, estas pruebas no ejecutables ayudan a descubrir errores en la navegación (por ejemplo, un caso en donde el usuario no pueda leer un nodo de navegación). Además, los enlenlaces de navegación (Sección 29.5.2) son revisados para asegurar su correspondencia con los especificados en cada USN del rol de usuario.

3. Se aplican pruebas de unidad a los componentes de proceso seleccionados y las páginas Web. Cuando lo que se tiene en consideración es el tema de las WebApps el concepto de unidad cambia. Cada una de las páginas Web encapsulará el contenido, los enlaces de navegación y los elementos de procesamiento (formularios, guiones, applets). No siempre es posible o práctico comprobar cada una de las caractensticas individualmente. En muchos casos, la unidad comprobable más pequeña es la página Web. A diferencia de la comprobación de unidades de software convencional, que tiende a centrarse en el detalle algorítmico de un módulo y los datos que fluyen por la interfaz del módulo, la comprobación por páginas se controla mediante el contenido, proceso y enlaces encapsulados por la página Web.

4. Se construye la arquitectura, se realizan las pruebas de integración. La estrategia para la prueba de integración depende de la arquitectura que se haya elegido para la WebApp. Si la WebApp se ha diseñado con una estructura jerárquica lineal, reticular o sencilla, es posible
integrar páginas Web de una manera muy similar a como se integran los módulos del software convencional. Sin embargo, si se utiliza una jerarquía mezclada o una arquitectura de red (Web), la prueba de integración es similar al enfoque utilizado para los sistemas OO. La comprobación basada en hilos (Capítulo 23) se puede utilizar para integrar un conjunto de páginas Web (se puede utilizar una USN para definir el conjunto adecuado) que se requiere para responder a un suceso de usuario. Cada hilo se integra y se prueba individualmente. La prueba de regresión se aplica para asegurar que no haya efectos secundarios. La comprobación de agrupamientos integra un conjunto de páginas colaborativas (determinadas examinando los casos prácticos y la USN). Los casos de prueba se derivan para descubrir errores en las colaboraciones.

5. La WebApp ensamblada se prueba para conseguir una funcionalidad global y un contenido. Al igual que la validación convencional, la validación de lossistemas y aplicaciones basados en Web se centra en acciones visibles del usuario y en salidas reconocibles para el usuario que procedan del sistema. Para ayudar en la derivación de las pruebas de validación, las pruebas deberán basarse en casos prácticos. El caso práctico proporciona un escenario con una probabilidad alta de descubrir errores en los requisitos de interacción del usuario.

La WebApp se implementa en una variedad de configuraciones diferentes de entornos y comprobar así la compatibilidad con cada configuración. Se crea una matriz de referencias cruzadas que define todos los sistemas operativos probables, plataformas de hardware para navegadores7 y protocolos de comunicación. Entonces se llevan a cabo pruebas para descubrir los errores asociados con todas y cada una de las configuraciones posibles.

La WebApp se comprueba con una población de usuarios finales controlada y monitorizada. Se selecciona un grupo de usuarios que abarque todos los roles posibles de usuarios. La WebApp se pone en práctica con estos usuarios y se evalúan los resultados de su interacción
con el sistema para ver los errores de contenido y de navegación, los intereses en usabilidad,
compatibilidad, fiabilidad y rendimiento de la WebApp. 

Dado que muchas WebApps están en constante evolución, el proceso de comprobación es una actividad continua, dirigida por un personal de apoyo a la Web que utiliza pruebas de regresión derivadas de pruebas desarrolladas cuando se creó la WebApp.