'...

MODELADO

DE DISEO:-PARA"
'f,

'P.UCACJONES WEB"

C'ONCEP'l'OS CLAVj! ..

..-w._ .._
. de

.s&6 .589

!lVC

caIdad _ .569
toI de .593

1alcl1 ..585

oisoio de CIIIIloaldo .584 oisoio de la i1torfat .5 73 ciseio de...-.gadn oisoio esttko MDtlOO IDtricus .. P"h-s .590 .582 595 .598

594

n su autorizado libro acerca del disefio Web. Jakob Nielsen [NIEOO) afinna: "'En esencia, existen dos enfoques bsiCos del disei\o: el ideal artlstico de expresarse uno mismo y el ideal.de ingenieria de resolver un problema para un cliente". Durante la primera dcada del desarrollo Web, la idea artstica.fue el enfoque que eligieron muchos desarrollador.es. El disefio'ocurri6 en una fonna ad hoc y-usualmente era dirigido confonne se generaba el HTML. El diseo evolucion de una visin artistica que en s misma evolucion6 'Confonne ocurri6 la construccin de la WebApp . Incluso en la actualidad, los defensores "radicales" del desarrollo de software gil (capitulo 4) utilizan las aplicacionesWeb como cartel de nios para "diseo limitado". Argumentan que la inmediatez y la volatilidad de las WebApps ate nan el diseo fonnal, que el diseo evoluciona confonne se construye (codifica) una aplicaci6n y que se debe gastar relativamente poco tiempo en la creaci6n de un modelo de diseo detallado. Este argumento tiene mrito. pero slo para WebApps relativamente simples. Cuando el contenido y la funci6n son complejos. cuando el tamao de la WebApp abarca cientos de objetos de contenido, funciones y clases de anlisis, cuando el xito de la WebApp tendr un impacto directo sobre el xito del negocio, el diseo no puede ni debe ser tomado a la ligera. Esta realidad conduce al segundo enfoque de Nielsen: "el ideal de ingeniera de resolver un problema para un cliente". La ingeniera Web adopta esta filosofia, y un enfoque ms riguroso del diseo WebApp pennite a los desarrolladores lograrlo.

Cuando se aplica el diseo dentro del contexto de la ingeriil1ria web, se deben considerar cuestiones tanto genricas como especficas. Desde un punto de vista genrico el diseo resulta en un modelo que guia la construccp de la WebApp. El modelo de ~iseo, Sin importar su forma, debe contener suficiente info~macin para reflejar cmo habrn de traducirse los requisitos de los particpanlfs (definidos en un modelo de anliSIS) en contenido y cdigo ejecutable. Pero el diseo tambin debe ser especifico. Debe abordar atributos clave de una WebApp en una forma que permita al ingeniero Web construir y ponerla a prueba de manera efectiva.

19.1.1 Diseo y calidad de una WebApp

En capitulas anteriores se seal que el diseo es la actividad de ingenieria que conduce a un producto de gran calidad. Esto conduce a una pregunta recurrente que se presenta en toda las discplinas de ingenieria: qu es calidad' En esta seccin se examinar la respuesta en el contexto de la ingenieria Web. Toda persona que haya navegado en la Web o usado una Intranet corporativa tie ne una opinin acerca de lo que hace una "buena" WebApp. Los puntos de vista individuales varian enormemente. Algunos usuarios disfrutan los grficos que bailan, otros quieren texto simple. Algunos solicitan infonnacin copiosa, otros desean una presentacin abreviada. A algunos les gustan las herramientas analiticas sofisticada~ o los accesos a las bases de datos. a otros les gustan las cosas simples. De hecho, la percepClon del usuario de lo que es "bueno" (y la resultante aceptacin o rechazo de la WebApp como consecuencia) puede ser ms importante que cualquier discusin tecnica de la calidad de la WebApp.

Pero cmo se aprecia la calidad de la WebApp? Qu atributos debe exhibir para loorar ser buena a los ojos de los usuarios finales y al mismo tiempo mostrar las cara~teristicas tcnicas de calidad que permitirn a un ingeniero Web corregir. adaptar, mejorar y apoyar la aplicacin a largo plazo? En realidad, todas las caractersticas generales de la calidad de software tratadas en los capitulos 9, 15 Y 26 se aplcan a la WebApps. Sin embargo, las ms relevantes de dichas caracteristicas -facilidad cia y facilidad de mantenimiento-de los sistemas basados en Web. 'Si los productos se disean poro encajar mejor en los tendencias naturales del comportamiento humano, entonal5~la genle estar mlSso1islerna, mll completo y ser ms produdivo. '. S.son Weiasdleak de uso, funcionalidad, confiablhdad. eficIenproporcionan una base til para valorar la calidad

Cules son los principales atributos de colidad poro los WebApps?

Seguridad.

Las webApps se han convertido en una parte integral de las bases de

datos cruciales del gobierno y las empresas. Las aplicaciones de comercio electrnico extraen y luego almacenan informacin confidencial de los clientes. Por stas y muchas otras razones, la seguridad de las WebApps es primordial en muchas situaciones. La medida clave de la seguridad es la habilidad de la WebApp y su ambiente de servidor de rechazar el acceso no autorizado e impedir un franco ataque malvolo. Un anlisis detallado de la seguridad WebApp est ms all del alcance de este libro. El lector interesado debe consultar [MCCO1J, [NOR02j o [KAL03j. Disponibilidad. Incluso la mejor WebApp no satisfar las necesidades de los

usuarios si no est disponible. En un sentido tcnico, la disponibilidad es la medida del porcentaje del tiempo que una WebApps est disponible para usarla. El usuario final comn espera que las WebApps estn disponibles las 24 horas de todos los dias del ao. Algo menos es considerado inaceptable.' Pero "a tiempo" no es el nico indicador de disponibilidad. Offutt [OFF02! sugiere que "usar caracteristicas disponiOlsina y sus colegas [OLS99J han preparado un "rbol de requisitos de calidad" que identifica un conjunto de atributos tcnicos -facilidad de uso. funclonalldad, confiabilidad. eficiencia y facilidad de mantenimiento-- que conducen a WebApps de oran calidad.' La figura 19.1 resume su. trabajo. Los criterios anotados en la figura ;on de particular inters para los ingenieros Web que deben disear, constrUir y mantener las WebApps a largo plazo. Offutt (oFF021 extiende los cinco principales atributos de calidad anotados en la bles slo en un navegador o una plataforma" hace que la WebApp no est dsponible para quienes tengan una configuracin de navegador y plataforma diferente. El usuario invariablemente se ir a otra parte. Escalabilidad. La WebApp y su ambiente de servidor pueden escalarse para ma-

nejar 100, 1 000, 10 000 o 100000 usuarios? La WebApp y los sistemas con los cuales est conectada manejan variaciones significativas en el volumen o la capacidad de respuesta caer catastrfica mente (o cesar por completo)? No es suficiente construir una WebApp exitosa. Es igualmente importante construir una WebApp que pueda acomodar el peso del xito (significativamente se todava ms exitosa. ms usuarios finales) y volver-

rbol de
Calidad de lo
aplicacin Web

figura 19.1 al agregar los atributos siguientes:

Comprensibilidad
Facilidad de uso ~

global del sitio

Tiempo

en el mercado.

Aunque en sentdo tcnico el tiempo en el mercado no

requisitos de calidad [OIS99].

Caractersticas de retroalimentacin en lnea y ayuda Caractersticas de lo interfaz y esttica Caractersticos especiales ________

es un verdadero atributo de calidad, es una medida de calidad desde un punto de vista de los negocios. La primera WebApp en el mercado usualmente captura un nmero desproporcionado de usuarios finales. Cientos de miles de pginas Web estn disponibles para quienes busquen informacin en la World Wide Web. Incluso las bsquedas Web mejor dirigidas resultan en una avalancha de contenido. Con tantas fuentes de informacin de las cuales elegir, cmo valora el usuario la calidad (por ejemplo, veracidad, precisin, integridad, oportunidad) del contenido que se presenta dentro de una WebApp? TiIlman [TILOO) sugiere un conjunto de criterios til para valorar la calidad del contenido: El mbito y la profundidad del contenido se pueden determinar con facilidad para asegurar que satisfacen las necesidades del usuario?

Funcionalidad

---=:==========-------~

Capacidades de bsqueda y recuperacin Caractersticos de navegacin y visualizacin

Caractersticos de la aplicacin relacionados con el dominio Correcto procesamiento de vnculos Recuperacin de errores . Validacin y recuperacin de entrado de usuario Desempeo en tiem~~ de res~u~sta de pagina de grficos

Eficiencia

--======---Rapidez

~-~

Rapidez de generaclon de generacin Fcil de corregir

Facilidad de
mantenimiento

_E:======_
~

Adaptabilidad Extensibilidad

Desde luego, esta expectativa Estos atributos lo tanto. de calidad son muy similares a los que se presentan son universales en los captulos 9. 15 Y 26. Por tividad" para reparaciones se deduce que las caracteristicas de calidad para todo el software.

es irreal.

Las grandes

WebApps

deben planificar

el "periodo

de inac-

y aaualizaciones.


Lista de verificacin
\....

19.1.2

Metas de diseo

de la calidad del diseo de la WebApp

Las tablas estn organizadas y dimensionados en uno forma que las hace camprensibles y que se desplieguen
eficientemente? El HTML est optimizado poro eliminor ineficiencias?

En su columna regular acerca del diseo Web, Jean Kaiser [KAl2] sugiere las siguientes metas de diseo, que son aplicables virtualmente portar el dominio, tamao o complejidad de la aplicacin: Simplicidad. Aunque pueda parecer pasada de moda, la expresin "todo con moa toda WebApp sin im-

~'"'"

La siguiente lista de verificacin, adaptada de la informacin presentada en webreference.

un conjunto de preguntas que ayudarn Web como o los usuarios finales a

ccm, proporciono

tonto a los ingenieros

valorar la calidad global de una WebApp:

El contenido, lo funcin o las opciones de navegacin

El diseo global de la pgina facilita la lectura y la navegocin?

Todos los punteros informacin vnculos) proporcionon vnculos con

deracin" se aplica a las webApps. Existe una tendencia entre algunos diseadores a proporcionar al usuario final "demasiado": contenido exhaustivo, efectos visuales extremos, animacin entrometida, enormes pginas Web, la lista es larga Es mejor luchar por la moderacin y la simplicidad. Consistencia. Esta meta de diseo se aplica virtualmente a cada elemento del

pueden ajustarse a las preferencias del usuario? El contenida a la funcianalidad se pueden personalizar
al ancho de banda en el cual se comunico el usuario?

interesante poro los usuarios?

los grficas y los otros medios que no son textuales se han usada de manera aprapiada2 El tamao de las archivos grficos est optimizado poro que se desplieguen con eficiencia?

Es probable que la mayaria de las vinculas persistan en la web2 La WebApp est instrumentoda can utilidades de gestin del sitio que incluyan herramientas poro rastrear su

modelo de diseo. El contenido se debe construir de manera consistente (por ejemplo, el formato del texto y los estilos de fuente deben ser los mismos a lo largo de todos los documentos de texto; el arte grfico debe tener una apariencia consistente, esquema de color y estilo). El diseo grfico (esttica) debe presentar una apariencia consistente en todas las partes de la WebApp. El diseo arquitectnico debe establecer plantillas que conduzcan a una estructura hipermedia consistente. El diseo de interfaz debe definir modos consistentes de interaccin, navegacin y despliegue de contenido. Los mecanismos de navegacin deben usarse de manera consistente a travs de todos los elementos de la webApp

usa, prueba de vinculas, bsqueda lacal y seguridad2

Qu se

debera :ansderar cuanla se valore el :antenido de eaidad?

Los antecedentes y la jerarquia de los autores del contenido se pueden identificar fcilmente? Esposible determinar la precisin del contenido, la ltima actualizacin y lo que fue actualizado? El contenido y su ubicacin son estables (es decir, permanecern en la URL de referencia)? Adems de estas preguntas relacionadas con el contenido, se pueden aadir las siguientes: El contenido es creible? El contenido es nico? Esto es, la WebApp proporciona algn beneficio nico a quienes la usen? El contenido es valioso para la comunidad de usuarios a que se dirige? El contenido est bien organizado? Est en un indice? Esfcilmente accesible? La lista de verificacin anotada en esta seccin slo representa una pequea muestra de los asuntos que deben abordarse conforme evolucione el diseo de una WebApp. Una meta importante de la ingenieria Web es desarrollar sistemas en los que se proporcionen respuestas afirmativas a todas las preguntas relacionadas con la calidad.

Identidad.

La esttica, la interfaz y el diseo de navegacin de una WebApp de-

ben ser consistentes con el dominio de la aplicacin para, la cual se va a construir. Un sitio Web para un grupo hip-hop indudablemente tendr una 'apariencia y un sentido diferente al de una WebApp diseada para una comp~ia de servicios financieros. La arquitectura de webApp ser completamente diferente, las interfases se construirn para acomodar diferentes categorias de usuarios, la navegacin estar organizada para lograr diferentes objetivos. Un ingeniero Web (y otros contribuyentes de diseo) deber trabajar para establecer una identidad para la WebApp por medio del diseo. Robustez. Con base en la identidad establecida, usualmente una WebApp hace

una "promesa" implicita al usuario. El usuario espera contenido y funciones robustas que sean relevantes para sus necesidades. Si dichos elementos estn perdidos o son insuficientes es probable que la WebApp fr.acase. Navegabilidad. Ya se ha sealado que la navegacin debe ser simple y consisten-

te. Tambin debe estar diseada de modo que sea intuitiva y predecible. Esto es, el usuario debe entender cmo moverse por la WebApp sin tener que buscar vinculas o instrucciones de navegacin. Apariencia visual. incuestionablemente De todas las categorias de software, las aplicaciones Web son las ms visuales, las ms dinmicas y sin duda las ms estti-

cas. Es indudable que la belleza (apariencia visual) est en el ojo del observador, pero muchas caracteristicas de diseo (por ejemplo, la apariencia y sentidJ del conteni-

do, la plantilla de la interfaz, la coordinacin del color, el equilibrio del texto, los grficos y otros medios audiovisuales, los mecanismos de navegacin) si contribuyen al aspecto, visual. compatibilidad. Una webApp se utilizar en una diversidad de ambientes (por

G~:~D:-------------

ejemplo, diferentes equipos, tipos de conexin a Internet, sistemas operativos, navegadores) y se debe disear para que sea compatible con cada uno. 'Para algunos, el disea Web se enfoca en la apariencia y sentido visuales ... para otros, el diseo Web trata de la eslruduracin de infannacin y la navegacin a Iravs del espacia del documenta. Otros indU5ll pueden ronsidefar que-. el disea Web trata acerca de la le<nologia empleada para construir aplicaciones Web interarnvas. En reolidtJd, el diseo induye todas estos factores y acoso ms.'

Thomas PoweI
Diseo de componentes
"...-"""- ...

,.

-....

... ...

-...~._------.. _ - ~~ ....

19.2

PIRMIDE

DEL DISEO

IWEB . 12 3
DISEO

tecn%go

Qu es diseo en el contexto de la ingenieria Web' Esta pregunta simple es ms dificil de responder de lo que uno puede creer. El diseo conduce a un modelo que contiene la mezcla adecuada de esttica, contenido y tecnologa. La mezcla variar depenl:liendo de la naturaleza de la WebApp, y, como consecuencia, las actividades de diseo tambin variarn. La figura 19.2 muestra una pirmide de diseo para la ingenieria Web. Cada nivel de la pirmide representa una de las siguientes actividades de diseo: Diseo de la interfaz: describe la estructura y organizacin de la interfaz del usuario. Incluye una representacin de la plantilla de pantalla, una definicin de los modos de interaccin y una descripcin de los mecanismos de navegalo IWeb oborco seis diferentes rtpos de diseo. Codo uno conlTibuyeo lo calidad global de lo WebApp. cin. Diseo esttico: tambin llamado diseo grfico, describe la "apariencia y sentimiento" de la WebApp. Incluye esquemas de color, plantilla geomtrica, tamao de texto, fuente y ubicacin, uso de grficos y decisiones estticas relacionadas. Diseo de contenido: define la plantilla, la estructura y el bosquejo de todo el contenido que se presenta como parte de la WebApp. Establece las relaciones entre los objetos de contenido. Diseo de navegacin: representa el flujo de navegacin entre los objetos de contenido y para todas las funciones de la WebApp. Diseo arquitectnico: identifica la estructura hipermedia global para la Dix [DIX99] argumenta que un ingeniero Web debe disear una interfaz de modo que responda tres preguntas primarias para el usuario final:

DE LA

INTERrAZ

DE' L'A

WEBApp3
debe pre-

Toda interfaz del usuario -ya

sea diseada para una webApp, una aplicacin de

software tradICional, un producto de consumo o un dispositivo industrial-

sentar las srgUlentes caracteristicas: fcil de usar, fcil de aprender, fcil de navegar, rntUltlva, conSIstente, eficiente, libre de errores y funcional. Debe ofrecer al usuario finalun~ experiencia satisfactoria y gratificante. Los conceptos, principios y mtodos de dIseno de la rnterfaz brindan al ingeniero Web las herramientas requeridas para lograr esta lista de atributos. En el capitulo 12 se observ que el diseo de la interfaz comienza no con una consideracin de la tecnologa, sino ms bien con un cuidadoso examen del usuario final. Durante el modelado de anlisis para la ingenieria Web (Capitulo 18). se desarrolla una jerarqUla de usuario. Cada categora de usuario puede tener necesidades sutllm~nte dIferentes, tal vez quiera interactuar con la WebApp en diferentes formas y qUlza requiera funcionalidad y contenido nicos. Esta informacin se deriva durante el anlisis de requisitos, pero se revisa como el primer paso en el diseo de la interfaz.

.-!~ Un silto es ~mente

"

uti~rzabIe pero carece de un esrtlo de diseo elegmrte y adecuada, fra~" ClIrt~er

WebApp. Diseo de componentes: desarrolla la lgica de procesamiento detallado que se requiere para implementar componentes funcionales. En las secciones que siguen se consideran con mayor detalle cada una de estas actividades de diseo.

La mayoria de, si no es que todas, las directrices presentadas en el capitulo 12 se aplican igualmente al dIseo de mterfases WebApp. Si todava no lee el capitulo 12, hgalo en este momento.

Dnde esloy' La interfaz debe 1) ofrecer una indicacin de que se ha tenido acceso a la WebApp' y 2) informar al usuario de su ubicacin en la jerarqua de conteSi es probable que los USlJanos puedan entror o su WebApp en varios ubicaciones y nrveles en lo erarquia de conTenido, asegrese de disear cado pgina con carocteris hcos de navegacin que conduzcan 01 USlJano o los ohas punfos de inTers. nido. Qu puedo hacer ahora' La interfaz siempre debe ayudar al usuario a entender sus opciones actuales: qu funciones estn disponibles, qu vinculos estn vivos, qu contenido es relevante. Dnde he estado, a dnde voy' La interfaz debe facilitar la navegacin. En consecuencia, debe proporcionar un "mapa" (implementado en una forma fcil de entender) de dnde ha estado el usuario y qu rutas puede tomar para moverse a cualquier parte dentro de la WebApp. La interfaz de una WebApp efectiva debe proporconar respuestas a cada una de estas preguntas conforme el usuario final navega a travs del contenido y la funcionaIidad. lo interfol de uno WebApp debe estor d, seodo poro ajustarse 01 conjunto de princ, pios anotados aqu.

y debe proporcionar facilidades de navegacin que permitan hacerlo s' J' . . In so lCllarJe al usuano una busque da de esta capacidad. Comuncacin. la interfaz debe comunicar el estado de cualquier actiVIdad que- haya iniciado el usuario. La comunicacin puede ser obvia (por ejemplo, un mensaje de texto) o sutil (por ejemplo, una hoja de papel que se mueva a travs de una impresora para indicar que Ja impresin est en camino). La interfaz tambin debe comunicar el estado del usuario (por ejemplo, la identificacin del usuario) y la ubicaclon dentro de la jerarquia de contenido de la WebApp. Consistencia: el uso de los controles de navegacin, mens, conos y esttica (por ejemplo, color, forma, plantilla) deben ser consistentes a travs de toda la WebApp Por ejemplo, si el texto subrayado de azul implica un vinculo de navegacin, el contenido nunca debe incorporar texto subrayado en azul que no implique un vinculo. Toda caracterstica de la interfaz debe responder en una forma que sea consistente con las expectativas del usuario." Autonoma controlada: la interfaz debe facilitarle al usuano el movimiento a travs de toda la WebApp, pero 10 debe hacer en una forma que refuerce las convenciones de navegacin establecidas para la aplicacin. Por ejemplo, la navegacin hacia porciones seguras de la WebApp se deben controlar con la identificacin del usuario y su contrasea, y no debe existir mecanismo de navegacin que permita al usuario dar la vuelta a dichos controles. i EjiClenclG: el diseo de la WebApp y su interfaz deben opumizar la ejiciencia laboral del usuario, no la eJiciencia del ingeniero Web que la disea y 1; construye o el ambiente cliente-servidor que la ejecuta. Tognozzi [TOGOJ J seiiala esto cuando escribe' "Esta simple verdad es por lo que es importante para todos los i~volucrados en un proyecto de software el apreciar la importancia de hacer propia la meta de productividad del usuario y entender la diferencia vital entre construir un sistema eficiente y fortalecer a un usuario eficiente." Flexibilidad: la inter(az debe ser lo su(icientementeJlexible como para permiur que al-

19.3.1

Principios y directrices del diseo de la intertaz

Bruce Tognozzi [TOGO1) define un conjunto de caracteristicas fundamentales que deben presentar todas las interfaces y, al hacerlo, establece una filosofia que debe seguir todo diseador de interfaz de WebApp: Las interfaces efectivas son visualmente aparentes e indulgentes, e implantan en sus usuariosunasensaci6ndecontrol.Losusuanosven rpidamentela envergadura desusopciones,comprendenc6mo lograr susmetasy hacensu trabajo Uno bueno interfol WebApp es comprens, ble e indulgente, y ofrece 01usuario uno sensacin de conlTol. Lasinterfacesefectivasno preocupanal usuario con los trabajosinternos del sistema. El trabajOse guardade manera cuidadosay continua. con la opci6n total de que el usuario deshagacualquieractividaden cualquiertiempo. LasaplicaCiones y serviciosefectivosreailzan un mximo de trabajo mientrasdemandan un mnimo de informaci6n a los usuanos. Con la finalidad de disear interfaces que muestren dichas caracteristicas, Tognozzi [TOGOJ J identifica un conjunto de principios de diseo primordiales:5 Anticipacin: una WebApp se debe disear de modo que anricipe el siguiente movimiento del usuario. Por ejemplo, considere una WebApp de soporte al cliente desarrollada para un fabricante de impresoras para computadora. Un usuano ha solicitado un objeto de contenido que presenta informacin acerca de un controlador de impresora para un sistema operativo lanzado recientemente. El diseador de la WebApp debe anticipar que el usuario pueda solicitar una descarga del controlador,

gunos usuarios r;alicen tareas directamente y otros exploren la WebApp en una lorma un tanto aleatoria. En todo caso, debe permitirle al usuario entender dnde esta \' ofrecerle la funcionalidad para que pueda deshacer los errores y volver a trazar la~ rutas de navegacin mal elegidas. Enfoque: la interfaz de la WebApp (Y el contenido que presenta) debe enrocarse en lals) tarealS) Importantels) para el usuario. En toda hipermedia existe una -tendencia para dirigir al usuario hacia contenido mal relacionado. Por qu'
j

Porque es muy

fcil hacerlo' El problema es que el usuario rpidamente se puede perder en muchas

4 Todas las personas han marcado alguna pagma ae un sitio Web. slo para volver de a visitarla mas tar-

y no lenel que dar indicaCIones del SitIO Web o del contexto de la pagina (as como para evitar
de Tognozzl se han aaaptado

capas de informacin de apoyo y perder el sitio del contenido original que quena en primer lugar.

moverse hdcla otra ublCaClon dentro del SItIOI Los pnnclplOs ongmales este libro

y extendido con el fm de aprovecharlos

en

Tognozzl

fTOGOl1 seala que la unlca forma de garantIzar es medIante

que las expectatIvas

del usu.:..n,) se com-

Vease TOGOI] para mayores detalles acerca de estos pnnclplos

prendan adecuadamente

una amplia prueba por parte del usuario (cap; .. 10201

Ley de F/(1: 'EI tiempo para adquirir

un objetivo es una funCin

de la distanCia a la que der

Metforas.

una inteifaz

que ucilice una metfora

de mteraccin

es ms fcil de apren-

se halla y de su tamao' [TOGO11.Con base en un estudio realizado en la decada de 1950 [FIT541. la ley de Fitt "es un mtodo efectivo de modelar rapldos mOVimientos dirigidos. donde un apndice (como una mano) parte del reposo en una poslclon de inicio especifica y se mueve hacia el reposo dentro de unaarea estableCida como objetivo" [ZHA02]. Si una tarea del usuario define una secuenCiade selecciones o entradas estandarizadas (con muchas opciones diferentes dentro de la secuencia). la pnmera seleccin (por ejemplo, seleccin de ratn) debe estar fisicamente cerca de la siguiente seleccin. Por ejemplo. considere la interfaz de la pgina de inicio de una WebApp en un sitio de comercio electrnico que vende aparatos electrodomsticos. . Cada opcin del usuario implica un conjunto de elecciones o acciones de segUimiento del usuario. Por ejemplo. una opcin "comprar UJl,producto" reqUiere que el usuario ingrese una categora de producto seguida por el nombre de ste. La categoria del producto (por ejemplo, equipo de audio. televisores. repro~uctores de DVD) aparece como un men desplegable tan pronto como se selecCiona comprar ,un producto". En consecuencia, la siguiente eleccin es inmediatamente obvia (esta cerca)
I 'dOO ' Uoo biJsQuedc en 1, Web desrubrinl mu<hos lilrel!<lsdispooibles; por ejemjlkl. pequel". intellles y doses JlMl A~ en jav . lOlII ,COM, OCOM y librerlos ripo en msdR.Miaosoft.
(011\.

de usar, en tanto la meefora sea apropiada

para la aplicacin

el usuario.

Una

metfora debe llamar imgenes y conceptos de la experiencia del usuario. pero no necesita ser una reproduccin exacta de una experiencia del mundo real. Por ejemplo, un sitio de comercio electrnico que implementa el pago de cuentas automatizado para una institucin financiera usa una metfora de lista de verificacin (no de manera sorprendente) para asistr al usuario en la especficacin y la calendarizacin de los pagos de cuentas. Sin embargo, cuando un usuario "escribe" un cheque. no necesita ingresar el nombre completo del pagador sino que puede elegr de una lista de pagadores o hacer que el sistema seleccione con base en las primeras letras escritas. La metfora permanece intacta. pero el usuario obtiene asistencia de la WebApp.
Mantener una forma ~ON5EJO. la integridad del producto de trabajo. Un producto de trabajo (por ejemplo,

completada

por el usuario,

una lisea especificada

por el usuario) debe guardar-

se de manera automcica de modo que no se perder si ocurriese un error. Todo mundo ha experimentado la frustracin asociada con el hecho de completar un gran formulario WebApp slo para que el contenido se pierda debido a un error (que comete el usuario, la WebApp o la transmisin de cliente a servidor). Para evitar esto la WebApp se debe disear para autoguardar todos los datos especificados por el usuario.
Legibilidad: ra jvenes toda la informacin presentada a travs de la inteifaz debe ser legible pa-

y el tiempo para adquirir es despreciable. Si. por otra parte. la eleccin aparece en un men ubicado en el otro lado de la pantalla, el tiempo para que el usuano lo adquie~a (y ruego realice la eleccin) ser demasiado.
Objetos de interfaz humana: Se ha desarrollado una gran librera de objetos de in terfaz hUn1ana re utilizables para WebApps. selas. Es posible adquirir, de vanas librenas

La metforas san uno idea excelente parque reReion lo experiencia del mundo real. Slo se debe aseguror que lo meroforo que se el~ ;0 es bien conocido entre los usuorios finales.

viejos. El diseador de la interfaz debe enfatizar los estilos de letra legi-

ble. tamaos de fuente y opciones de fondo de color que mejoren el contraste.

Estado de rastro: Cuando sea adecuado, rastrearse el estado de la interaccin del usuario debe

de objetos, cualquier objeto de interfaz que pueda ser "ViStO,escuchado, tocado o de algn otro modo percibido" [TOGOI1 por un usuario final.
Reduccin de latencia: Ms que obligar descargar al usuario a esperar eI)in de alguna operacin interna (por ejemplo, la multitarea operacin en una forma una imagen gr)iea compleja), al usuario proceder la WebApp debe usar como s/ la

almacenarse

de modo que un usuario pueda salir

regresar ms tarde allu-

gar de donde sali. En general. las cookies

se pueden disear para almacenar infor-

macin de estado. Sin embargo. las cookies son una tecnologa controvertida. y otras soluciones de diseo pueden ser ms aceptables para algunos usuarios.
Navegacin que los usuarios visible: una inteifaz estn en el mismo de WebApp bien diseada lugar, proporciona "la ilusin de

que permita

con el trabajo

hubiese sido completada.

Adems de reducir la late.ncia, las demoras deben de audo (por ejemplo, un "clic" o campanada)

reconocerse de modo que el usuario comprenda lo que esta ocumendo. Esto mcluye 1) proporcionar retroalimentacin cuando una seleccin no genera una accin inmediata de la WebApp; 2) desplegar un reloj animado o barra de progreso para indicar que el procesamiento esta en .marcha; 3) ofrecer algn entretenimiento (por ejemplo, una antmaClon o presentaClon de texto) mientras ocurra un procesamiento largo. 'S mejorvioje es el que tiene el menor nmero de pasos. Acorte lo distoncio entre el usuorioy su mefa.-~o

que se les lleva el trabajo hasta sus lugares"

[TOGO11.Cuando se usa este enfoque la navegacin no es preocupacin del usuario. En lugar de eso, el usuaro recupera objetos de contenido y selecciona funciones que se despliegan y ejecutan por medio de la interfaz.

Facilidad

de aprendizaje:

La inteifaz

de una WebApp reducir

se debe

disear para minimizar requend~ cuan-

el tiempo de aprendizaje y, una vez aprendido,

el reaprendlzaJe

do se vuelve a visitar la WebApp. En general, la interfaz debe acentuar u,n diseno sim-

ple e intuitivo que organice el contenido y la funcionalidad en categonas obvias para el usuario.

nibles para el usuario. El diseo no debe descansar en las funciones del navegador para asistir en la navegacin. La esttica nunca debe sustituir la funcionalidad. Por ejemplo, un simple botn puede ser una mejor opcin de navegacin que una imagen o un icono estticamente placenteros pero vagos, cuya intencin no es clara. Las opciones de navegacin deben ser obvias, incluso para el usuario casual. El usuario no debe tener que buscar en la pantalla para determinar cmo vincularse con otro contenido o servicio. Una interfaz bien diseada mejora la percepcin del usuario del contenido o servicios que proporciona el sitio. No necesariamente tiene que ser ostentosa, sino que siempre debe estar bien estructurada y ergonmicamente saludable. 'Lo gente tiene muy JlOlIIpodendo Ion los sitiosWWW pobremente diseados.' . ; ~.

JakobIfI8lsen y -.ne

W.

;;

Los objetivos de la interfaz de una WebApp son)) establecer una ventana consistente con el contenido y la funcionalidad que proporciona, 2) guiar al usuario a travs de una serie de interacciones con la WebApp, y 3) organizar' las opciones de navegacin y el contenido disponible para el usuario. Lograr una interfaz consistente requiere que el diseador use primero el diseo esttico (secc;n 19.4) con el fin de establecer una "apariencia" coherente para la interfaz. Esto abarca muchas caracteristicas, pero debe subrayar la plantilla y la forma de los me()Qnismos de navegacin. Para guiar la interaccin del usuario. el diseador de la interfaz puede emplear una metfora apropiada: que permita al usuario adquirir una comprensin intuitiva de la interfaz. Las opciones de navegacin las implementa el diseador seleccionando de entre varios mecanismos de interaccion: Qu melanismos de nleralln esln disponibles pora los diseodores de WebApps?

Nielsen y Wagner [NIE96] sugieren unas cuantas directrices pragmticas en el diseo de interfases (basados en su rediseo de una gran WebApp) que proporcionan un buen complemento a los principios sugeridos prrafos atrs en esta seccin: La rapidez de lectura en un monitor de computadora es aproximadamente 25 por ciento ms lenta respecto de la lectura en impresos. En consecuenCia, no fuerce al usuario a leer voluminosas cantidades de texto, en partICular cuando se explica la operacin de la WebApp o se ofrece ayuda en la navegacin. Evite los signos de "en construccin", crean expectativas y provocan un vinculo innecesario que es seguro para la decepcin. Los usuarios prefieren no desplazarse. La informacin importante debe estar dentro de las dimensiones de una ventana tipica de navegador.

Mens de navegaCin. menus clave (organizados vertical u horizontalmente)

que mencionan contenido o funcionalidad clave. Dichos mens se pueden implementar de modo que el usuario pueda elegir de una jerarquia de subtemas que se despliegan cuando se selecciona la opcin de men primario

leonos grficos.' botn, interruptores e imgenes grficas similares que permiten al usuario seleccionar alguna propiedad o especificar una decisin.

Imgenes grficas. alguna representacin grfica que el usuario pueda seleccionar y que implemente un vnculo hacia un objeto de contenido o funcionalidad de la WebApp.
unil re~resentaclOn (extrada de la expenenc12 del mundo real del
de la mterfaz Un ejemplo sjmpl
p

En este contexto,

una mel%ra

es

Los mens de navegacin y los encabezados deben estar diseados de manera consistente y deben estar disponibles en todas las pginas que esten dlspo-

usuariO) que puede modelarse Interruptor deshzable

dentro del contexto

p'Jede ser un

con que se controla el volumen auditivo de un archivo

.mp'::

Es importante anotar que uno o ms de dichos mecanismos de control debe proporcionarse en cada nivel de la jerarquia de contenido. 19.3.3, Flujo de trabajo en el diseo de la interfaz Aunque un anlisis detallado del diseo de la interfaz para WebApps es mejor dejarlo a libros de texto que se dedican a la materia (por ejemplo, [GAL02], [RASOO]o [NIEOOJ), vale la pena echar un vistazo a las tareas de diseo clave. En el capitulo 12 se seal que el diseo de la interfaz del usuario comienza con la identificacin de ste, la tarea y los requisitos ambientales. Una vez que se han identificado las tareas del usuario, se crean y analizan sus escenarios (casos de uso) para definir un conjunto de ubjetos y acciones de interfaz. Este trabajo se representa como parte del modelo de anlisis de la webApp tratado en el capitulo 18. Las siguientes tareas representan un flujo de trabajo rudimentario para el diseo de la interfaz WebApp. l. Revisar la informacin conforme 2.' Desarrollar se requiera. un bosquejo aproximado de la plantilla de la interfaz de la contenida en el modelo de anlisis y refmarla

3. Correlacionar interfaz.

los objetivos del usuario con acciones especificas de la

Para la gran mayoria de las WebApps, el usuario tendr un conjunto

relativamente primario de objetivos primarios (usualmente entre cuatro y siete). stos deben correlacionarse con acciones especficas de la interfaz, como se muestra en la figura 19.3. 4. Defmir un conjunto de tareas de usuario que estn asociadas con cada accin. Cada accin de la interfaz (por ejemplo, "comprar un producto") est asociada con un conjunto de tareas de usuario. Dichas tareas se identificaron durante el modelado de anlisis. Durante el diseo deben correlacionarse interacciones especificas que abarquen asuntos de navegacin, objetos de contenido y funciones WebApp. 5. Elaborar bosquejos con imgenes de la pantalla para cada accin de la interfaz. Conforme se considera cada accin, se debe crear una secuencia de imgenes en bosquejo (imgenesde pantallas) para esbozar cmo responde la interfaz a la interaccin del usuario. Se deben identificar los objetos de contenido (incluso si todavia no se disean ni desarrollan), se debe mostrar la funcionalidad de la WebApp y se deben indicar los vnculos de navegacin. 6. Refmar la plantilla de la interfaz y los bosquejos con el uso de entradas desde el diseo esttico. La plantilla aproximada y los bosquejos los completan los ingenieros Web, pero la apariencia y la percepcin esttica para un gran sitio comercial con frecuencia los desarrolla un artista, en lugar de profesionales tcnicos. 7. Identificar los objetos de la interfaz del usuario que se requieran para Esta tarea puede requerir una bsqueda en una Iibreria de implementarla.

'webApp. Como parte de la actividad de modelado del anlisis se pudo haber desarrollado un prototipo de la interfaz (que incluya la plantilla). Si ya existe la plantilla, debe revisarse y refinarse conforme se requiera. Si no se ha desarrollado la plantilla de la interfaz, el equipo de ingenieria Web debe trabajar con los participantes para desarrollarla en este momento. En la figura 19.3se muestra una primera versin de un bosquejo de plantilla.

objetos existente para encontrar aquellos objetos reutilizables (clases)apropiados para la interfaz de la WebApp. Adems, en este momento se especifican cualesquiera clases de personalizacin. 8. Desarrollar una representacin de procedimiento de la interaccin del usuario con la interfaz. Esta labor opcional usa diagramas de secuen-

Correlacin de los objetl vos del usua rio en las ac ciones de la lnlerlaz.

Borro de men de funciones principales

cia UML o diagramas de actividad (estudiados en el capitulo 18)para esbozar el flujo de actividades (y decisiones) que ocurren conforme el usuario interacObie~vo #1 Objetivo #2 Objetivo #3 Objetivo #4Objetivo #5

ta con la WebApp. 9. Desarrollar una representacin del comportamiento de la interfaz. Esta tarea opcional utiliza diagramas de estado UML (estudiados en el capitulo 18)para representar las transiciones de estado y los eventos que las causan. Se definen los mecanismos de control (es decir, los objetos y acciones disponibles con que el usuario altera el estado de una WebApp). 10. Describir
Men de navegacin

la plantilla

de la interfaz para cada estado. Con el uso de la

informacin de diseo desarrollada en las tareas 2 y 5, se asocia una plantilla especfica o imagen de pantalla con cada estado de la WebApp descrito en la tarea 9.

11. Refinar y revisar el modelo de diseo de la interfaz. La revisin de la interfaz se debe enfocar en la facilidad de uso (capitulo 12). Es importante notar que el conjunto de tareas finales que haya elegido un equipo de ingenieria Web se debe adaptar a los requisitos especiales de la aplicacin que se va a construir.

jo a la derechaS Si los elementos de plantilla tienen prioridades especificas, los elementos de mayor prioridad deben colocarse en la porcn superior izquierda de la pgina bien inmueble.
Agrupar navegacin, contenido

y funcin

geogrjicamente

dentro

de la pgina.

Los

humanos buscan patrones vrtualmente en todas las cosas. Si no existen patrones discemibles dentro de una pgina Web, es probable que aumente la frustracin del usuario (debido a la bsqueda innecesara de la informacin requerida).

El diseo esttico, tambin llamado diseo grjico,

NollXloir,efreroWeb lo ir,efrero de softwote} 1iooe1lientrJ0I1is1ico lesIroJ). Si seesJ en estuaJl1!lpkJ,coofTtese lJ1 ctefcxJcx grfico

es un esfuerzo artstco que com-

No extender el bien inmueble

con la barra de desplazamiento.

Aunque con frecuen-

plementa los aspectos tcnicos de la ingenieria Web. Sin l, una webApp puede ser funcional, pero sin atractivo. Con l, una WebApp lleva a sus usuarios a un mundo que los incluye en un mbito tanto emocional como intelectual. Pero, qu es esttica? Existe un viejo dicho: "la belleza existe en los ojos de quien la ve". Esto es particularmente apropiado cuando se considera el diseo esttico para las WebApps. Para realizar un diseo esttico efectivo, de nuevo se regresa a la jerarqua de usuarios desarrollada como parte del modelo de anlsis (captulo J 8) Y se pregunta quines son los usuarios de la WebApp y qu "apariencia" desean.

cia el desplazamiento es necesario, la mayoria de los estudos indican que los usuarios preferirian no desplazarse. Es mejor reducir el contenido de la pgina o presentar el contenido necesario en varias pginas.
Considerar la resolucin

el tamao de la ventana de navegador

cuando disee planti-

llas. En vez de definir tamaos fijos dentro de una plantilla, el diseo debe especificar

todos los artculos de la plantilla como un porcentaje del espacio disponible [NIEOO].

expeti'nemrxlo XIO el trofxp de seiio esttico.

19.4.2 Cuestiones de diseo grfico

El diseo gr~(ico considera cada aspecto de la presentacin y percepcin de una WebApp. El proceso de diseo grfico comienza con la plantilla (seccin 19.4.1) Y

"Encontramos que lo gente rpidamente evalo un sitio slo por su diseo visuaL" Directrices Slanford para la credibilidad en la Web

procede hacia la consideracin de esquemas de color globales, tipos de fuentes, tamaos y estilos, el uso de medios audiovisuales complementcirios (por ejemplo, audio, video, animacin) y todos los dems elementos estticos de una aplicacin. El lector interesado puede obtener Sugerencias y directrices de 'diseo en muchos sitios web que se dedican al tema (por ejemplo, www.graphic-design.com, ticdesgns.com, www.wpdfd.com) BAGO!], ICLOOlj o IHEI02]). o de una o ms fuentes'impresas www.grantas(por ejemplo,

19.4.1 Cuestiones de la plantilla

Toda pgina Web tiene una cantdad limitada de "bien inmueble" que puede usarse para dar soporte a la esttica no funcional, caractersticas de navegacin, contenido de informacin y funconalidad dirigida al usuario. El "desarrollo" de este bien inmueble se planea durante el diseo esttico. Al gual que las cuestiones estticas, no existen reglas absolutas cuando se disea una plantilla de pantalla. Sin embar!l0' vale la pena consderar algunos lineamientos generales de plantilla:
No temerle al espacio vacio. No es aconsejable rellenar cada centimetro cuadrado

Sitios Web bien diseados

En ocasiones, lo mejor forma de comprender el buen diseo de los WebApps es observar unos cuantas ejemplos. En su articula "The Tap Twenty Web Design Tips" (Los mejores 20 sugerencias poro el diseo Webl, Marcelle Toor (hltp://www.graphic-design.cam/ Web/feature/tips.htmll sugiere las siguientes sitias Web cama ejemplos de buen disea grfica:

~~

www.pbs.org/riverofsong: serie de televisin poro lo radio y la televisin pblicos acerco de lo msica estadounidense www.RKDINC.cam: firma de diseo con un portafolios en lneo y buenos sugerencias de diseo. www.commorts.com/career/index.html: revista Communicotion Arts, una publicacin peridico poro diseado res grficos. Una bueno fuente poro otros sitios bien diseados. www.btdnyc.cam: firma de diseo encabezada Toudreau. por Beth

de una pgina Web con informacin. El amontonamiento desagradable.

Resaltar el contenido.

resultante dficulta que el

usuario identifique la informacin o caractersticas necesarias y crea un caos visual

Despus de todo, sta es la razn por la cual el usuario es-

www.primo.com: firma de diseo encabezada Angeli.

por Primo para

t aqu. Nielsen [NIEOOjsugiere que la tpica pgina Web debe ser 80 por ciento contenido con el resto del ben Inmueble dedicado a navegacin y otras caractersticas.
Orgamzar los elementos de planulla de arriba a la izqUierda hacia abajo a la derecha.

WWw.warkhook.com: este sitio sirve como aparador el trabaja de ilustradares y diseadares

La gran mayoria de los usuarios explorarn una pgina web en gran parte de la mISma forma en que exploran las pagmas de un libro: de arriba a la izquierda hacia aba-

vencional. Un objeto de contenido tiene atributos que incluyen informacin especi-

19; 5

DISEO pn

CONIENIQg
se enfoca en dos asuntos de diseo diferentes, cada uno lo

fica de contenido (normalmente definida durante el modelado de anlisis WebApp) y atributos especificas de implementacin que se especifican como parte del diseo. Como ejemplo, considrese la clase de anlisis que se desarroll para el sistema de comercio electrnico HogarSeguro llamado ComponentedeProducto que se desarroll en el capitulo 18y se representa como aparece en la figura 19.4 En el capitulo 18 se mencion un atributo descripdn contenido: DescripcinDeMarketing, que aqui se representa como una clase compuesta de cinco objetos de DescripdnTcnica, Esquede diseo llamada DescripcindeComponente, Fotografa,

El diseo del contenido

abordan individuos con distintos conjuntos de habilidades. El diseo del contenido desarrolla una representacin de diseo para los objetos de contenido y representa los mecanismos que se requieren para que establezcan sus relaciones uno con otro. Esta actividad de diseo la dirigen los ingenieros Web. Adems, el diseo de contenido se ocupa de la representacin de la informacin dentro de un objeto de contenido especifico: actividad de diseo que dirigen los publicistas, los diseadores grficos y otros que generan el contenido de una WebApp. "los buenos diseodores pueden crear normalidad a partir del coos; pueden comunicar los idees con daridod por medio de lo organizacin y el manejo de los palabras y los dibujos: Je/fery V_

ma y Video, que se muestran como objetos sombreados en la figura. La informacin que contiene el objeto de contenido se registra como atributos. Por ejemplo, Fotografa (una imagen .jpg) tiene los atributos.,dimensin horizontal, dimensin vertical y estilo de borde. Mediante una asociacin UML y un agregado' se pueden representar relaciones entre los objetos de contenido. Por ejemplo, la asociacin UML que se muestra en la figura 19.4 indica que se emplea una DescripcindeComponente tancia de la clase ComponentedeProducto. para cada insest

19,5,1 Objetos de contenido

La relacin 'entre objetos de contenido, definida como parte del modelo de anlisis webApp (por ejemplo, figura 18.3), y los objetos de diseo que representan contenido es anloga a la relacin entre las c1sesde anlisis y los componentes de diseo descritos en el capitulo I l. En el contexto de la ingenieria Web un objeto de contenido est alineado de manera ms cercana con un objeto de dato para software con-

DescripcindeComponente

integrado por los cinco objetos de contenido mostrados. Sin embargo, la multiplicidad de notacin que se muestra indica que Esquema y video son opcionales (es posible que se presenten cero ocurrencias). se requieren una DescripcinDeMarketing y DescripcinTcnica, y se aplican una o ms instancias de Fotografia.

19,5.2 Cuestiones del diseo de contenido

Una vez modelados todos los objetos de contenido, la informacin que cada objeto
Representacin del cllseo de los objetos de contenJdo.
ComponltnredeProduClO po.,eNumero porlflNombrlt poneTipo deKflpcln precio creorNvevoAtliculoO de~plegorDeKflpc'nll desplegar EspecTecnlcO

entregar debe crearse y luego formatearse para satisfacer mejor las necesidades del

cliente. La creacin del contenido es el trabajo de los especialistas que disean el ob~ El
parte

de

jeto de contenido al proporcionar un esbozo de la informacin que se entregar y

,
I
tcoroctSoftwcr~'

flONSIJO.
Descripci6nd-Componenlre

una indicacin de los tipos de los objetos de contenido genricos (por ejemplo, texto descriptivo, imgenes grficas, fotografias) mediante los cuales se entregar la informacin. Tambin se puede aplicar el diseo esttico (seccin 19.4) para representar la apariencia y percepcin adecuados para el contenido. Conforme se disean, los objetos de contenido se "despedazan" [POWOOjpara formar pginas de la WebApp. El nmero de objetos de contenido que se incorporan en una sola pgina es en funcin de las necesidades del usuario, de las restricciones impuestas por la rapidez de descarga de las conexiones de Internet y debido a las restricciones que impone la cantidad de desplazamiento que el usuario tolerar.

t
1 1

I
IIPonel de Control.

SenKlr

C6moro

11

11

11

1
O'

OeKripci6no.MoReting
I>io<1oX1O estilo hn lomo" "-'" oopociodo ~tramcJi\o t.do vIO colo< fondo

"

, 1
Fotografia
dimensfn e6fi1o hori:zontol

0 .. \

011 E",

11
O

los usuorios tienden o tolerar el desplozomiento vertical ms fcilmente que el desplozomienro honzonrol. Evite los forrnom de pgina oncho.

V.deo
horizonfiCH ver#cal

"

DeKripdnTknico c""1dO estilo.fuenM i<>moIIo "-'" espociotn*'to liMO IomoM M:ldo imogen colo< fondo

dimenUn....mcat bde

dimensin Itorizon!d dimensin ....meal 10 bo<de

dimenain dimensin .~borde

~oudto

El diseo arquitectnico est enlazado con las metas establecidas para la WebApp, el contenido que se presentar, los usuarios que la visitarn y la filosofa de navega-

cin que se establezca. El diseador arquitectnico

debe identificar la arquitectura

de contenido y la arquitectura de la WebApp. La arquiteclUra de contenido'o se centra en la forma en la que los objetos de contenido (u objetos compuestos como las pginas Web) se estructura n para su presentacin y navegacin. La arquitectura de

WebApp aborda la forma en la que la aplicacin se estructura para gestionar la interaccin del usuario, manejar las tareas de procesamiento internas, efectuar la navegacin y presentar el contenido. ~~[lJa 8SllIJdUrUarquiledniaJ de un sitio bien diseado no siempre es aparente para el usuario ... .ni lo debe ser. '.> ')j',

'.. '

n.-s"

.:;

En la mayora de los casos, el diseo arquitectnico se dirige en paralelo con el diseo de la interfaz, el esttico y el de contenido. Puesto que la arquitectura WebApp puede tener una fuerte influencia sobre la navegacin, las decisiones tomadas durante esta actividad de diseo influirn en el trabajo dirigido durante el diseo de navegacin.
lineal con
flujo opcional

lineol
con derivaciones

El diseo de la arquitectura de contenido se centra en la definicin de la estructura hipermedia global de la WebApp. El diseo se puede elegir de cuatro diferentes estructuras de contenido [POWOC]: Las estructuras lineales (figura
J

9.5) se encuentran cuando es comn una secuen-

cia predecible de interacciones (con alguna variacin o desviacin). Un ejemplo clsico puede ser una presentacin tutorial en la que las pginas de informacin junto con grficos relacionados, videos cortos o audio se presentan slo despus de que se ha presentado informacin de prerrequisilos. La secuencia de la presentacin de contenido est predefinida y, por lo general, es lineal Otro ejemplo puede ser una secuencia de entradas para comprar un producto, en la cual se debe detallar informacin especfica en un orden especifico. En tales casos, son apropiadas las estructuras mostradas en la figura 19.5. Conforme el contenido y el procesamiento se vuelven ms complejos, el flujo meramente lineal mostrado a la izquierda de la figura da paso a estructuras lineales ms complejas en las que se puede llamar contenido alternativo u ocurre una desviacin para adquirir contenido complementario tura mostrada a la derecha de la figura 19.5) Las estructuras en reticula (figura J 9.6) son una opcin arquitectnica (estrucaplicable sin vertical representa las ofertas de varios fabricantes de palos de golf. En consecuencia, un usuario puede navegar la reticula horizontalmente para encontrar la columna putters y luego verticalmente para examinar las ofertas de aquellos fabricantes que venden putlers. Esta arquitectura de WebApp slo es til cuando se encuentra contenido altamente regular POWOO]. Las estructuras jerrquicas (figura 19.7)son indudablemente las arquitecturas WebApp ms comunes. A diferencia de las Jerarquias de software factorizadas -que se estudiaron en el capitulo J 0-, que alinean el flujo de control slo a lo largo de las ram?s verticales de la jerarquia, una estructura jerrquica WebApp se puede disear en una forma que permita (via ramificaciones de hipertexto) el flujo de control horizontalmente, a travs de las ramas verticales de la estructura. Por lo tanto, el contenido presentado en la rama de la extrema izqUierda de la jerarqua puede .~ner VInculas

cuando el contenido de la WebApp est organizado categricamente en dos (o ms) dimensiones. Por ejemplo, considrese una situacin en la cual un sitio de comercio electrnico vende palos de golf. La dimenSin horizontal de la retcula representa el tipo de palo que se vende (por ejemplo, madera, hierro, wedges, putters). La dimen-

10 El terrmno arqUItectura de mformaCln tamb,en una mejor organizacIn, etIquetado. navegaClon

se utiliza para sugerir estructuras

que conducen

y busqueda de objetos de contenido

Estructura jerrquica.

Los autores sugieren una arquitectura de diseo en tres capas que desacople la interfaz de la navegacin y del comportamiento de hipertexto que conduzcan a contenido que existe en la rama de en medio o a la derecl;la de ,la estructura. Sin embargo" se debe sealar que, aunque tales ramificaciones permiten la navegacin rapida a travs del contenido de la WebApp, pueden conducir ,aconfusin en la parte del usuario. Una estltlCtura en red o "Web pura" (figura 19.8) es similar en muchos sentidos a la arquitectura que evoluciona para los sistemas orientados a objetos. Los componentes arquitectnicos (en este caso, paginas Web) estan diseados de modo que pueden pasar el control (via vinculas de hipertexto) virtualmente a cualquier otro componente en el sistema. Este enfoque permite una considerable flexibilidad en la navegacin, pero al mismo tiempo puede ser confusa para el usuario. Las estructuras arquitectnicas comentadas en los parrafos precedentes se puede combinar para formar estructuras compuestas. La arquitectura global de una WebApp puede ser jerarquica, pero parte de la estructura puede mostrar caractersticas lineales, mientras que otra parte puede estar en red. La meta para el diseador arquitectnico es emparejar la estructura WebApp con el contenido que se presentara y el procesamiento que se lI"evara a cabo. 19.6,2 Arquitectura de WebApp La arquitectura MVe desacopla la interroz del usuario de lo funcionalidad 'NebApp y del contenido de informacin. mentacin y mejora la reutilizacin. La arquitectura de modelo-vista-controlador (MVC) IKRA881" es uno de varios modelos de infraestructura WebApp sugeridos para desacoplar la interfaz del usuario de la funcionalidad y el contenido de informacin de la WebApp. El modelo (a veces llamado "objeto modelo") contiene todo el contenido especifico de la aplicacin y la lgica de procesamiento, e incluye todos los objetos de contenido, el acceso a fuentes de datos/informacin externas y toda la funcionalidad de procesamiento que son especificos de la aplicacin. La vista contiene todas las funciones especificas de la interfaz y habilita la presentacin del contenido y la lgica de procesamiento, e incluye todos los objetos de contenido, acceso a fuentes de datos/informacin externas y a toda la funcionalidad de procesamiento requerida por el usuario final. El controde la aplicacin, y argumentan que mantener la separacin de la interfaz, aplicacin y navegacin simplifica la imple-

lador gestiona el acceso al modelo y a la vista y coordina el flujo de datos entre ellos.
En una webApp, "la vista la actualiza el controlador con datos provenientes del modelo con base en la entrada del usuario" [WMT02]. En la figura 19.9 se muestra una representacin esquemtica de la arquitectura MVC. En referencia a la figura, las solicitudes o datos del usuario se manejan mediante el controlador. ste tambin selecciona el objeto vista que es aplicable con base en la solicitud del usuario Una vez que se determina el tipo de solicitud, se transmite una solicitud de comportamiento al modelo, que implementa la funcionalidad o recupera el contenido requerido para acomodar la solicitud. El objeto modelo puede tener acceso a datos almacenados en una base de datos corporativa, como parte de

La arquitectura de WebApp describe una infraestructura que permite a un sistema o aplicacin basados en Web lograr sus objetivos de negocios. )acyntho y sus colegas [JAC021describen las caractersticas basicas de esta infraestructura en la forma siguiente: Lasaplicacionesdebenconstruirsecon el usode capasen lasque se tomen en cuenta las diferentespreocupaciones: en particular.losdatosde la aplicacinsedebensepararde los contenidosde la pgina (nadasde navegacin), y dichoscontenidos,a su vez, debenestar claramenteseparadosde la aparienciay la percepcinde ta interfaz (pginas).

I1

Sedebedestacar queMVC esenrealidad unpatrndediseoarquitectnico desarrollado porelambIenteSmalltatk(vease httpJ/www.cetus-links.org/oo_smalltalk.html) y sepuedeusarparacualquier aplicacin interactiva.

La arquitectura MVC (adaptada de [JAC02]).

I

19.7.1
I I

semntica de navegacin

Al igual que muchas actividades de ingenieria Web, el diseo de navegaCin comienza con una consideracin de la jerarquia de usuario y los casos de uso relacionados (capitulo 18) desarrollados para cada categora de usuario (actor). Cada actor puede usar la WebApp de manera un poco diferente y. por tanto, tener diferentes requisitos de navegacin. Adems. los casos de uso desarrollados para cada actor definirn un conjunto de clases que abarcan uno o ms objetos de contenido o funciones de la WebApp. Conforme cada usuario interacta con la WebApp, encuentra una serie de
unidades semnticas de navegacin

Contl'Cilador Gestiona los solicitud del usvor;o Selecciono

comportamiento

I I
I I I

de modelo
Selecciono respuesto visto comportamiento Seleccin de visto

I
I

(cambio de estado) :
I I I
I

Modelo Encapsula Iuncionolidod Encopsulo obeIos .de contenido Incorporo Iodos los eslo~os de WebApp

(USN). "un conjunto de estructuras de informade un subconjun-

cin y navegacin relacionadas que colaboran en el cumplimiento to de requisitos de usuario relacionados" ICAC02].

I
I I I

Gnaho y Larcher IGNA99J describen la USN en la forma siguiente:

La estructura de una USN est compuesta de un conjunto de subestructuras cin que se lIamarnfonnas de navega-

Vi.",
Prepora datos del modelo
Actualizo solicitudes

I
I

del modelo
Presento visto seleccionada

I I I I
I I I

de navegacin (FdN). Una FdN representa la mejor forma o

ruta de navegacin para los usuarios con ciertos perfiles para lograr su meta o submeta deseada. En consecuencia, el concepto de FdN est asociado con el concepto de Perfil de Usuario. La estructura de una FdN est Integrada con un conjunto de nadas de navegacion (NN) relevantes conectados por vinculas de navegacin, que en ocasiones incluyen otras FdN Esto significa que las FdN pueden, en si mismas, ser agregadas dara formar una FdN de nivel superior. o pueden anidarse en cualquier profundidad Para ilustrar el desarrollo de' una FdN, considrese el caso de usd seleccionar campo nentes HogarSeguro descrito en la seccin 181.2 y que se reproduce a'continuacin.
\

por el controlador ___________________________

Servioor

un almacn de datos local o como una coleccin de archivos independientes. Los datos que desarrolla el modelo debe formatearlos y organizarlos el objeto vista adecuado y luego transmitirlo del servidor de la aplicacin de vuelta al navegador basado en el cliente para que se despliegue en la mquina de ste. En muchos casos. la arquitectura de \\'ebApp se define dentro del contexto del ambiente de desarrollo en el que la aplicacin habr de implementarse (por ejemplo, ASPnet, JWAA o )2EE). El lector interesado debe ver rFOW031para una exposicin ulterior acerca de los ambientes de desarrollo modernos y de su papel en el diseo de las arquitecturas de aplicaciones Web.

Entonces la webApp recomendar componentes de producto

(por ejemplo, paneles de

control, sensores, cmaras) y otras caracteristicas (por eJemplo, funcionaJidad basada en

pe

implementada

en software) para cada ~ de precIos para cada componente

y la entrada exterior. Si el usuano si existen. El usuario obtendr iJ1fQrm.Q., de producto. La webApp creara y vanos componentes. El

solicita opciones, la webApp las proporcionar cion descriptiva)" mostrar

una factura de materiales conforme se seleccionen

usuario tambin podr nombrar la factura de materiales y guardarla para referenCia futu.

Una vez establecida la arquitectura de WebApp y la identificacin de los componentes (pginas, guiones, applets y otras funCiones de procesamiento). el diseador debe definir las rutas de navegacin que habiliten para los usuarios el acceso al contenido y las funciones de la WebApp. Para lograr esto el diseador debe 1) identificar la semntica de navegacin para diferentes usuarios del sitio y 2) definir la mecnica (sintaXIS) que logra la navegacin "Slo espero, Grelel, hasta que lo luna se eleve, entonces veremos los trozos de pon que he desparramado, ellos nos mostrorn de nuevo el comino o coso.' TOIIICIdo de HcmseI Y Grete! Uno USNdescribe los requisitos de .Iovegocin poro codo coso de uso. En esen<io, lo USN muestro cmo un actor se mueve entre los o~etos de contenido o los funoones de lo WebApp.

ra (vase caso de uso: guardar configuracin).

Los artculos subrayados en la descripcin del caso de uso representan clases y ohjetos de contenido que sern incorporados en una o ms FdN que permitirn a un nuevo cliente realizar el escenario descrito en el caso de uso seleccionar
tes HogarSeguro. componen-

La figura 19.10 bosqueja un anlisis semntica parcial de la navegacin que irlplica el caso de uso seleccionar componentes HogarSeguro. Con la aplicacin de ,a terrninologia introducida anteriormente, la figura tambin representa una FdN pa.a la WebApp HogarSegurolnc.com. Se muestran importantes problemas en las clases de dominio Junto con objetos de contenido seleccionados (en este ca"J, el paquete

 Barra de navegacin horizontaI- lista de [as principales categorias de conte~ONSEJO"

nido o funcionales en una barra que contiene vinculos adecuados. En general, se mencionan entre cuatro y siete categorias. Columna de navegacin vertical.
1) lista de las principales categorias de conte-

En la mayaria de las situaciones, elanse mecanismos de navegacin horizontal o vertical, pero no ambos.
vinculo de navegacin de navegacin comprar ComponentedeProduclo regresar a Habitacin vnculo

nido o funcionales, o 2) lista de virtualmente todos los principales objetos de contenido dentro de [a WebApp. Si se elige la segunda opcin, tales columnas de navegacin se pueden "expandir" para presentar objetos de contenido como parte de una jerarquia. Pestaas: una metfora que no es ms que una variacin de la barra o colum-

na de navegacin, que representa las categorias de contenido o funcionales

vnculo de navegacin comprar ComponentedeProducto

como marcas que se seleccionan cuando se requiere un vinculo. Mapas de sitio. proporcionan una tabla de contenido incluyente para la nave-

gacin hacia todos [os objetos de contenido y funcionalidad contenidos en [a WebApp. de objeto~ de contenido llamado DescripcinComp, pOllentedeProducto). un atributo de la clase Com~ONSEJO"

Dichos articulas son nodos de navegacin. Cada una de las

Adems de elegir los mecanismos de navegacin, el diseador tambin debe establecer convenciones y auxiliares de navegacin adecuados. Por ejemplo, iconos y vinculos grficos que deben parecer "oprimibles" mediante el biselado de los bordes para que la imagen tenga una apariencia tridimensional. Debe disear retroalimentacin visual o de audio para ofrecer al usuario un indicador de que ha elegido una opcin de navegacin. En la navegacin basada en texto debe usarse color para indicar los vinculos de navegacin y proporcionar un indicador de los vinculas ya recorridos. stas son slo algunas de las docenas de convenciones de diseno que hacen la navegacin amigable al usuario.

flechas representa un vinculo de nav.egacin" y est etiquetado con la accin que inicia el uso que causa que el vinculo ocurra. El di;eador de la WebApp crea una unidad cliente semntica de navegacin (USN) para

cada c~so de uso asociado con cada papel de usuario [GNA991 Por ejemplo, un nuevo (figura 18.1) puede tener tres diferentes casos de uso, y todos resultan en acceso a diferente informacin y funciones de la WebApp. Para cada meta se crea una USN. Durante las etapas iniciales del diseo de navegacin se valora la arquitectura de contenido de [a WebApp para determinar una o ms FdN para cada caso de uso. Como se anot anteriormente, una FdN identifica los nodos de navegacin (por ejemplo, contenido) y los vinculas que permiten la navegacin entre ellos. Entonces las FdN se organizan en USN.

Elmapa de sino debe ser accesible desde cada pgino. Elmapa en si mismo debe estar organizado de modo que la estructura de informacin de la WebApp sea fcilmente aparente.

Las modernas aplicaciones Web entregan funciones de procesamiento cada vez ms elaboradas que 1) realizan procesamiento localizado para generar capacidad de contenido y navegacin en una forma dinmica; 2) ofrecen capacidades de computacin o procesamiento de datos que son adecuadas para el dominio de negocios de la WebApp; 3) proporcionan cuestionamientos y acceso sofisticados a bases de datos, 4) establecen interfases de datos con sistemas corporativos externos. Para lograr

.:,g problema de la navegolin en el sitio Web es conceptuol, tmico, espacial, filosfico y 1ogs1iw. ":.: las soludones tienden a pedir combinaciones de arte, ciencia y psicologia orgonizadonaJ improvisadas.y _.

19.7.2 Sintaxis de navegacin

Conforme el diseo se lleva a cabo se define la mecnica de navegacin. Entre muchas posibles opciones estn: Vnculo de navegacin individual: vinculos basados en texto, iconos, botones e

estas (y muchas otras) capacidades, el ingeniero Web debe disear y construir componentes de programa que sean idnticos en forma a los componentes de software para el software convencional. En el capitulo 11 se considera con cierto detalle el diseo al nivel de componentes. Los mtodos de diseo estudiados en el capitulo I1 se aplican a los componentes WebApp con poca, si acaso, modificacin. El ambiente de implementacin, los lenguajes de programacin y los patrones de reutlizacin, marcos de trabajo y software pueden variar un poco, pero el enfoque de diseo global permanece igual.

interruptores, y metforas grficas.

,
cmo la interfaz informa al usuaro de las consecuencias de una accin especifica; cmo un usuario expande el contenido con base en el contexto de uso y sus deseos;

Los patrones de diseo aplicados en la ingeniera Web abarcan dos grandes clases:
1) patrones de diseo genrico

cmo describir mejor el destino que implica un vinculo; cmo informar al usuario acerca del estado de una interaccin en marcha y otros. Las fuentes de informacin acerca de los patrones de diseo hipermedia se han expandido en forma sustancial en aos recientes. Los lectores interesados deben consultar [GAR97]. [PER99] Y [GEROO].

que son aplicables a todos los tipos de software (por

de diseo hipermedia

ejemplo, (BUS96] y IGAM95]) Y 2) patrones

que son especificos

de las WebApp. En el captulo 9 se trataron los patrones de diseo genrico. A travs de Internet se puede tener acceso a varos catlogos y almacenes de patrones de hipermedia.13
JllIIIIl

es una regio de tres portes que expresa uno relacin enlre cierto amtexto, un JlfaOlema y uno soIudn. "
.-

~ To

CJsrIstoplMrAIeuncIIr

Almacenes

de patrones de diseo hipermedia

Mejora de los sistemas de infonnacin Web con patrones de navegacin hltp://www8.org/w8papers/5bhypertextmedio/impro
ving/improving.html

Como se apunt antes en este libro. los patrones de diseo son un enfoque genrico para resolver algn pequeo problema de diseo que se puede adaptar a una variedad mucho ms amplia de problemas especificos. En el contexto de los sistemas basados en Web. German y Cowan [GEROO] sugieren las siguientes categoras de patrones: Patrones arquitectnicos. Estos patrones auxilian en el diseo del contenido y la

El sitio Web IAWiki (hltp://iawiki.net/Website Pottems) es un espacio de discusin coniunto poro informocin de los orquitectos y que contiene muchas
recursos tiles. Entre ellos estn vnculos a varios catlogos

y oImocenes de potrones hipermedio tiles. Estn represen' todas cientos de potrones de diseo: Almacn de patrones de diseo hipermedia hltp://www.designponern.lu.unisi.ch/ InteractionPattems de Tom Erickson hltp: / / www.pliant.org/personol/Tom_Erickson/lnteroc tionPanerns.htrnl Patrones de diseo Web de Martijn vanWelie hltp://www.welie.com/ponerns/

arquitectura de la WebApp. Las secciones J 9.6. J Y 19.6.2 presentan patrones arquitectnicos para el contenido y la arquitectura de la WebApp. Adems. estn disponibles muchos patrones arquitectnicos relacionados (por ejemplo. Java Blueprints en java.sun.com/blueprnts/) para los ingenieros Web que deben disear webApps en de componentes. Estos patrones recomiendan mtouna diversidad de dominios de negocios. Patrones de construccin

Un patrn de lenguaje HTML2.0 hnp:/ /www.cnamorph.com/docs/ponerns/defcult.html Terreno comn hltp:/ / www.mit.edu/-itidwell/interoetion_ponerns.htrnl Patrones para sitios Web personales hltp://www.rdrop.com/-holflCrections/Writings/Web. ponerns/index.htrnl . ndice de lenguajes patrri hltp://www.cs.brown.edu/-rms/lnformationStructures/ Indexing/ Overview. htrnl

r.~.

dos para combinar componentes WebApp (por ejemplo, objetos de contenido. funciones) en componentes compuestos. Cuando se requiere la funcionalidad de procesamiento de datos en una WebApp, son aplicables los patrones de diseo arquitectnico y al nivel de componente que proponen [BUS96L IGAM95] y otros Patrones de navegacin. Patrones de presentacin. Estos patrones auxilian en el diseo de USN. vnculos de Estos patrones auxilian en la presentacin del contenavegacin y el flujo global de navegacin de la WebApp nido como se presenta al usuario via la interfaz correspondiente. Los patrones en esta categoria abordan como organizar las funciones de control de la interfaz del usuario para una mejor facilidad de uso; cmo mostrar la relacin entre una accin de la interfaz y los objetos de contenido que afecta; cmo establecer jerarquias de contenido efectivas; y muchas otras. Patrones de interaccin comportamiento/usuario. Estos patrones auxlian en el diseo de la interaccin usuario-mquina. Los patrones en esta categoria abordan

19,10 . MfTOPO

m:

DISEO WPERMEDIA ORIENTApO A OBJETOS (MDHOQ)

Durante las pasadas dcadas se propusieron varios mtodos de diseo para aplicaciones Web. A la fecha, ningn mtodo es el dominante. En esta seccin se presenta un breve panorama de uno de los mtodos de diseo WebApp ms ampliamente analizados: MDHOO.14 El mtodo de diseo hipemledia
orte;llado a objetos (MDHOO) lo propusieron ongi-

nalmente Daniel Schwabe y sus colegas (SCH95, SCH98]. El MDHOO est compuesto de cuatro diferentes actividades de diseo: diseo conceptual, diseo de navegaCJol1, diseo abstracto de la interfaz e implementacin. brevemente. 19.10.1 Diseo conceptual por el MDHOO mediante el MDHOO crea una representacin de los subsist,En la figura 19.I I se muestra un resumen de estas actividades de diseo. y en las secciones que siguen se discuten

El diseo conceptual

mas, clases y relaciones que definen el dominio de aplicacin para la WebApp. ~e

Esquema conceptual

parcial

para HogarSeguroInc.com.

'.1
')

~
Diseo conceptual

~
Diseo de navegacin

Diseo abstracto de lo interfoz Obetos abstractos de a interlaz,

respuestas o eventos externos, transformaciones

[i9

(J
Implementocin WebApp ejecutoble
hobitodf'lNombre dimensiones exteriOfVenlanos exleriorf'uerfos

ComponenledeProdUdo porteNmero porteNombre

poneTipo
descripcin predo creorNuevoArtculoll o~pcin(J obtenetE.spec Tcnicc

FocturoDeMoterioles ildentificodor UsloFdM NumeroAttculos precioTolo1

Nadas, vinculos,
estructuras

Productos de trabaja

Clases, subsistemos,
relaciones, atributos

de acceso, contextos
de navegacin, transformaciones de navegacin

Mecanismos de diseo

Clasificacin, composicin, agregacin, generalizacin, especializacin

Correlacin

entre

o~etos concep,tuales y e navegaclon

C-;"reloci6n objetos de
navegacin

entre

Recurso proporcionado

y perceptibles
Modelada de las objetas perceptibles, implementacin de las metforas elegidas. Descripcin de la interlaz para los objetos de navegacin

por ambiente objetiva

Preocupaciones de disl'o
I

Mbdelado de la semntica del

dominio

de aplicacin

Toma en cuente el perfil del usuario y la tarea. Resalta los aspectos cOgnitivos.

Exactitud; desempeo de la 1clicacir integri ad

Pedido pedidoNmero di&n*nfo foctur<JOell..\oterioles embotquelnfo cobronzolnfo

contidod porteNmero porteNombre porleTipo precio ogregoroUSlo{ I borrordesto( J obtenerSiguiente EnlrodoUsto( I

puede usar'5 UML para crear diagramas taciones describe de clase compuestas, el dominio diagramas

de clase adecuados, de colaboracin

agregados y otra

y represenque dos, vinculos, ms elaboradas anclas y estructuras de acceso como (SCH98]. Las estructuras un in dice de la WebApp, de acceso son un mapa de

informacin

de la aplicacin simple

(vase la Parte 2 de este libro para ms detalles). conceptual del MDHOO, considrese de nue19.12

incluyen

mecanismos

Como un ejemplo vo la aplicacin se muestra

de diseo electrnico

sitio o un paseo guiado. Una vez definidas navegacin llamados tes: Cada definicin de contexto incluye. ademas de los elementos que estan incluidos en l. mediante contextos" las clases de navegacin, el agrupamiento (SCH98). Schwabe el MDHOO "estructura

de comercio

de HogarSegurolnc.com.

En la figura

el espacio de
en conjuntos siguien-

un "esquema agregados

conceptual" e informacin

parcial

para HogarSegurolnc.com. desarrollados

Los diagracomo parte del re-

de los objetos describe un

de navegacin

mas de clase, anlisis laciones

relacionada

contexto

en los trminos

de la WebApp entre clases.

se reutilizan

durante

el diseo conceptual

para representar

19.10.2
El

Diseo de navegacin
identifica

mediante el MDHOO
de "objetos" que se derivan de las cla-

la especificacin de su estructura de navegacin interna, un punto de entrada, restricciones de acceso en trminos de clases de usuario y operaciones, y una estructura de acceso asociada. Se desarrolla una plantilla de contexto (analoga a las tarjetas CRC estudiadas en el capitulo 8) y se emplea para rastrear los requisitos de navegacin de cada categoria de usuario a travs de varios contextos definidos en el MDHOO. Al hacer esto surgen rutas especificas de navegacin (que se llamaron FdN en la seccin 19.7.1). al

diseo de navegacin

un conjunto

ses definidas o "nodos"

en el diseo

conceptual. dichos

Se define una serie de "clases

de navegacin" casos de

para encapsular grficos

objetos.

Se puede usar UML para crear de secuencia, de navegacin. de navegacin

uso adecuados, diseador aplicar

de estado y diagramas mejor los requisitos para el diseo un conjunto

todos ellos auxilian Adems, conforme

a comprender

es posible el diseo se no-

los patrones

de diseo utiliza

desarrolle.

El MDHOO

predefinido

de clases de navegacin:

19.10.3
La actividad

Diseo abstracto de la interfaz e implementacin

de

diseo abstracto de la interJaz

interacta

especifica

los objetos

de la interfaz de objetos

que de

15 El MDHOO

no prescribe

una notacin

especifica;

sin embargo,

el uso de UML es comn

cuando

se

el usuario la interfaz,

ve conforme llamado

con la WebApp.

Un modelo

formal

aplica este mtodo.

visin abstracta de datos

(VAD) se utiliza

para representar

la re-

lacin entre objetos de la interfaz y objetos de navegacin, y las caracteristicas de comportamiento de los objetos de la interfaz. El modelo VAD define una "plantilla esttica" [SCH98] que representa la metfora de la interfaz e incluye una representacin de los objetos de navegacin dentro de la interfaz y la especificacin de los objetos de la interfaz (por ejemplo, mens, botones, iconos) que auxilian en la navegacin y la interaccin. Adems, el modelo VAD contiene un componente relacionado con el comportamiento (similar al diagra~
~

Las mtricas para el diseo de WebApps estn en desarrollo y pocas se han validado ampliamente. El lector interesado debera consultar [IVOOI] y [MENOI] para una muestra de las mtricas propuestas para el diseo de WebApps.

Mtricas tcnicas para WebApps

Web Static Ana/yzer Tool (WebSAT): verifico el HTMl de lo pgina web conlTa los lineomientos de facilidad de
uso tpicos.

ma de estado UML) que indica cmo los eventos externos "disparan la navegacin y qu transformaciones de la interfaz ocurren cuando el usuario interacta con la aplicacin" [SCHO J]. Una exposicin detallada del VAD el lector interesado puede hallarla en [SCH98] y ISCHO1]. La actividad implementacin del MDHOO representa una interaccin de diseo que es especifica al ambiente en el que operar la WebApp. Las clases, la navegacin y la interfaz son caracterizadas en una forma que puede construirse para el ambiente cliente/servidor, sistemas operativos, software de soporte, lenguajes de programacin y otras caracteristicas del entorno relevantes respecto del problema.

Objetivo: Apoyar o los ingenieros Web en el desarrollo de melTicos WebApp significativos que ofrezcan uno visin acerco de lo calidad globol de uno aplicacin. Mecnica:
Las

Web Category Ana/y.i.

herramientas mecnicas varan.

niero de facilidad de uso construir

Tool (WebCAT): permite 01 inge y dirigir un anlisis

Herramientas representativas 17 Netmechonic Toa/s, desarrollado por Netmechonic (www.

de categoria Web. Web Variable Instrumenter Program (WebV/P): instrumento un sitio Web poro capturar un registro de interac dn de usuario.

netmechanic.comL

es uno coleccin de herramientas

que ayudo n o mejoror el desempeo de un sitio Web; se enfoca sobre los temas especficos de lo implemento-

Framework lor Logging Usabiliry Doto (FLUO):implemen' to un formateodor y analizador gramatical de archivos
poro representar los registros de interaccin de usuorio. Vis VIP

dn. N/ST Web Metric. Te.tbed, desarrollado por The Notionol Institute of Stondords ond Technology (zing.ncsl.nist. gov /Web Toels/), aborca lo siguiente coleccin de he'
rramientas tiles que estn disponibles poro descargar-

Tool: produce una visualizacin tridimensionol de

del ,usuario o travs de un sitio

Las mtricas de diseo se deben caracterizar en una forma que proporcione a los ingenieros Web un Indicador de calidad en tiempo real. En esencia, un conjunto til de medidas y mtricas ofrece respuestas cuantitativas a las siguientes preguntas: La interfaz del usuario promueve la facilidad de uso' La esttica de la WebApp es apropiada para el dominio de la aplicacin y confortable para el usuario' El contenido est diseado en una forma que proporciona la mayor informacin con el menor esfuerzo' La navegacin es eficiente y directa' La arquitectura de la WebApp se ha diseado para acomodar las metas y objetivos especiales de los usuarios de la webApp, la estructura de contenido y funcionalidad, y el flujo de navegacin requerido para usar el sistema de manera efectiva' Los componentes estn diseados en una forma que reduce la complejidad de procedimientos y aumenta la exactitud, la confiabilidad y el desempeo' En la actualidad, cada una de estas preguntas se puede abordar de manera cualitativa,'0 pero todavia no existe un conjunto validado de mtricas que ofrezcan respuestas cuantitativas.
secClon

las rutas de navegacin

Web. de un sitio Web.

'
e las pginas

TreeDec: agrego auxiliares de navegacin

los:

.--,....""':"--

;RESYMEN
La calidad de una WebApp -derJnida en trminos de facilidad de uso, funcionalidad, confiabilidad, efiCiencia, facilidad de mantenimiento, seguridad, escalabilidad y tiempo en el mercadose introduce durante el diseo. Para lograr dichos atributos de calidad, un buen diseo WebApp debe posser simplicidad, consistencia, identidad. robustez, navegabilidad y aparienCia visual. El diseo de la interfaz describe la estructura y organizacin de la interfaz del usuario. Incluye una representacin de la plantilla de pantalla, una definicin de los modos de interaccin y una descripcin de los mecanismos de navegacion. El diseo esttico, tambien llamado diseo grfico. describe la "apariencia y la percepcin" de la WebApp e Incluye esquemas de color, plantilla geomtrica. tamao de texto, fuente y ubicaCin, el uso de grficos y decisiones estticas relacionadas. Un conjunto de lineamientos de diseo grfico proporciona la base para un enfoque de diseo.

16 Vease el capItulo de una WebApp

16 (seCCIn 164) Y la

9 1.1 para una exposicJon cualitatIva

de la calidad

El diseo de contenido define la plantilla, la estructura y el subrayado de todo el contenido que se presenta como parte de la WebApp: adems, establece las relaciones entre objetos de contenido. El diseo de contenido comienza con la representacin ae los objetos de contenido, sus asociaciones y relaciones. Un conjunto de consideraciones elementales establece las bases para el diseo de navegacin. El diseo de arquitectura identifica la estructura hipermedia global para la WebApp y abarca tanto la arquitectura de contenido como la de WebApp. Los estilos arquitectnicos para el contenido incluyen estructuras lineal, en reticula, jerrquica y en red. La arquitectura de la WebApp describe una infraestructura que permite a un sistema o aplicacin basado en Web lograr sus objetivos de negocios. El diseo de navegacin representa el flujo de navegacin entre los objetos de contenido y para todas las fUl'lciones de la WebApp. La navegacin se define al describir un conjunto de unidades semnticas de navegacin. Cada unidad est compuesta de formas de navegacin y de vinculas y nadas de navegacin. Los mecanismos de sintaxis de navegacin se aplican para afectar la navegacin descrita como parte de la semntica.
\

IFIT54J Filts,. P., "The Informalion CapaClty of the Human Molor System in Controlling the Amplilude 01 Movemenl", en oumal o/Expenmental Psychology, vol. 47, 1954, pp. 381-391 IFOW031 Fowler, M. et al., Pattems o/ Encerpnse Applicalion Archlleeture, AddisonWesley, 2003 [GAL021 Galitz, w., The Essenlial CUide lo User Interface Deslgn, Wley, 2002. [GAM95j Gamma, E. el al., Design Patterns, Addson-Wesley, 1995. [GAR97J Garndo, A., G. Rossi y D. Schwabe, "Pattems Systems for Hypermedia", 1997, se puede descargar de www.infpuc-no.br/-schwabe/papers/PloP97.pdf IGEROOj German, D..y D. Cowan, "Toward a Unified Calalog of Hypermeda Design Patterns", Prac. 33rd Hawau Int/. Con/ on Syslem Sciences, IEEE, vol. 6, Mau, Hawaii, junio de 2000, se puede descargar de www. turingmachne.orgl -dmg/research/papers/dmg_hicss2000.pdf [GNA99] Gnaho, C. y F. Larcher, "A User-Centered Methodology for Complex and Customizable Web Engineering", Proc. ISIICSE Workshop on Web Engmeenng, ACM, Los ngeles mayo de 1999. ' IHEI02] Heinicke, E., Layout Fasl Solulions lor Hands-On Design, Rockport Publishers, 2002. [IVOO 1] IVOry, M., R. Sinha y ~l. Hearst, "Empircally Validaled Web Page Desgn Metrics", ACM SIGCHI '01, Seattle, WA, abril de 2001, disponible en htlp:llwww.rashmisinha.com/articlesl WebTangoCHIO I.html. UAC02j Jacynlho, D., D. Schwabe y G. Ross, "An Architecture for Structuring Complex Web Applcations", 2002, disponible en http://www2002.org/CDROM/alternate/478/. lKAI021 Kaiser, J., "Elemenls 01'EITectiveWeb Design", About, Ine., 2002, disponible en http://web. design.about.com/library/weekly/aa091998.hlm. IKAL031 Kalman, S., Weh Secun!)l Field CUide, Cisco Press, 2003. [KOC991 Koch, N., "A Comparatve Sludy of Melhods for Hypermedia Development", Technical Report 9905, Ludwig-Maximilians Universilat, Munich, Alemania, 1999, se puede descargar de http://www.dslC.upv.es/-west200 1IlwwoslO 1lfiles/contributons/NoraKoch/hyp_ dev.pdf [KKA88j Krasner, G. y S. Pope, "A Cookbook for Using the Model-Vew Conlroller User Interface Paradigm in Smalllalk-80", oumal ofObect-Orienced Programming, vol. 1, nm. 3, agosto-septiembre de 1988, pp.26-49. ILOW981 Lowe, D., y W. Hall (eds.). Hypene'l and !he Web-An Engmeering Approach, John Wiley & Sons, 1998. IMCCO1] McClure, S. J. Scambray y G. Kurtz, Hackmg Exposed, McGraw-HIl/Osborne, 2001 [MENOI j Mendes, E., N. Mosley y S. Counsell, "Eslimating Design and Authorng Efforl", en IEEE MullimedlO, enero-marzo de 2001, pp. 50-57. [MILOOI Miller, E.,."The Websle Quality Challenge", Software Research, Ine., 2000, http://www. soft.com/evalid/Technology/wh,te.papers/website.quality.challenge.html. INIE96j Nlelsen, J. y A. Wagner, "User Interface Design for the WWW ... Proc.CHI96 Con/ On Human FaclOrs in Compuling Syslems, ACM Press, 1996, pp, 330-331. [NIEOO] Nielsen, J., Designing Web Usability, New Riders Publishing, 2000. INOR02j Northcutt, S. y j. Novak, Network Intrusion Deleclion, New Riders Publishing, 2002. [Off 021 Offutl, )., "Quality Attnbutes of Web Software Applications", en IEEE Soj/ware, marzoabnl de 2002, pp. 25-32. IQLS98j Olsina, L., "Building a Web-Based Information System Applying the Hypermedia Flexible Process Modeling Strategy", Proc. ISllnt/. Workshop on Hypermedia Development, 1998. [0L599j Olslna, L. el al., "SpeClfying Qualily Characteristcs and Altributes for Web Siles", Proc. IsIICSE Workshop on Web Engineering, ACM, Los ngeles, mayo de 1999. [PER99j Perzel, K. y D. Kane, "Usability Pattems for Applications on the World Wide Web", 1999, se puede descargar de http://jerry.cs.uiuc.edu/ -plop/plop99/proceedings/Kane/perzel kane.pdf. [POWOOIPowelJ, T., Web Design, MCGraw-HilJ/Osborne, 2000. [KASOO] Raskin, j" The Humane Interface, Addison-Wesley, 2000. [R.H098l Rho, y, y T. Gedeon, "Surface Slruclures in Browsing the Web", Proc. Australasian Computer Human Interaclion COnJerence,IEEE, diciembre de 1998. [SCH95] Schwabe, D. y G. Rossi, "The Object-Oriented Hypermedia Design Model", en G4CM, vol. 38, num. 8, agosto de 1995, PP.45-46.

El diseo de componentes desarrolla la lgica de procesamiento detallada que se requiere para implementar los componentes funcionales de la WebApp. Las tcnicas de diseo descritas en el capitulo I l se aplican a la ingenieria de componentes WebApp. Los patrones para el diseo de WebApps abarcan patrones de diseo genrico que se aplican a todos los tipos de software y patrones hipermedia especialmente relevantes para las WebApp. Se han propuesto patrones de diseo arquitectnico, navegacin, de componentes, de presentacin y de comportamiento/usuario. El mtodo de diseo hipermedia orientado a objetos (MDHOO) es uno de varios mtodos propuestos para el diseo WebApp. El MDHOO sugiere un proceso de diseo que incluye diseo conceptual, diseo de navegacin, diseo abstracto de la interfaz e implementacin. Las mtricas de diseo para ingeniera Web estn en desarrollo y todavia tienen que validarse por completo. Sin embargo, se han propuesto varias medidas y mtricas para abordar cada una de las actividades de dseo reanalizadas en este capitulo. de

[AME96j Amento, B. et al., "Fit!'s Law", CS 5724: Models and Theories o/ Human-Compuler Interaclions, Virginia Tech, 1996, disponible en http://eLcs.vt.edu/-cs5724/gl/. [BAGOI] Baggerman, L., y S. Bowman, Web Design That Works, Rockport Publishers, 2001. [BUS96j Buschmann, F. et al., Pattem-Orienled Sojlvvare ArchileclUre, Wiley, 1996. ICAC02] Cachero, C. et al., "Conceptual Navigation Analysis: a Device and Platform Independent Navigation Specificalion", Proc. 2nd Int/. Workshop on Web-Oriented Techn%gy, junio de 2002, se puede descargar de www.dsic.upv.es/-west/iwwost02/papers/cachero.pdf. [CLOO11Cloninger, C,' Fresh Stylesfor Web Designers, New Riders Publishing, 2001. [DIX99J Dix, A., "Desgn of User Interfaces for the Web", Proc, OfUser Interfaces lODala ~Iems Conference, septiembre de 1999, se puede descargar de http://www.comp.lancs.ac.uk!computing/ usersl dixa/topics/webarch/.

SCH98] Schwabe, D. y G. Rossi, "Developing Hypermedia Applications Using OOHDM", Proc. Workshop on Hypermedja Developmenl Process, Methods and Models, Hypercext '98, 1998, se puede descargar de http://citeseer.n).nec.com/schwabe98deveJoping.htmi. rSCHOJ] Schwabe, D., G. Rossi y S. Barbosa, "Systematic Hypermedia Application Design using OOHDM", 2001, disponible en http://www-di.inf.puc-rio.br/-schwabe/HT96WWW/ section J.htmi. [TILOO]Tillman, H. N., "Evaluating Quality On the Net", Babson College, 30 de mayo de 2000, disponible en http://www.hopetillman.com/findquai.html#2 TOGO1] Tognozzi, B., "First PrincipJes", askTOG, 2001, disponible en http://www.asktog.com/ basics/firstPrinciples. html. [WMT02] Web Mapping Testbed Tutorial, 2002, disponible en http://www.webmapping. org/vcgdocuments/vcgTutoriall. IZHA02] Zhao, H., "Fitt's Law: Modeling Movement Time in HCI", Theories in Computer Human lnleraction, University of Maryland, octubre de 2002, disponible en http://www.cs.umd.edu/ c1ass/fal12002/ cmsc838s/tichi/fitts. htm J.

19.12. Con UML desarrllense tres o cuatro representaciones de diseo para objetos de contenido que podrian encontrarse conforme se disea el "motor de aprendizaje" descrito en el problema 19.7. 19.13. Hacer un poco de investigacin adicional acerca de la arquitectura MVC y decidir si seria una arquitectura WebApp apropiada para el "motor de aprendizaje" mencionado en el problema 19.7. 19.14. Cul es Ja diferencia entre sintaxis de navegacin y semntica de navegacin' Describir cada una con

19.15. Definir dos o tres USN para la webApp de HogarSegurolnc.com. cierto detalle.

19.16. Hacer alguna investigacin y presentar a su clase dos o tres patrones de diseo hipermedia completos.

19.1. Por qu el "ideal artistico" es una filosofia de diseo insuficiente cuando se construyen las webApps modernas? Existe un caso en el que el ideal artistico sea la filosofia que debe seguirse' 19.2. En este capitulo se analiz una amplia variedad de atributos de calidad para las WebApps. Elijanse las tres que se considere como las ms importantes y elabrese un argumento que explique por qu cada uno debe resaltarse en el trabajo de diseo de Ingeniena Web. 19.3. Agrguense al menos cinco preguntas adicionales a la "Lista de verificacin de la calidad del diseo de la WebApp" presentada en una barra lateral en la seccion 19.1.1. 19.4. Revisar los principIOS de diseo de la interfaz de Tognozzi tratados en la seccin 19.3.1 Considerar cada principio para una WebApp operativa con la cual se est familiarizado. Calificar la webApp (sense calificaciones A, 5, C, D o F) en relacin con el grado en el cual ha logrado el principio. Explicar la razn para cada calificacin. 19.5. Disear una interfaz prototipo para la webApp de HogarSegurOlnc.com. Intntese ser innovador pero, al mismo tiempo, se debe asegurar que la interfaz se ajusta a los pnncipios para el buen diseo de la interfaz. 19.6. Se han encontrado mecanismos de control de la interfaz que sean diferentes a los anotados en la Seccin 19.3.2' Si es asi, describanse brevemente. 19.7. El lector es el diseador webApp para una compaia de enseanza a farga distancia. Su intencin es implementar un "motor de aprendizaje" basado en Internet que le permitir entregar contenido del curso a los estudiantes. El motor de aprendizaje ofrece la infraestructura bsica para entregar contenido de aprendizaje de cualquier materia (diseadores de contenido prepararn el contenido adecuado). Desarrllese un diseo de interfaz prototipo para el motor de aprendizaJe. 19.8. Cul es el sitio Web estticamente ms agradable que el lector haya ha viSitado y por qu' 19.9. Considerar el obJeto de contenido pedido, generado una vez que un usuario de HogarSeguroJnc.com ha completado la seleccin de todos los componentes y est listo para finalizar su compra. Desarrollar una descripcin UML de pedido unto con todas las representaciones de diseo apropiadas. 19.10. <Cul es la diferenCia entre arquitectura de contenido y arquitectura de webApp'

Aunque se han escrito cientos de libros acerca del "diseo Web", muy pocos abordan algunos mtodos tcnicos significativos para realizar el trabajo de diseo. Cuando mucho, se presentan varios Iineamlentos tiles para el diseo de la WebApp, ejemplos valiosos de pginas Web y se muestra programacin java, y se analizan los detalles tcnicos importantes para implementar webApps modernas Entre los muchos que se ofrecen en esta categora, vale la pena conSiderar la discusin enCiclopdica de Powell [POWOO.Adems, los libros de Galitz [GAL02J. Helnlcke IHEI02J. Schmitt IDesgning CSS Web Pages, New Riders Publishing, 2002). Donnelly IDesigning Easy-to-use Websaes, Addison-wesley, 2001) y Nielsen INIEOOJproporcionan una guia til. La viSin agil del diseo (y otros tpicos) para webApps la presentan Wallace y sus colegas (Extreme ProgrammingJor Web Proecrs. Addison-Wesley, 2003). Con~len (Buildmg WebApplicalJons wah UML, segunda edicin, Addison-Wesley, 2002) y Rosenberg y Scott (Applymg Use-Case Dnven Obect Modeling with UML, Addison-Wesley, 2001 I presentan ejemplos detallados de WebApps modeladas con la aplicaein de UML. , Van Duyne v sus colegas (The Design ojSies: Paltems, Principies and Processes, Addison-Wesley, 2002) escribieron un libro excelente que cubre los aspectos mas importantes del proceso de diseo en la ingeniena Web. Se cubren en detalle los modelos de h'oceso de diseo y los patrones de diseo. Wodtke 1I,,{omlOtion Archirecture, New Riders Publishing, 2003). Rosenfeld y Morville (/n(nrmallon ATChl1ecture./orthe World Wide Web, O'Reilly & Associates, 2002). y Reiss (Pracl/cal In(omlOlJOn ArcJirecturc, Addison-Wesley, 2000) abordan la arquitectura de contenido y otros tOpICOS. Las tcnicas de diseo tambin se menCionan en libros eSCrItos acerca de ambientes de desarrollo especficos. Los lectores interesados deben examina. libros acerca de 2EE, ava, ASP.NET, CSS, XML. Per! y una diverSidad de aplicaciones de creacin de WebApps IDreamweaver, HomePage, Frontpage. GoUve, MacroMedia Flash. etc.) para comentarios de diseo tiles. En Internet est disponible una gran variedad de fuentes de informacin acerca de diseo para ingenieria Web. Una 1Istaactualizada de referencias en la World Wide Web se encuentra en el sitio Web de SEPA: http://www.mhhe.com/pressman.

J 9.11. Reconsldrese el "motor de aprendizaJe' descrito en el problema 19.7, selecclonese una arquitectura de conteJ1ldo que seria apropiada para la WebApp Ccomentese por qu se hiZO dicha eleCCin