Autores: Yusef Hassan, Francisco J. Martín Fernández y Ghzala Iazza (Universidad de Granada)
Citación recomendada: Yusef Hassan & Francisco J. Martín Fernández & Ghzala Iazza. Diseño Web Centrado en el Usuario: Usabilidad y Arquitectura de la Información [en linea]. "Hipertext.net", núm. 2, 2004. <http://www.hipertext.net>
1. Introducción
3. Arquitectura de la información
4. Diseño web centrado en el usuario
5.1. Diseño
5.1.1. Modelado del usuario
5.1.2. Diseño conceptual
5.1.3. Diseño visual y definición del estilo
5.1.4. Diseño de contenidos
5.2. Prototipado
5.3. Evaluación
5.3.1. Método por inspección: evaluación heurística
5.3.2. Método de test con usuarios
5.4. Implementación y lanzamiento
5.5. Mantenimiento y seguimiento
5.5.1. Opiniones de los usuarios
5.5.2. Comportamiento del usuario y uso del sitio
6. Conclusiones
7. Bibliografía
La consecución de los objetivos perseguidos a través de la puesta a disposición del público de cualquier aplicación web está condicionada por la satisfacción del usuario final.
Los factores o atributos de calidad de una aplicación o sitio web que influirán en dicha satisfacción podemos clasificarlos en aquellos relacionados con: la calidad y utilidad de los contenidos; la calidad del servicio y asistencia del proveedor; y la calidad del diseño de la aplicación, atributo de calidad sobre el que versa el presente trabajo.
La importancia del diseño de la aplicación se basa en que éste será el que modele la interacción entre usuario y aplicación, y por tanto posibilitará o no la consecución de los objetivos perseguidos por el usuario (encontrar información, comprar, comunicarse, aprender...).
Tomemos como ejemplo el usuario que intenta completar una tarea de compra en un sitio web de comercio electrónico. Del correcto diseño del sitio dependerá que el usuario consiga finalmente su objetivo (y consecuentemente el proveedor también), o que por el contrario, frustrado por la dificultad de uso del sitio web, decida abandonarlo en busca de otro donde llevar a cabo la compra sea más fácil.
Es fácil inferir que un buen diseño deberá ser comprensible, fácil de usar, amigable, claro, intuitivo y de fácil aprendizaje para el usuario. Para poder asegurar que un diseño cumple con estos requisitos no basta simplemente con una actitud empática del diseñador durante el desarrollo de la aplicación; es imprescindible la adopción por parte de éste de técnicas, procedimientos y métodos que aseguren empíricamente la adecuación del diseño a las necesidades, habilidades y objetivos del usuario.
En este artículo abordaremos cómo diseñar aplicaciones web usables y accesibles a través de la aplicación del conjunto de técnicas y procedimientos englobados bajo el marco metodológico conocido como Diseño Centrado en el Usuario. La estructura seguida en el artículo será: (2) Definición y explicación de los conceptos de usabilidad y accesibilidad; (3) Introducción a la Arquitectura de la Información; (4) Propuesta de aplicación del Diseño Centrado en el Usuario en el contexto del desarrollo Web, detallando procedimientos, técnicas, métodos y recomendaciones de diseño; (5) Conclusiones y (6) Bibliografía.
La usabilidad - anglicismo que significa "facilidad de uso" - como indican Bevan, Kirakowski, y Maissel (1991) parece tener su origen en la expresión "user friendly", que es reemplazada por sus connotaciones vagas y subjetivas.
Numerosos autores han propuesto diversas definiciones de usabilidad, normalmente a través de la enumeración de los diferentes atributos o factores mediante los que puede ser evaluada, dependiendo finalmente cada definición del enfoque con el que pretende ser medida (Folmer, Bosch; 2003).
Tomaremos para este trabajo la definición más extendida, que es la ofrecida por la ISO , y que define usabilidad como el " grado de eficacia, eficiencia y satisfacción con la que usuarios específicos pueden lograr objetivos específicos, en contextos de uso específicos ".
En la definición podemos observar que la usabilidad se compone de dos tipos de atributos:
Como se indica en la definición, la usabilidad de una aplicación debe ser entendida siempre en relación con la forma y condiciones de uso por parte de sus usuarios, así como con las características y necesidades propias de estos usuarios. Un diseño no es en sí mismo usable: " lo es para usuarios específicos en contextos de uso específicos ".
Pretender que una aplicación web sea usable independientemente de quién y cómo la use se corresponde más con una visión o enfoque universalista de la usabilidad (en ocasiones necesaria), que con una visión realista y práctica. Esto es debido a que normalmente toda aplicación se diseña con la intención de satisfacer las necesidades de una audiencia concreta y determinada, por lo que será más usable cuanto más adaptado esté su diseño a esta audiencia específica, y por tanto menos lo esté para el resto de personas.
El concepto de usabilidad puede ser definido, además de como atributo de calidad de una aplicación, consecuentemente, como disciplina o enfoque de diseño y evaluación. Se suele hablar entonces de Ingeniería de la Usabilidad - conjunto de fundamentos teóricos y metodológicos que aseguren el cumplimiento de los niveles de usabilidad requeridos para la aplicación-.
Un concepto íntimamente ligado al de usabilidad es el de accesibilidad. Éste ya no se refiere a la facilidad de uso, sino a la posibilidad de acceso. En concreto a que el diseño, como prerrequisito imprescindible para ser usable, posibilite el acceso a todos sus potenciales usuarios, sin excluir a aquellos con limitaciones individuales - discapacidades, dominio del idioma,... - o limitaciones derivadas del contexto de acceso - software y hardware empleado para acceder, ancho de banda de la conexión empleada, etc.- (Hassan Montero, Martín Fernández; 2003b)
Se da la paradoja de que mientras que un diseño usable requiere delimitar a su audiencia potencial con el fin de diseñar para lo concreto, un diseño accesible implica la necesidad de diseñar para la diversidad y heterogeneidad de necesidades de acceso presentadas por esta audiencia específica.
Cuando la audiencia para la que se diseña es muy amplia y presenta necesidades de acceso muy diferentes, normalmente se hace necesaria la puesta a disposición de varias versiones del diseño o un diseño adaptable, como son las conocidas "versiones solo texto" o versiones en varios idiomas.
Aunque para la mayoría de los usuarios "la interfaz es la aplicación" puesto que es la parte que ven y a través de la cual interactúan (Hartson; 1998) , debemos entender que la usabilidad de la aplicación depende no sólo del diseño del interfaz, sino también de su arquitectura - estructura y organización -, en otras palabras, del componente no visible del diseño.
Folmer y Bosch (2003) estudian este hecho en aplicaciones software concluyendo que el diseño a nivel de arquitectura tiene una gran influencia en la usabilidad del sistema. En el entorno Web, que es el que nos ocupa en este artículo, la Arquitectura de la Información (AI) es un enfoque de diseño que ha cobrado especial relevancia estos últimos años por esta misma razón.
La AI es definida como el arte y la ciencia de organizar espacios de información con el fin de ayudar a los usuarios a satisfacer sus necesidades de información. La actividad de organizar comporta la estructuración, clasificación y rotulado de los contenidos del sitio web (Toub; 2000).
Hay dos aspectos de la AI que merece la pena resaltar: La Recuperación de la Información : El objetivo principal de definir una correcta arquitectura de información es facilitar al usuario la recuperación de información. Esto se consigue por un lado posibilitando que el usuario pueda encontrar información - diseño y definición de índices, clasificaciones, taxonomías y sistemas de recuperación de información o sistemas de búsqueda en el sitio web -, y por otro lado posibilitando que cada elemento de información pueda ser encontrado - descripción a través de metadatos y optimización del sitio para buscadores-. Este segundo caso es lo que se denomina "findability", "encontrabilidad" o visibilidad.
El diseño a nivel conceptual : Las técnicas propias de la AI, dentro del ciclo de vida del desarrollo del sitio, se ubican en fases de diseño conceptual. Las fases de diseño visual están, en cambio, copadas por técnicas de Ingeniería de la Usabilidad, Diseño de Interfaces y Diseño de Información.
Para asegurar empíricamente que un sitio cumple con los niveles de usabilidad requeridos, el diseñador necesita de una metodología, de técnicas y procedimientos ideados para tal fin.
En este trabajo proponemos la aplicación del marco metodológico conocido como Diseño Centrado en el Usuario o User-Centered Design (Norman, Draper; 1986) adaptándolo a las características propias del desarrollo de aplicaciones web.
El Diseño Web Centrado en el Usuario se caracteriza por asumir que todo el proceso de diseño y desarrollo del sitio web debe estar conducido por el usuario, sus necesidades, características y objetivos. Centrar el diseño en sus usuarios (en oposición a centrarlo en las posibilidades tecnológicas o en nosotros mismos como diseñadores) implica involucrar desde el comienzo a los usuarios en el proceso de desarrollo del sitio; conocer cómo son, qué necesitan, para qué usan el sitio; testar el sitio con los propios usuarios; investigar cómo reaccionan ante el diseño, cómo es su experiencia de uso; e innovar siempre con el objetivo claro de mejorar la experiencia del usuario.
El proceso de Diseño Web Centrado en el Usuario propuesto en este trabajo se divide en varias fases o etapas, algunas de las cuales tienen carácter iterativo. Sirva como aproximación el siguiente esquema:
Como indica el esquema, las fases de "diseño", "prototipado" y "evaluación" son cíclicas e iterativas. Esto quiere decir que todo lo que se diseñe debe ser constantemente evaluado a través de su prototipado, para así poder corregir errores de usabilidad desde los primeros momentos del desarrollo. Evaluar el sitio web únicamente una vez finalizado su desarrollo haría mucho más costosa la reparación de errores de usabilidad, ya que siempre es más económico reconducir un diseño que rediseñar completamente el sitio.
Los siguientes apartados de este trabajo se estructuran siguiendo este mismo esquema del proceso de diseño.
Todo proyecto debe comenzar por una correcta planificación. En esta etapa se identifican los objetivos del sitio, así como las necesidades, requerimientos y objetivos de la audiencia potencial.
Confrontando esta información se definen los requerimientos del sitio web, entre los que podemos contar requerimientos técnicos (back-end y front-end), recursos humanos y perfiles profesionales necesarios, y adecuación del presupuesto disponible.
Se trata, pues, de establecer un equilibrio entre lo que puede ofertar el proveedor y lo que necesita el usuario. El sitio web - sus contenidos y diseño - debe cumplir precisamente este cometido: servir de medio para la consecución de objetivos por parte de proveedor y usuario.
El diseñador debe obtener información precisa tanto de las necesidades y objetivos del proveedor como del usuario. En el primer caso, mediante entrevistas y reuniones con los responsables del sitio, será relativamente fácil obtener dicha información. Más dificultoso, pero al mismo tiempo más importante, es obtener esta información del usuario: Qué necesita, cuáles son sus objetivos, cómo se comporta y actúa, cuál será el contexto de uso y cómo afectará a la interacción, experiencia y conocimientos previos,...
La respuesta a estas preguntas se resuelve estudiando a la audiencia a través de métodos de indagación. Éstos engloban métodos de aproximación contextual, estudios de campo o etnográficos, métodos de aproximación por grupos y métodos de aproximación individual (encuestas, cuestionarios y entrevistas). Cuanto más conozcamos a la audiencia, más adaptado será el diseño y más satisfactoria la experiencia del usuario final.
Como se puede ver, la etapa de planificación se basa casi completamente en la recogida, análisis y ordenación de toda la información posible, con el objetivo de tener una base sólida sobre la que poder tomar decisiones de diseño en las siguientes etapas del proceso.
5.1. Diseño
La etapa de Diseño es el momento del proceso de desarrollo para la toma de decisiones acerca de cómo diseñar o rediseñar, en base siempre al conocimiento obtenido en la etapa de planificación, así como a los problemas de usabilidad descubiertos en etapas de prototipado y evaluación.
5.1.1. Modelado del usuario
Toda la información obtenida de los estudios de usuarios realizados en la anterior fase de planificación debe servir como base para comenzar el diseño, pero para ello se debe resumir y sintetizar dicha información.
Este paso se denomina modelado del usuario y consiste en la definición de clases o perfiles de usuarios en base a atributos comunes. Los atributos sobre los que se hará la clasificación dependen de la información que se tenga de la audiencia, pero normalmente se tratarán de atributos tales como necesidades de información, condiciones de acceso, experiencia y conocimientos.
Mediante esta técnica, el diseñador tendrá en mente para quién diseña, qué espera encontrar el usuario y en qué forma. El diseño del sitio web debe estar orientado al usuario, organizando y estructurando la información según los modelos definidos de usuarios.
El problema de esta técnica de modelado de usuario es que cuando la audiencia es demasiado extensa y heterogénea, la categorización total de la audiencia puede no ser viable. En estos casos es conveniente hacer uso del enfoque 'persona', ideado por Cooper (1999).
Esta técnica de modelado del usuario se basa en la definición de arquetipos de usuarios que representan patrones de conducta, objetivos y necesidades. Estos arquetipos, llamados "personas", son descripciones en forma narrativa de usuarios, a los que se les da una identidad inventada: fotografía, nombre,... En cambio, todos los atributos, características y necesidades del arquetipo deben estar basados en información real extraída de la audiencia objetiva del sitio web, ya que si éstos fueran datos inventados la técnica perdería toda su utilidad.
Además se deben definir "scenarios" - descripciones de situaciones de uso del sitio - sobre los que poder contextualizar la interacción persona-aplicación web.
Las "personas" definidas, al contrario de lo que se pretendía con la categorización de la audiencia, no pueden representar al total de los usuarios del sitio web, pero es que ésta no es su misión.
La función de esta técnica es la de servir de soporte para la toma de decisiones en el diseño del sitio, permitiendo al desarrollador realizar un diseño centrado en el usuario, o más correctamente, en "algún" usuario. Este usuario podemos considerarlo 'real', ya que aunque no pertenece al mundo real, su descripción está basada sobre, y por tanto representa a, un nutrido grupo de usuarios reales.
Es demasiado común que el diseñador se imagine a sí mismo usando el sitio y por tanto sea incapaz de comprender por qué a alguien le puede resultar difícil, incomodo y hasta frustrante su uso. Estos arquetipos de usuarios conseguirán precisamente que el diseñador tenga en mente a un usuario 'real', con limitaciones, habilidades y necesidades reales.
5.1.2. Diseño conceptual
El objetivo de la fase de Diseño Conceptual es definir el esquema de organización, funcionamiento y navegación del sitio. No se especifica qué apariencia va a tener el sitio, sino que se centra en el concepto mismo del sitio: su arquitectura de información.
Los sitios web son sistemas hipermedia formados por conjuntos de páginas interrelacionadas por enlaces unidireccionales, pudiendo cada una de estas páginas contener sub-elementos con entidad propia, contenidos multimedia y herramientas interactivas.
La "estructura" del sitio web se refiere precisamente a las conexiones y relaciones entre páginas, a la topología de la red de páginas, así como a la granularidad de los elementos de información contenidos en las páginas; y la "navegación" a las posibilidades y forma en que cada página presenta las opciones de desplazamiento hacia otras páginas.
La definición de la estructura del sitio puede hacerse desde dos enfoques diferentes y complementarios: aproximación descendente y ascendente. En la descendente se trata de estructurar del "todo" a las "partes", dividir los contenidos en páginas y definir los enlaces entre páginas. En la Ascendente, por el contrario, se definen los bloques mínimos de información, estructuración que va más allá de la propia segmentación de información en páginas.
Una vez definida la estructuración del sitio es necesario documentarla, para así tener un modelo de referencia sobre el que sustentar el desarrollo del sitio. La forma de documentar arquitecturas se suele hacer a través de grafos y esquemas, con el objetivo de que sean de fácil y rápida comprensión por todos los miembros del equipo de desarrollo.
Si la arquitectura es ascendente normalmente se documentará a través de diagramas entidad-relación. Por otro lado, cuando la arquitectura a documentar es la descendente, para sitios web proponemos el uso del vocabulario gráfico de Garret (2002). A través de unas sencillas convenciones gráficas para la diagramación de la arquitectura, podemos definir la estructura de la información así como la navegación del sitio.
Otras tareas a llevar a cabo por el Arquitecto de Información o diseñador en la fase de Diseño Conceptual son: Definir sistemas de clasificación para los contenidos; Elaborar índices y mapas del sitio; Aplicar metadatos a cada una de las páginas y sub-elementos de información; y Definir el Sistema de Rotulado (Rosenfeld, Morville; 2002).
Entre las técnicas de Diseño Centrado en el Usuario a aplicar en la etapa de Diseño Conceptual destacamos, por su utilidad y facilidad de ser llevada a cabo, la técnica de "card sorting" u ordenación de tarjetas. Ésta se basa en la observación de cómo los usuarios agrupan y asocian entre sí un número predeterminado de tarjetas etiquetadas con las diferentes categorías o secciones temáticas del sitio web. De esta forma, partiendo del comportamiento de los propios usuarios, es posible organizar y clasificar la información de un sitio web conforme a su modelo mental. (Hassan Montero et al.; 2004)
5.1.3. Diseño visual y definición del estilo
En esta fase se especifica el aspecto visual del sitio web: composición de cada tipo de página, aspecto y comportamiento de los elementos de interacción y presentación de elementos multimedia.
Con el objetivo de evitar la sobrecara informativa, en el diseño de cada interfaz se debe tener en cuenta el comportamiento del usuario en el barrido visual de la página, distribuyendo los elementos de información y navegación según su importancia en zonas de mayor o menor jerarquía visual - por ejemplo, las zonas superiores del interfaz poseen más jerarquía visual que las inferiores-.
Además de la posición de cada elemento en la interfaz, existen otras técnicas para jerarquizar información como son: uso del tamaño y espacio ocupado por cada elemento para otorgarle importancia en la jerarquía visual, utilización del contraste de color para discriminar y distribuir información, uso de efectos tipográficos para enfatizar contenidos, rotura de la simetría y uso de efectos de relieve / profundidad para resaltar elementos, etc.
Además de evitar la sobrecarga informativa jerarquizando los contenidos mediante las técnicas descritas, para evitar la sobrecarga memorística se recomienda definir menús de navegación con un número de opciones reducido, normalmente no más de nueve diferentes.
Otro aspecto importante en el diseño visual del sitio es la accesibilidad. En el uso de colores, por ejemplo, se debe ofrecer suficiente contraste entre texto y fondo para no dificultar la lectura, e igualmente seleccionar combinaciones de colores teniendo siempre en cuenta las discapacidades visuales en la percepción del color que pudieran presentar nuestros usuarios.
Al utilizar imágenes en el diseño, por motivos de accesibilidad y comprensibilidad, se debe cuidar su resolución y tamaño, así como en fotografías la no pérdida de significación o contexto por recorte o minimización excesiva de la imagen.
Desde una perspectiva más amplia del diseño visual del sitio es importante mantener una coherencia y estilo común entre todas las páginas, proporcionando una consistencia visual a todo el sitio. Para asegurar que esta coherencia se cumple, es útil elaborar un libro o guía de estilo que sirva de documento referencia para todo el equipo de desarrollo.
5.1.4. Diseño de contenidos
En el diseño de contenidos hipermedia se debe mantener un equilibrio entre lo que serían contenidos que no aprovechasen las nuevas posibilidades hipertexto y multimedia, y lo que serían contenidos caóticos o desorientativos debido a un uso excesivo y no sosegado de las posibilidades hipermedia.
Sin prescindir de las capacidades que ofrece el nuevo medio, de lo que se trata es de diseñar contenidos interrelacionados y vinculados, manteniendo cierta coherencia informativa, comunicacional y organizativa.
La escritura hipertextual se debe realizar de forma diferente a la tradicional. El nuevo medio y sus características obligan a ser concisos, precisos, creativos y estructurados a la hora de redactar. Debemos conocer a quién nos dirigimos y adaptar el lenguaje, tono y vocabulario utilizado al usuario objetivo.
Algunos consejos a seguir en el diseño y redacción de contenidos son:
5.2. Prototipado
La evaluación de la usabilidad del sitio web se debe realizar desde las primeras etapas de diseño, pero ¿cómo evaluar un sitio web que no está implementado? A través de prototipos.
La etapa de prototipado se basa en la elaboración de modelos o prototipos de la interfaz del sitio. Su aspecto no se corresponde exactamente con el que tendrá el sitio una vez finalizado, pero pueden servir para evaluar la usabilidad del sitio sin necesidad de esperar a su implementación.
Según Floría Cortés (2000) , podemos clasificar los tipos de prototipado según el nivel de funcionalidad reproducida:
Según el grado de fidelidad o calidad del prototipo se distingue entre:
En las primeras etapas de desarrollo del sitio web se puede hacer uso del prototipado en papel o de bajo coste, que consiste en reproducir los aspectos básicos de la interfaz del sitio en papel.
Por ejemplo, podemos reproducir a través de bocetos cómo serán las diferentes páginas que conformarán el sitio a desarrollar, cada una en una página de papel diferente. La reproducción suele ser a mano (lápiz y tijeras), por lo que resulta una técnica de prototipado muy económica.
Otra forma de realizar prototipos es mediante la reproducción del aspecto del sitio a través de herramientas software. Mediante el procesador de textos o un simple editor HTML podemos esbozar cómo será la interfaz del sitio.
Hay que recordar que estos prototipos son reproducciones, no estados tempranos de implementación de la interfaz. Una vez que el prototipo se ha utilizado se tira, no es parte del sitio web.
La utilidad real del prototipado se fundamenta en que no tendría sentido empezar a implementar una interfaz web si no nos hemos asegurado antes de que el diseño es usable.
5.3. Evaluación
La evaluación de la usabilidad - la etapa más importante en el proceso de Diseño Centrado en el Usuario - se puede realizar a través de varios métodos o técnicas y sobre diferentes representaciones del sitio (prototipos en papel, prototipos software, sitio web implementado...).
Existe una gran diversidad de métodos para evaluación de usabilidad, aunque en el presente trabajo únicamente se describirán aquellos que creemos de más utilidad y aplicabilidad real en el contexto del desarrollo de aplicaciones web.
5.3.1. Método por inspección: evaluación heurística
Los métodos de inspección de la usabilidad de un sitio web son aquellos realizados por el experto en usabilidad, y que se basan en el recorrido y análisis del sitio identificando errores y problemas de diseño.
La Evaluación Heurística es un tipo de método de inspección, que tiene como ventaja la facilidad y rapidez con la que se puede llevar a cabo.
Este tipo de evaluación normalmente la lleva a cabo un grupo reducido de evaluadores que, en base a su propia experiencia, fundamentándose en reconocidos principios de usabilidad (heurísticos), y apoyándose en guías elaboradas para tal fin, evalúan de forma independiente el sitio web, contrastando finalmente los resultados con el resto de evaluadores.
Diversos autores han propuesto diferentes conjuntos de heurísticos o principios de usabilidad a través de los cuales evaluar la usabilidad. Nielsen (1994a) propone los siguientes:
Hassan Montero y Martín Fernández (2003a) proponen el siguiente modelo de evaluación heurística:
5.3.2. Método de test con usuarios
El test con usuarios es una prueba de usabilidad que se basa en la observación y análisis de cómo un grupo de usuarios reales utiliza el sitio web, anotando los problemas de uso con los que se encuentran para poder solucionarlos posteriormente.
Como toda evaluación de usabilidad, cuanto más esperamos para su realización, más costoso resultará la reparación de los errores de diseño descubiertos. Esto quiere decir que no sólo debemos realizar este tipo de pruebas sobre el sitio web una vez implementado, sino también, sobre los prototipos del sitio.
Es una prueba complementaria a la evaluación heurística, pero un test con usuarios es más costoso, por lo que es recomendable realizarlo siempre después de una evaluación heurística, ya que sería desperdiciar tiempo y dinero utilizarlo para descubrir errores de diseño motivados por el no cumplimiento en el desarrollo de principios generales de usabilidad (heurísticos).
La ventaja que ofrecen los test de usuarios frente a otro tipo de evaluaciones es que por un lado es una demostración con hechos, por lo que sus resultados son más fiables, y por otro porque posibilitan el descubrimiento de errores de diseño imposibles o difíciles de descubrir mediante la evaluación heurística.
Llevar a cabo un test de usuarios formal obligaría a alquilar un local (laboratorio) adecuado, contratar a evaluadores especializados, así como a delegar en alguna empresa la selección y reclutamiento de los participantes de la prueba. Realmente sería bastante costoso y poco viable para la gran mayoría de casos.
Existe otra forma de llevar a cabo un test con usuarios popularizada por Nielsen (1994b) , mucho más económica y fácil de realizar, con resultados y utilidad similares, que son las denominadas pruebas informales o test de 'guerrilla'.
En (Hassan Montero, Martín Fernández; 2003c) se detalla cómo llevar a cabo este tipo de pruebas: reclutamiento de participantes, elección del local y materiales, realización de la prueba y elaboración del informe final.
5.4. Implementación y lanzamiento
En la implementación del sitio es recomendable utilizar estándares (HTML, XHTML...) para asegurar la futura compatibilidad y escalabilidad del sitio. Esto se debe a que, aunque puede ser tentador utilizar tecnologías propietarias, el panorama tecnológico puede hacerlas desaparecer o cambiar en poco tiempo.
Igualmente es recomendable separar en la implementación contenido de estilo, mediante el uso de hojas de estilo (CSS) del lado del cliente y uso de bases de datos del lado del servidor. De esta forma se facilitará tanto el rediseño del sitio como la posibilidad de adaptación dinámica del diseño a las necesidades de acceso de cada tipo de usuario.
En esta etapa del desarrollo se debe llevar, así mismo, un control de calidad de la implementación, supervisando que todo funcione y responda a cómo había sido planificado, ya que la usabilidad del sitio depende directamente de la funcionalidad. Si algo no funciona, sencillamente no se puede usar.
Entre las técnicas para controlar la calidad de la implementación se pueden utilizar validadores automáticos de código como los proporcionados por el W3C ( http://www.w3c.org ), así como validadores para testar de forma semi-automática el cumplimiento de directrices de accesibilidad en el código, como el Test de Accesibilidad Web ( http://www.tawdis.net ).
Una vez implementado el sitio y testada su funcionalidad se procede al lanzamiento del sitio, que consiste en su puesta a disposición para los usuarios. Se trata de un evento importante, muchas veces erróneamente apresurado debido a la necesidad de cumplir plazos de entrega.
El primer encuentro entre usuario y el sitio web modelará en gran medida la percepción que el usuario tendrá del sitio en posteriores visitas. Por ello es necesario que durante los primeros meses a partir del lanzamiento, el sitio tenga un diseño y contenidos adaptados a este importante momento de su ciclo de vida. Es el momento de explicar a los usuarios el sitio, de enseñarles a usarlo, darles la bienvenida, "vendérselo"...
Después de esos primeros meses de vida la audiencia del sitio habrá cambiado. Seguirá habiendo usuarios que accedan por primera vez al sitio, pero ya no representarán a la mayoría de la audiencia. A los usuarios habituales no se les puede seguir haciendo perder el tiempo dándoles la bienvenida o explicándoles qué es y en qué consiste el sitio web.
Para asegurar que el sito llega a su audiencia potencial se hace uso de la promoción. La forma de llevar a cabo una campaña de publicidad o promoción dependerá de la naturaleza y características del sitio web.
Se debe crear expectación, un conocimiento previo del sitio en los potenciales usuarios. Para ello es recomendable que antes del lanzamiento, desde la misma URL que tendrá finalmente el sitio, se ofrezca una página web explicativa de lo que será el sitio, cuándo estará disponible, así como información de contacto.
Una vez realizado el lanzamiento se deben utilizar técnicas de promoción para atraer a los usuarios hacia el sitio:
5.5. Mantenimiento y seguimiento
Un sitio web no es una entidad estática, es un objeto vivo cuyos contenidos cambian; cuya audiencia, necesidades y perfiles cambian, y que por lo tanto requiere de continuos rediseños y mejoras.
Estos rediseños deben ser muy sutiles, no se puede cambiar el aspecto y diseño de forma drástica de un día para otro, pues aunque estos cambios estén fundamentados en problemas de usabilidad descubiertos post-lanzamiento, los cambios pueden resultar dramáticos para los actuales usuarios que ya estaban acostumbrados y familiarizados con el actual diseño.
Los problemas de uso no detectados durante el proceso de desarrollo pueden descubrirse a través de varios métodos, principalmente a través de los mensajes y opiniones de los usuarios, y su comportamiento y uso del sitio.
5.5.1. Opiniones de los usuarios
Esta información puede ser obtenida de forma pasiva - a través de los mensajes enviados por los usuarios acerca de problemas que han tenido con el uso del sitio - o de forma activa - por medio de cuestionarios y encuestas realizadas sobre la audiencia -.
Las opiniones expresadas por los usuarios indican posibles problemas de usabilidad, pero no son en sí mismas la respuesta a estos problemas. Por ejemplo, si un usuario envía un email preguntando por qué desde la home page no encuentra un enlace al recurso X, no significa que debamos implementar este enlace, sino que posiblemente el recurso X sea poco visible o de difícil localización.
Igualmente, en los cuestionarios no se deben hacer preguntas del tipo "¿Preferiría que el diseño fuera de tal forma?", sino del tipo "¿Ha tenido algún problema para localizar el recurso X?" ó "¿Le ha resultado fácil el uso de la herramienta X?". Los resultados de los cuestionarios no indican la usabilidad del sitio, sino la satisfacción del usuario. Si la satisfacción es baja, habrá que mejorar la usabilidad.
5.5.2. Comportamiento del usuario y uso del sitio
Una vez que el sitio web ha sido lanzado y es usado diariamente, tenemos a nuestra disposición una nueva fuente de información sobre el comportamiento del usuario: Los ficheros "log".
Estos, son extensos ficheros de texto plano que genera el servidor web, y en los que se registra cada una de las peticiones de páginas realizadas por los clientes al servidor.
Por cada petición del cliente al servidor se suele registrar la siguiente información:
A través del análisis de los ficheros logs se pueden responder preguntas como: ¿quién usa el sitio? ¿cuándo lo usa? ¿qué páginas suelen ser las más visitadas? ¿desde qué páginas se llega? ¿qué términos utiliza el usuario para interrogar al buscador interno?...
Se trata realmente de una información muy valiosa que correctamente analizada (normalmente ayudándonos de software específico), puede servirnos para la toma de decisiones sobre el rediseño en sitios web implementados.
En este trabajo se ha descrito, a grandes rasgos, cómo diseñar sitios web usables a través de la aplicación de técnicas, recomendaciones de diseño, métodos y procedimientos de Diseño Centrado en el Usuario.
El Diseño Web Centrado en el Usuario es un marco metodológico y una filosofía de diseño claramente multidisciplinar, por lo que en la práctica debería ser aplicado idealmente por equipos de desarrollo interdisciplinares. En el contexto de estos equipos de desarrollo, el perfil del profesional de la documentación se adecua especialmente con las tareas de Arquitectura de Información.
Es de esperar que ante la posibilidad de conquista de nuevos nichos de trabajo, todos estos nuevos conocimientos se vayan integrando en los actuales planes de estudio de Biblioteconomía y Documentación, así como la proliferación de cursos de formación especializada impartidos por investigadores de nuestra área.
Bevan, N.; Kirakowski, J.; Maissel, J. (1991). What is Usability?. Proceedings of the 4th International Conference on HCI, Stuttgart, September 1991. Elsevier.
Copper, A. (1999). The Inmates Are Running the Asylum: Why High-Tech Products Drive Us Crazy and How to Restore the Sanity. SAMS. ISBN: 0-67231-649-8.
Floría Cortés, A. (2000). Recopilación de Métodos de Usabilidad . SIDAR. Disponible en: http://www.sidar.org/recur/desdi/traduc/es/visitable/Herramientas.htm
Folmer, E., Bosch, J. (2004). Architecting for usability: a survey. En: Journal of Systems and Software. Febrero 2004, v. 70, n. 1-2. pp. 61-78.
Garret, J.J. .(2002). Un vocabulario visual para describir arquitectura de información y diseño de interacción . Disponible en: http://www.jjg.net/ia/visvocab/spanish.html
Hartson, H.R. (1998). Human-computer interaction: Interdisciplinary roots and trends. En: Journal of Systems and Software, Noviembre 1998, v. 43, n. 2, pp. 103-118.
Hassan Montero, Y. Martín Fernández, F.J. (2003a). Guía de Evaluación Heurística de sitios web . Disponible en: http://www.nosolousabilidad.com/articulos/heuristica.htm
Hassan Montero, Y. Martín Fernández, F.J . (2003b). Que es la Accesibilidad Web . Disponible en: http://www.nosolousabilidad.com/articulos/accesibilidad.htm
Hassan Montero, Y. Martín Fernández, F.J. (2003c). Método de test con usuarios . Disponible en: http://www.nosolousabilidad.com/articulos/test_usuarios.htm
Hassan Montero, Y. et al. (2004). Arquitectura de la Información en los entornos virtuales de aprendizaje. Aplicación de la técnica de Card Sorting y análisis cuantitativo de los resultados. En: El Profesional de la Información, 2004, marzo-abril, v. 13, n. 2, pp. 93-99.
ISO 9241-11. (1998). Ergonomic requirements for office work with visual display terminals (VDT)s - Part 11 Guidance on usability, 1998.
Nielsen, J. (1994a). Ten Usability Heuristics . Disponible en: http://www.useit.com/papers/heuristic/heuristic_list.html
Nielsen, J. (1994b). Guerrilla HCI: Using Discount Usability Engineering to Penetrate the Intimidation Barrier . Disponible en: http://www.useit.com/papers/guerrilla_hci.html
Norman, D. A.; Draper, S. W. (Eds.) (1986). User centered system design: New perspectives on human-computer interaction. Hillsdale, NJ: Lawrence Erlbaum Associates.
Rosenfeld, L.; Morville, P. (2002). Information Architecture for the World Wide Web. 2nd edition. ISBN 0-596-00035-9. 2002.
Toub, S. (2000). Evaluating Information Architecture: A Practical Guide to Assessing Web Site Organization . ARGUS Associates. Disponible en: http://argus-acia.com/white_papers/evaluating_ia.html
El diseño rápido se centra en una representación de aquellos aspectos del software que serán visibles para el cliente o el usuario final. El prototipo es evaluado por el cliente para una retroalimentación; gracias a ésta se refinan los requisitos del software que se desarrollará.
Ventajas
Inconvenientes
Existen varios tipos de prototipos, cada uno de los cuales permite la realización de un tipo determinado de pruebas y con un determinado nivel de realismo. En ingeniería de requisitos, los prototipos más comunes son los siguientes:
Las maquetas acostumbran a realizarse mediante programas gráficos de diseño, tales como Visual Basic o PowerBuilder, por citar ejemplos.
¿Qué tipo de prototipo se debe construir?
La respuesta depende de dos factores:
Tampoco se debe olvidar que el analista deberá suplir al usuario la información que el prototipo no pueda suministrar (mensajes de error, resultados de los cálculos, etc.).
Una de las peores cosas que le puede pasar a un profesional es diseñar e implantar un sistema que el usuario no necesita, ni desean.
Características de la Interfaz de usuario:
Estos prototipos son directrices obligatorias que se deben seguir para desarrollar aplicaciones para la Junta de Andalucía según el marco de desarrollo de la misma.
Prototipo de pantalla de búsqueda avanzada
Prototipo de pantalla de búsqueda simple
Prototipo de pantalla de login
Prototipo de pantalla de consulta de detalle
Prototipo de pantalla de introducción de datos
Prototipo de pantalla de ayuda
Prototipo de pantalla de error
Prototipo de pantalla de listado simple
Prototipo de pantalla de listado avanzado
Prototipo de pantalla de confirmación de eliminación
La aplicación Scene Builder permite diseñar, mediante un interfaz gráfico, las estructuras de las ventanas de las aplicaciones que queramos desarrollar usando JavaFX. En este artículo podrás conocer los fundamentos básicos para empezar a usar esta herramienta de manera integrada con el entorno de desarrollo NetBeans.
Descarga de Scene Builder: http://gluonhq.com/open-source/scene-builder/
Con el fin de que cuando se abra un archivo FXML desde NetBeans se muestre directamente con la herramienta Scene Buider, se debe indicar en la configuración de NetBeans en qué carpeta se encuentra Scene Buider.
En el artículo Using Scene Builder with NetBeans IDE de la web de Oracle se puede obtener también información sobre los pasos a seguir.
La versión 8.0 de Scene Builder se encuentra instalada por defecto en la carpeta C:\Users\TU_USUARIO\AppData\Local\SceneBuilder\SceneBuilder.exe
Puedes acceder a las opciones de configuración de NetBeans en el menú Tools > Options. Ahí accede a la sección Java y la pestaña JavaFX:
En NetBeans 8.0.2 no se reconoce la carpeta de instalación de Scene Builder. En cambio en la versión 8.1 RC de NetBeans que es la más moderna a la que se puede acceder en el momento de crear este artículo, se detecta automáticamente la carpeta de instalación de Scene Builder:
Utiliza el asistente de creación de proyectos de NetBeans para crear un proyecto de tipo JavaFX > JavaFX FXML Application, que crear automáticamente la estructura básicas de una aplicación JavaFX con un archivo FXML básico para la estructura de la pantalla.
Al hacer doble clic sobre el archivo FXML que se crea, o bien seleccionando la opción Open de su menú contextual, verás que se abre automáticamente la aplicación Scene Builder con ese documento abierto.
También puede optar por ver el código fuente de dicho archivo desde NetBeans. Si no lo encuentras en las pestañas de los archivos que se encuentren abiertos, puedes usar la opción Editar de su menú contextual. Como puedes observar, se trata de una archivo XML que contiene la estructura de la ventana, la cual puedes diseñar editando este código o de manera visual desde la aplicación Scene Builder.
Como cualquier otra aplicación Java, al usar el botón Run de NetBeans, podrás ver en ejecución la aplicación tal como se encuentre desarrollada hasta ese momento. Al hacerlo sobre el proyecto recién creado podrás ver una ventana con un botón "Click Me!" que al pulsarlo muestra debajo el mensaje "Hello World!".
En la estructura del proyecto que se acaba de crear, puedes ver que se han generado automáticamente 3 archivos:
Esta es la manera en la que están relacionados entre ellos:
La clase java JavaFXApplication1 es la principal en este proyecto, y será la que inicia la ejecución de la aplicación. Dentro de su código fuente puedes observar que se encarga de cargar la estructura de la ventana contenida en el archivo FXMLDocument.fxml:
package
javafxapplication1
;
import
javafx.application.Application
;
import
javafx.fxml.FXMLLoader
;
import
javafx.scene.Parent
;
import
javafx.scene.Scene
;
import
javafx.stage.Stage
;
public class JavaFXApplication1 extends Application
{
@
Override
public
void
start
(
Stage stage
)
throws
Exception
{
Parent root =
FXMLLoader.
load
(
getClass
()
.
getResource
(
"FXMLDocument.fxml"
))
;
Scene scene = new Scene
(
root
)
;
stage.
setScene
(
scene
)
;
stage.
show
()
;
}
public static
void
main
(
String
[]
args
)
{
launch
(
args
)
;
}
}
A su vez, el archivo FXMLDocument.fxml hace referencia en su código a la clase Java FXMLDocumentController que va a hacer las funciones de controlador, gestionando las acciones que realice el usuario sobre los elementos de la ventana. Puedes ver el código fuente contenido en este archivo editándolo desde NetBeans:
<?xml
version
=
"1.0"
encoding
=
"UTF-8"
?>
<?import
java.lang.*
?>
<?import
java.util.*
?>
<?import
javafx.scene.*
?>
<?import
javafx.scene.control.*
?>
<?import
javafx.scene.layout.*
?>
<AnchorPane
id
=
"AnchorPane"
prefHeight
=
"200"
prefWidth
=
"320"
xmlns:fx
=
"http://javafx.com/fxml/1"
fx:controller
=
"
javafxapplication1.FXMLDocumentController
"
>
<children>
<Button
layoutX
=
"126"
layoutY
=
"90"
text
=
"Click Me!"
onAction
=
"
#handleButtonAction
"
fx:id
=
"button"
/>
<Label
layoutX
=
"126"
layoutY
=
"120"
minHeight
=
"16"
minWidth
=
"69"
fx:id
=
"label"
/>
</children>
</AnchorPane>
Desde Scene Builder también puedes ver o modificar la clase Java que va a hacer las funciones de controlador, concretamente desde el apartado Controller que puedes encontrar en la parte inferior derecha.
Dentro del trozo de código correspondiente al botón (Button) en el archivo que se acaba de mostrar, puedes observar que se hace referencia al método que se ejecutará cuando el usuario de la aplicación haga clic en él. En concreto se indica que se ejecute el método handleButtonAction que se encuentra dentro del controlador FXMLDocumentController.
Este es el código fuente del controlador (FXMLDocumentController.java):
package
javafxapplication1
;
import
java.net.URL
;
import
java.util.ResourceBundle
;
import
javafx.event.ActionEvent
;
import
javafx.fxml.FXML
;
import
javafx.fxml.Initializable
;
import
javafx.scene.control.Label
;
public class
FXMLDocumentController
implements Initializable
{
@FXML
private
Label
label
;
@FXML
private
void
handleButtonAction
(
ActionEvent
event
)
{
System
.
out
.
println
(
"You clicked me!"
)
;
label.
setText
(
"Hello World!"
)
;
}
@
Override
public
void
initialize
(
URL
url,
ResourceBundle
rb
)
{
// TODO
}
}
Observa que para que un método pueda ser invocado desde el archivo FXML, debe indicarse antes de la declaración de dicho método la anotación @FXML.
De manera similar, observa que antes de la declaración del elemento label también se ha usado esa anotación. Eso es necesario también en ese caso, ya que desde el código Java se está haciendo referencia al elemento con ese mismo nombre (label) para cambiar el texto que contiene (recuerda que aparece el texto Hello World!)
En el archivo FXML has podido ver que se había declarado
<Label
layoutX
=
"126"
layoutY
=
"120"
minHeight
=
"16"
minWidth
=
"69"
fx:id
=
"
label
"
/>
En el controlador Java se ha declarado como:
@FXML
private
Label
label
;
Y se ha cambiado su contenido con:
label
.
setText
(
"Hello World!"
)
;