Usable y accesible

Modificación de la Ley 34/2002 que obliga al consentimiento expreso del usuario para el uso de cookies

2012-05-17T10:53:00.000+02:00

Para comprender estas modificaciones y sus implicaciones, os recomiendo tres artículos:

Entra en vigor la “ley de cookies” en España, Eduard Barredo, 04/04/2012
Cómo cumplir con la nueva ley de cookies (parte I), Sergio Maldonado, 19/04/2012
Cómo cumplir con la nueva ley de cookies (parte II). Ejemplo práctico, Sergio Maldonado, 20/04/2012

Web Usability Guidelines–Directrices de usabilidad web

2012-03-22T10:43:00.012+01:00

Artículo anterior: Qué teclas de acceso rápido (accesskey) utilizar

Última actualización: 26/03/2012

En el artículo Estándares formales de usabilidad y su aplicación práctica en una evaluación heurística definí qué es un estándar y la diferencia entre estándares oficiales (o “de jure” o formales) y estándares “de facto” (o no formales)

En dicho artículo traté los estándares oficiales, repasando las diferentes normas ISO existentes, donde destaca la norma ISO 9241-151 que presenta una checklist de validación.

Asimismo repasé diferentes propuestas basadas en estas normas ISO que incluían formas prácticas de aplicarlas en una evaluación heurística, en especial WUEP (Web Usability Evaluation Process)

Por ello incluí la descarga de una excel con las subcaracterísticas (y descripción), atributos (y su descripción) y métricas, a modo de herramienta de ayuda, para la elaboración de una evaluación de usabilidad de una web de acuerdo a la ISO 25000 (SQUARE), según el modelo propuesto por WUEP (Web Usability Evaluation Process)

En este artículo repaso, fuera ya de los que son los estándares formales, diferentes propuestas de directrices de usabilidad web, - algunas de las cuáles se pueden considerar estándares “de facto”-, con listas de verificación (checklist) asociadas, que permitan la evaluación heurística de los sitios en base a dichas directrices.

No está de más recordar que las directrices de usabilidad no pueden considerarse nunca reglas fijas ni pueden ser aplicadas por igual en todos los sitios web, siempre habrá que tener en cuenta y reflexionar sobre el tipo de sitio, su audiencia, sus objetivos o su contexto.

He seleccionado las que me parecen más relevantes, incluyendo al final un listado con otros enlaces de interés. Os animo a que dejéis en los comentarios aquellas que no he incluido pero os parecen relevantes.

Índice

HHS Guidelines
247 directrices de usabilidad de Userfocus
Nielsen Norman Group Guidelines
Swedish National Guidelines for Public Sector Websites
SIRIUS
Australia Government Usability Checklist
Guía para el Desarrollo de Sitios Web del Gobierno de Chile
Usability Guidelines del MIT
Directrices de usabilidad para sitios web del Estado colombiano
Otros enlaces de interés

HHS Guidelines

Las "HHS Guidelines" son las directrices de diseño web y usabilidad del Gobierno de EEEUU. Fueron desarrolladas por el U.S. Department of Health and Human Services (HHS) en 2004, de ahí que se las conozca como las HHS Guidelines.

Están disponibles en formato PDF en el documento Research-Based Web Design and Usability Guidelines (PDF 20.64 MB)

Fueron realizadas y revisadas por diseñadores y expertos de usabilidad basándose en la investigación de diferentes campos (citan en concreto: cognitive psychology, computer science, human factors, technical communication y usability)

En la actualidad cuenta con 209 directrices (en la primera edición eran 187) que, tras un estudio de cardsorting, se agruparon en 18 temas:

Proceso de diseño y evaluación (11 directrices)
Optimizando la experiencia de usuario (16 directrices)
Accesibilidad (13 directrices)
Hardware y software (5 directrices)
La página de inicio (9 directrices)
Esquema de la página (layout) (13 directrices)
Navegación (12 directrices)
Desplazamiento (scrolling) y paginado (5 directrices)
Encabezados, títulos y etiquetas (8 directrices)
Enlaces (14 directrices)
Apariencia del texto (11 directrices)
Listas (9 directrices)
Controles y Widgets (25 directrices)
Gráficos, imágenes y multimedia (16 directrices)
Escribiendo contenido web (11 directrices)
Organización del contenido (9 directrices)
Búsqueda (9 directrices)
Test de usabilidad (13 directrices)

Se puede consultar de forma individual cada uno de estos capítulos en la página Guidelines de la web usability.gov Esta web del Gobierno de EEUU recoge la metodología que se debe aplicar en la construcción de un sitio web bajo una metodología de Diseño Centrado en el Usuario, dentro de la cuál cumplir con estas directrices sólo es un paso más. Traté en profundidad esta web y su metodología propuesta en el artículo La usabilidad como metodología para el desarrollo de una aplicación

Dentro de cada capítulo las directrices están ordenadas de más a menos importantes. La estructura de cada directriz es la siguiente:

Como se aprecia consta de:

Numeración y título de la directriz ("1:1 Provide Useful Content")
Guideline, título extendido de la directriz;
Comments, descripción de la directriz indicando en qué consiste y por qué hay que cumplirla;
Sources, referencias sobre esta directriz;
Ejemplos, solo disponibles en algunas directrices.
Relativa Importance, importancia de la directriz que están clasificadas de 1 a 5 (5 las más importantes, 1 las menos importantes) La clasificación fue llevada a cabo por una encuesta a numerosos expertos en usabilidad.
Strength of Evidence, indica la "medida de confianza" clasificada de 1 a 5 (5 las que mayor nivel de confianza ofrecen y 1 las que menos) La medida de confianza está basada en la calificación dada por numerosos expertos en usabilidad (y en la que, según se indica, hubo alto grado de coincidencia) que buscaron evidencias de esa directriz en investigaciones, estudios, resultados de experimentos, etc.

La medida de confianza se define de la siguiente manera:

5 – Strong Research Support
- Cumulative and compelling, supporting research-based evidence
- At least one formal, rigorous study with contextual validity
- No known conflicting research-based findings
- Expert opinion agrees with the research
4 – Moderate Research Support
- Cumulative research-based evidence
- There may or may not be conflicting research-based findings
- Expert opinion
- Tends to agree with the research, and
- A consensus seems to be building
3 – Weak Research Support
- Limited research-based evidence
- Conflicting research-based findings may exist
- There is mixed agreement of expert opinions
2 – Strong Expert Opinion Support
- No research-based evidence
- Experts tend to agree, although there may not be a consensus
- Multiple supporting expert opinions in textbooks, style guides, etc.
- Generally accepted as a ’best practice’ or reflects ’state of practice’
1 – Weak Expert Opinion Support
- No research-based evidence
- Limited or conflicting expert opinion

En el apéndice de la guía encontramos lo que puede servirnos de checklist (PDF 20.64 MB), que es el listado de todas las directrices agrupadas por su importancia.

Se puede consultar una comparativa entre la ISO 9241-151 y las HHS Guidelines en BEVAN, N. , SPINHOF, L. (2007): "Are guidelines and standards for web usability comprehensive?" (PDF)

247 directrices de usabilidad web de Userfocus

Userfocus propone 247 directrices de usabilidad que distribuye en 9 heurísticos:

Usabilidad de la página de inicio (20 directrices)
Orientado a tareas (44 directrices)
Navegación y Arquitectura de Información (29 directrices)
Formularios y entrada de datos (23 directrices)
Confianza y credibilidad (13 directrices)
Escritura y calidad de los contenidos (23 directrices)
Esquema de la página (layout) y diseño visual (38 directrices)
Usabilidad en la búsqueda (20 directrices)
Ayuda, feedback y tolerancia a errores (37 directrices)

Una gran ventaja es que ofrece gratuitamente una excel de trabajo con las 247 directrices (traducida al español) que facilita la valoración y la inclusión de comentarios.

Nielsen Norman Group Guidelines

Posiblemente los 10 heurísticos de Jakob Nielsen sean los más conocidos:

Visibilidad del estado del sistema.
Utilizar el lenguaje de los usuarios.
Control y libertad para el usuario.
Consistencia y estándares.
Prevención de errores.
Minimizar la carga de la memoria del usuario.
Flexibilidad y eficiencia de uso.
Los diálogos estéticos y diseño minimalista.
Ayudar a los usuarios a reconocer, diagnosticar y recuperarse de los errores.
Ayuda y documentación.

Según el propio Jakob Nielsen dispone de 2397 directrices de usabilidad repartidas en múltiples informes que lista en "Publications" de nngroup.com

Swedish National Guidelines for Public Sector Websites

La guía del Gobierno de Suecia Swedish National Guidelines for Public Sector Websites es especialmente completa. Las directrices están agrupadas por capítulos, dentro de los cuales se listan los heurísticos y las directrices asociadas.

Aunque no incluye checklists asociadas, las directrices están muy bien explicadas y tienen asociadas un nivel de prioridad (1, 2 y 3, siendo las de nivel 1 las más críticas)

En el capítulo "3. Website standards" se incluyen 58 directrices agrupadas en:

Estructura y navegación (9 directrices)
Color, contraste y tipografía (3 directrices)
Diseño (22 directrices)
Tablas de datos (5 directrices)
Formularios (11 directrices)
Aplicaciones web (3 directrices)
Manejo de errores (3 directrices)
Eventos del sistema (2 directrices)

En el capítulo Contenidos y servicios se incluyen 29 directrices agrupadas en:

Acerca de la autoridad (5 directrices)
Información básica (8 directrices)
Otros lenguajes (3 directrices)
Búsqueda (4 directrices)
Distribución de servicios y contenidos del sitio web (4 directrices)
Participación y transparencia (5 directrices)

En el capítulo Actualización del sitio web (o mantener el sitio al día) se incluyen 43 directrices agrupadas en:

Administración (1 directrices)
Seguimiento del uso y el contenido (6 directrices)
Información de "emergencia" en el sitio (6 directrices)
Escribir para la web (9 directrices)
Formato de la web (marcado HTML) (9 directrices)
Imágenes y gráficos (4 directrices)
Enlaces y documentos (8 directrices)

Hay otros capítulos como "Servicio mejor y más eficiente", "Proceso de desarrollo", "Contenido para dispositivos móviles", "Herramientas de publicación" o "Productos de apoyo para usar el sitio web".

Sirius

La propuesta de Mª del Carmen Suarez en su tesis Sirius: Sistema de Evaluación de la Usabilidad Web Orientado al Usuario y basado en la Determinación de Tareas Críticas (PDF, 3.39 MB) son 83 directrices dividas en:

Aspectos generales (10 directrices)
Identidad e información (7 directrices)
Estructura y navegación (14 directrices)
Rotulado (6 directrices)
Layout de la página (10 directrices)
Entendibilidad y facilidad en la interacción (7 directrices)
Control y retroalimentación (10 directrices)
Elementos multimedia (6 directrices)
Búsqueda (8 directrices)
Ayuda (5 directrices)

Hablé de su sistema en profundidad en Sirius. Nuevo sistema para la evaluación de la usabilidad web. Su método presenta numerosas ventajas, por ejemplo que la relevancia de los errores tienen en cuenta el tipo de sitio evaluado.

Permite elaborar una herramienta de evaluación que dé soporte al sistema planteado y facilite la validación empírica de la propuesta de evaluación. Proporcioné esta herramienta en formato excel: Checklist para la evaluación de la usabilidad web según la metodología Sirius. Versión 3 (XLSX)

Australia Government Usability Checklist

La Australia Government Usability Checklist es la más sencilla de todas las vistas hasta ahora. Está incluida dentro del conjunto de publicaciones "User Profiling and Testing Tollkit" del Gobierno de Australia.

Son 43 directrices clasificadas en 6 temas:

Arquitectura y navegación
Layout y diseño
Contenidos
Formularios
Plataforma e implementación
Accesibilidad (prioridad 1)

Guía para el Desarrollo de Sitios Web del Gobierno de Chile

Al igual que la del Gobierno de Australia, presenta una checklist de usabilidad bastante reducida.

Son 30 directrices divididas en los siguientes heurísticos:

Identidad corporativa
Utilidad del sitio web
Navegación
Visibilidad del estado del sistema
Consistencia y cumplimiento de estándares
Atención a errores
Estética y diseño
Ayuda a errores
Retroalimentacion (feedback)

Usability Guidelines del MIT (Massachusetts Institute of Technology)

En la web IST (Information Services & Technology) del MIT (Massachusetts Institute of Technology) encontramos el apartado "Usability at MIT" con numerosos recursos de interés.

Uno de estos recursos son las "Usability Guidelines", 62 directrices agrupadas en:

Navegación (5 directrices)
Funcionalidad (4 directrices)
Control del usuario (5 directrices)
Lenguaje y contenido (7 directrices)
Ayuda en línea y guías de usuario (2 directrices)
Feedback (7 directrices)
Accesibilidad (14 directrices)
Consistencia (2 directrices)
Prevención y correción de errores (8 directrices)
Claridad arquitectual y visual (8 directrices)

Directrices de usabilidad para sitios web del Estado colombiano

En 2010 M. Carvajal y J. Saab (2010) publicaban un documento muy interesante: “Documento de análisis de prácticas y recomendaciones mundiales en Usabilidad (PDF)” para el Ministerio de Tecnologías de la Información y las Comunicaciones de la República de Colombia. En él se repasan diferentes propuestas de diferentes países para concluir cuál sería la mejor forma de redactar unas recomendaciones de usabilidad para el Gobierno de Colombia.

Actualmente encontramos una versión 1.0.4 candidata a oficial (del 26 de agosto de 2010) en Directrices de usabilidad para sitios web del Estado colombiano (PDF, 4.1 MB).

Las directrices están organizadas así:

1. Arquitectura de información
- 1.1 Objetivos del portal web
- 1.2 Personajes y escenarios
- 1.3 Necesidades de los usuarios
- 1.4 Evaluación constante
- 1.5 Evaluación de la Arquitectura de Información
- 1.6 Navegación global consistente
- 1.7 Navegación de contexto
- 1.8 Ruta de migas
- 1.9 URL limpios
- 1.10 Ubicación del usuario
- 1.11 Tagline
- 1.12 Enlaces bien formulados
- 1.13 Memoria a corto plazo
2. Diseño de Interfaz de Usuario
- 2.1 Ubicación del logotipo
- 2.2 Diseño ordenado y limpio
- 2.3 Interfaces en movimiento
- 2.4 Contenido que parece publicidad
- 2.5 Contraste en brillo y color
- 2.6 Información transmitida a través de color
- 2.7 Justificación del texto
- 2.8 Ancho del cuerpo de texto
- 2.9 Fuentes tipográficas comunes
- 2.10 Texto subrayado
- 2.11 Uso adecuado del espacio en blanco
- 2.12 Desplazamiento horizontal
- 2.13 Vínculo a la página de inicio
- 2.14 Tareas clave en la página de inicio
- 2.15 Contenidos de ejemplo en la página de inicio
- 2.16 Hojas de estilo para diferentes formatos
- 2.17 Independencia de navegador
- 2.18 Vínculos visitados
- 2.19 Calidad del código
3. Diseño de Interacción
- 3.1 Campos obligatorios
- 3.2 Asociación de etiquetas y campos
- 3.3 Validación dinámica de datos
- 3.4 Error de página no encontrada
- 3.5 Ventanas emergentes
- 3.6 Botón atrás
- 3.7 Tiempo de carga de las páginas
- 3.8 Ejemplos en los campos de formulario
- 3.9 Páginas de confirmación

4. Búsqueda
- 4.1 Motor de búsqueda y ubicación
- 4.2 Búsquedas con términos familiares y errores de digitación
- 4.3 Sugerencias de búsqueda
- 4.4 Ubicación en los 10 primeros resultados

5. Pruebas de usabilidad
- 5.1 Evaluación heurística
- 5.2 Test de Usuario
- 5.3 Diseño y evaluación iterativos

6. Contenido
- 6.1 Contenido útil
- 6.2 Pirámide invertida
- 6.3 Títulos y encabezados
- 6.4 Listas
- 6.5 Escaneado de contenido
- 6.6 Vínculos rotos
- 6.7 Contenido encontrable

Otro documento recomendable de M. Carvajal es La Guía Web 1.0 de Proexport (PDF) donde se aplican las directrices.

Otros enlaces de interés

En Index of Government Guidelines for Web Sites de Peter Krantz se puede encontrar las guías web de los diferentes gobiernos en el mundo. Algunas de interés que no he nombrado son:

Las Kwaliteitsmodel Webrichtlijnen (The Web Guidelines quality model) son las las directrices del Gobierno de Holanda. Están centradas en la accesibilidad y el uso adecuado del estándar HTML
Las Elmer 2: User interface guidelines for governmental forms on the Internet (PDF), es una guía del Gobierno de Noruega con una checklist muy interesante pero está centrada exclusivamente en los formularios web.
Tasmanian Government Web Usability Guidelines 2009 recoge diversos documentos pero no tienen directrices asociadas como hemos podido ver en otros casos.

El artículo "Official Usability, User Experience & User Interface Guidelines From Companies" de usabilitygeek.com, repasa las diferentes guías de directrices de compañías concretas (Adobe, Apple, IBM, Microsoft, etc.) aunque la que más me gusta es la de SUN, pero la de 1995: Sun Guide to Web Style

¿Añadirías alguna más?

Artículos anteriores

Estándares formales de usabilidad y su aplicación práctica en una evaluación heurística

2012-03-15T15:01:00.167+01:00

Novedad 19/3/2012

Descarga de excel para ayudar en una evaluación de usabilidad según WUEP (Web Usability Evaluation Process), proceso explicado en el artículo y que se basa en la ISO 25000 (SQUARE).

Ver WUEP (Web Usability Evaluation Process)

26/03/2012: ampliado el contenido sobre la ISO 9241-151

Índice

Qué es un estándar
Tipos de estándares
Estándares formales de usabilidad
Aplicación práctica de los estándares formales en la evaluación heurística de una web
Qué es un estándar
“Estándar” es definido por la ISO (Organización Internacional de Estandarización) como:
documento establecido por consenso y aprobado por una institución reconocida, que prevé, para uso común y repetido, reglas, directrices y características para actividades o sus resultados, encaminada a la consecución del grado óptimo de definición en un contexto dado. Nota: las normas deben basarse en los resultados consolidados de la ciencia, la tecnología y la experiencia, y tener por finalidad promover beneficios óptimos.
[ISO/IEC Guide 2:2004, definición 3.2]
Tipos de estándares
Existen tres tipos de estándares:
- los oficiales o “de jure”. Los estándares oficiales son aquellos que han sido aprobados y sancionados por un organismo oficial de estandarización.
  Como organismos oficiales de estandarización podemos destacar:
  - En España, el organismo nacional de normalización es AENOR (Asociación Española de Normalización y Certificación) que elabora normas técnicas españolas (UNE)
  - A nivel europeo está el Comité Europeo de Normalización (CEN)
  - A nivel internacional la Organización Internacional de Estandarización (ISO) compuesta por representantes de los organismos de normalización (ON's) nacionales, que produce normas internacionales industriales y comerciales. Dichas normas se conocen como normas ISO
  Los estándares oficiales son a veces de obligado cumplimiento. De hecho en España no se puede hacer referencia en la legislación a estándares que no provengan de un organismo oficial de estandarización. Por ejemplo en España es obligatorio por ley que determinados tipos de sitios web cumplan con la Norma UNE 139803 que asegure su accesibilidad.
- los “de facto”. Son aquellos que son promulgados por comités guiados por una entidad, organismo o compañía, se usan por voluntad propia o conveniencia y tienen una amplia aceptación, aunque no hayan sido sancionados por un organismo de estandarización.
  El caso más claro es el W3C (World Wide Web Consortium) que crea estándares ampliamente aceptados y que a veces pasan a ser reconocidos como estándares oficiales (por ejemplo la Norma UNE 139803 se basa en las WCAG del W3C; y hay muchos países que en su legislación establecen que los sitios web cumplan con las WCAG)
- Estándares propietarios de una corporación o entidad.
En el caso de la accesibilidad web son muy conocidos los estándares existentes, posiblemente porque son de obligado cumplimiento en muchos países.
Sin embargo los estándares de usabilidad no son tan conocidos. En el siguiente apartado se explica de manera sencilla y comprensible cuáles son los estándares oficiales de usabilidad. En el último apartado se abordará cómo se pueden aplicar en la práctica dichos estándares para realizar evaluaciones heurísticas de usabilidad.
Estándares formales de usabilidad
Orientados al proceso: ISO 9241 e ISO 13407

ISO 9241 Ergonomics of Human System Interaction
Está compuesta por 17 partes. La 1 y 2 es una introducción y guías para el empleo del estándar. De la 3 a la 9 tratan los requisitos y guías relacionadas con el hardware que impactan en el funcionamiento del software. De la 10 a la 11 se centran en los aspectos del software.
En realidad la norma se llamaba Ergonomic requirements for office work with visual display terminals (VDTs) pero en 2006 se le simplificó el nombre; y además se renumeraron sus partes para poder cubrir más temas como la interacción táctil (ISO 9241-920:2009) , la interacción con formularios (ISO 9241-143:2012) o interfaces web (ISO 9241-151:2008)
La ISO 9241-11:1998 “Guidance on usability”, define la usabilidad como:
La medida con la que un producto se puede usar por usuarios determinados para conseguir objetivos específicos con efectividad, eficiencia y satisfacción en un contexto de uso concreto.
Por tanto, los tres factores, los tres atributos de calidad son:
- Efectividad: exactitud e integridad con la que los usuarios alcanzan los objetivos especificados, y por tanto implica la facilidad de aprendizaje, la ausencia de errores del sistema o la facilidad del mismo para ser recordado. Las métricas definidas son:
  - Número de tareas importantes realizadas
  - Porcentaje de funciones relevantes utilizadas
  - Porcentaje de tareas completadas con éxito al primer intento
  - Número de referencias a la documentación
  - Número de llamadas para soporte
  - Número de accesos a la ayuda
  - Número de funciones aprendidas
  - Porcentaje de usuarios capaces de aprender sus características
  - Porcentaje de errores corregidos o reportados por el sistema
  - Número de errores de los usuarios tolerados
  - Porcentaje de palabras leídas correctamente a una distancia de visualización normal
- Eficiencia: recursos empleados (esfuerzo, tiempo, etc.) en relación con la exactitud e integridad con la que los usuarios alcanzan los objetivos especificados. Las métricas definidas son:
  - Eficiencia relativa en comparación con un usuario experto
  - Tiempo empleado en el primer intento
  - Eficiencia relativa en el primer intento
  - Tiempo empleado en reaprender funciones
  - Número de errores persistentes
  - Tiempo productivo
  - Tiempo para aprender características
  - Tiempo para reaprender características
  - Eficiencia relativa durante el aprendizaje
  - Tiempo empleado en la corrección de errores
- Satisfacción: un factor subjetivo que implica una actitud positiva en el uso del producto. Las métricas definidas son:
  - Calificación (por parte del usuario) de su satisfacción con las características importantes
  - Tasa de uso voluntario del producto
  - Frecuencia de reutilización del producto
  - Calificación (por parte del usuario) de la facilidad de aprendizaje
  - Calificación (por parte del usuario) del tratamiento de errores
La ISO 9241‐11 recomienda un enfoque basado en procesos para evaluar la usabilidad, a través del Diseño Centrado en el Usuario (DCU). Por ello la ISO 9241 debe aplicarse en conjunto con la ISO 13407.

La ISO 9241-151:2008 “Guidance on World Wide Web user interfaces” referencia a la 9241-11 para la evaluación de criterios y a la ISO 13407 como guía de Diseño Centrado en el Usuario, puesto que señala que el diseño de interfaces web debe seguir un proceso de DCU.
Se pueden consultar comparativas de la 9241-151 con HHS Guidelines [USABILITY.GOB] en [BEVAN, 2005] y actualizado en [BEVAN, 2007]
Dentro de la ISO 9241-151 podemos destacar las siguientes directrices (viene cada una explicada y con ejemplos, y se puede encontrar una checklist para la evaluación al final del documento de la ISO):
- 6. High-level design decisions and design strategy (11 directrices evaluables)
- 7. Content design
  - 7.1 Conceptual content model (5 directrices evaluables)
  - 7.2 Content objects and functionality (19 directrices evaluables, 5 de las cuales referentes al 7.2.8 Privacy and business policies; y 7 al punto 7.2.9 Indivudualisation and user adaptation)
- 8. Navigation and search
  - 8.1 General
  - 8.2 General guidance on navigation (5 directrices evaluables)
  - 8.3 Navigation structure (11 directrices evaluables, varias de ellas relativas a Splash screens)
  - 8.4 Navigation components (16 directrices evaluables)
  - 8.5 Search (22 directrices evaluables)
- 9. Content presentation
  - 9.1 General
  - 9.2 Observing principles of human perception (1 directrices evaluables)
  - 9.3 Page design issues functions (17 directrices evaluables)
  - 9.4 Link design (15 directrices evaluables)
  - 9.5 Interaction objects (3 directrices evaluables)
  - 9.6 Text design (6 directrices evaluables)
- 10. General design aspects
  - 10.1 Designing for cultural diversity and multilingual use (5 directrices evaluables)
  - 10.2 Providing help (1 directrices evaluable)
  - 10.3 Making Web user interfaces error-tolerant(2 directrices evaluables)
  - 10.4 URL names (1 directrices evaluable)
  - 10.5 Acceptable download times (1 directrices evaluable)
  - 10.6 Using generally accepted technologies and standards(1 directrices evaluable)
  - 10.7 Supporting common technologies(1 directrices evaluable)
  - 10.8 Making Web user interfaces robust(1 directrices evaluable)
  - 10.9 Designing for input device independence(1 directrices evaluable)
  - 10.10 Making the user interface of embedded objects usable and accessible
ISO 13407:1999. Human centred design processes for interactive systems
La ISO 13407:1999 ha sido revisada por la ISO 9241-210:2010 Ergonomics of human-system interaction – Part 210: Human-centred design for interactive systems.
La ISO 13407 proporciona una guía para alcanzar la calidad en el uso mediante la incorporación de actividades de naturaleza iterativa involucradas en el Diseño Centrado en el Usuario (DCU).
El Diseño Centrado en el Usuario (DCU) lo describe como una actividad multidisciplinar, que incluye factores humanos y conocimientos y técnicas de ergonomía con el objetico de mejorar la efectividad y eficiencia, las condiciones de trabajo y contrarrestar los posibles efectos adversos de su uso.
Describe los cuatro principios del Diseño Centrado en el Usuario:
- Involucrar activamente a los usuarios
- Asignación adecuada de funciones al sistema y el usuario
- Soluciones de diseño iterativas
- Diseño multidisciplinar
Y las cuatro actividades del Diseño Centrado en el Usuario:
- Entender y especificar el contexto de uso
- Especificar los requisitos del usuario y de la organización
- Producir más de una solución de diseño candidata
- Contrastar los diseños con los requisitos
Figura 1. Imagen tomada de [MONTERO, 2008, pág.6]
Como he dicho, la ISO 13407 ha sido revisada por la ISO 9241-210:2010 Ergonomics of human-system interaction – Part 210: Human-centred design for interactive systems que describe seis principios clave que caracterizan al Diseño Centrado en el Usuario [TRAVIS, 2011]:
- El diseño está basado en una comprensión explícita de usuarios, tareas y entornos.
- Los usuarios están involucrados durante el diseño y el desarrollo.
- El diseño está dirigido y refinado por evaluaciones centradas en usuarios.
- El proceso es iterativo.
- El diseño está dirigido a toda la experiencia del usuario.
- El equipo de diseño incluye habilidades y perspectivas multidisciplinares
Orientados al producto: ISO 9126 e ISO 14598
ISO 9126 Software engineering — Product quality
Es un estándar para evaluar la calidad del software. Esta dividida en cuatro partes:
- ISO/IEC 9126‐1: 2001 : presenta el modelo de calidad que clasifica la calidad del software en un conjunto estructurado de características: funcionalidad, fiabilidad, usabilidad, eficiencia, mantenibilidad y portabilidad.
  Define la usabilidad como la capacidad que tiene un producto software para ser entendido, aprendido, operable, atractivo para el usuario y conforme a estándares/guías, cuando es utilizado bajo unas condiciones específicas.
  Por ello la usabilidad se divide en las siguientes subcaracterísticas:
  - Fácil de aprender: capacidad para ser aprendido en su manejo
  - Fácil de entender: capacidad del producto de ser entendido por nuevos usuarios en términos de su propósito y cómo puede ser usado en tareas específicas.
  - Fácil de operar: capacidad del producto de ser operado y controlado en cualquier momento.
  - Atractivo: capacidad del producto de ser atractivo para sus usuarios.
  - Conformidad: capacidad del producto para adherirse a estándares, convenciones, guías de estilo o regulaciones relacionadas con la usabilidad.
  Figura 2. Modelo de calidad ISO/IEC 9126-1
- ISO/IEC 9126‐2:2003 : describe las métricas externas que se pueden utilizar para evaluar el comportamiento del software cuando es operado por el usuario.
- ISO/IEC 9126‐3:2003 : describe las métricas internas que se pueden utilizar para describir propiedades estáticas de la interfaz, que puede ser evaluadas por la inspección sin poner en funcionamiento el software.
- ISO/IEC 9126‐4:2004 : describe las métricas de calidad que se pueden utilizar para evaluar el efecto del producto software cuando son operados por el usuario en determinados contextos de uso. Las métricas definidas son:
  - Efectividad (el método de aplicación definido para las tres es el test con usuarios)
    - Efectividad de las tareas: ¿qué proporción de objetivos de las tareas son logrados correctamente?
    - Tareas completadas, ¿qué proporción de tareas son completadas?
    - Frecuencia de los errores
  - Productividad (el método de aplicación definido para todas es el test con usuarios)
    - Tiempo de las tareas, ¿cuánto tiempo lleva completar una tarea?
    - Efectividad de las tareas, ¿cuán eficientes son los usuarios?
    - Productividad económica, ¿cómo de rentable es el usuario?
    - Porcentaje de producción, ¿qué proporción de tiempo dedica el usuario a acciones productivas?
    - Eficiencia relativa de los usuarios, ¿cómo de eficiente es el usuario comparado con un experto?
  - Seguridad (el método de aplicación definido para todos es el uso de estadísticas)
    - Salud y seguridad del usuario, ¿cuál es la frecuencia de problemas de salud entre usuarios del producto?
    - Seguridad de las personas afectadas por el uso del sistema, ¿cuál es la frecuencia de peligro para las personas afectadas por el uso del sistema?
    - Daños ergonómicos, ¿cuál es la frecuencia de daños ergonómicos?
    - Daños del software, ¿cuál es la frecuencia de la corrupción del software?
  - Satisfacción
    - Escala de satisfacción, ¿cómo de satisfecho está el usuario?
    - Cuestionario de satisfacción, ¿cómo de satisfecho esta el usuario con características específicas del software?
    - Uso discrecional, ¿qué proporción de potenciales usuarios eligen el uso del sistema? El método de aplicación definido es la observación del uso.
Puesto que la ISO 9126 se limita a la especificación de un modelo de calidad general, esta se debe aplicar en conjunto con la ISO 14598.
ISO 14598 Information technology — Software product evaluation
La ISO 14598 es un estándar que proporciona un marco de trabajo para evaluar la calidad de todo tipo de producto software e indica los requisitos para los métodos de medición y el proceso de evaluación. Consta de seis partes:
- ISO/IEC 14598‐1: 1999 : provee una visión general de las otras cinco partes y explica la relación entre la evaluación del producto software y el modelo de calidad definido en la ISO/IEC 9126
  Figura 3. Imagen de [Férnandez-Martinez, 2009]
- ISO/IEC 14598‐2: 2000 : contiene requisitos y guías para las funciones de soporte tales como la planificación y gestión de la evaluación del producto del software.
- ISO/IEC 14598‐3: 2000 : provee los requisitos y guías para la evaluación del producto software cuando la evaluación es llevada a cabo en paralelo con el desarrollo por parte del desarrollador.
- ISO/IEC 14598‐4:1999 : provee los requisitos y guías para que la evaluación del producto software sea llevada a cabo en función a los compradores que planean adquirir o reutilizar un producto de software existente o predesarrollado.
- ISO/IEC 14598‐5: 1998 : provee los requisitos y guías para la evaluación del producto software cuando la evaluación es llevada a cabo por evaluadores independientes.
- ISO/IEC 14598‐6:2001 : provee las guías para la documentación del módulo de evaluación.
Ventajas y desventajas de la definición de usabilidad como proceso y como producto
[Férnandez-Martinez, 2009] explica las ventajas y desventajas de la definición de la usabilidad como proceso o como producto vistas en el conjunto de normas anteriores:
Ventajas de la definición usabilidad como proceso:
- Se identifican aspectos de usabilidad y componentes del contexto de uso que deben tenerse en cuenta en las fases de especificación de requisitos, diseño y evaluación de usabilidad.
- El rendimiento y la satisfacción del usuario proporcionan medidas directas de usabilidad en un contexto específico.
- Las medidas obtenidas proporcionan una base para comparar la usabilidad de varios diseños en un mismo contexto.
Desventajas de la definición usabilidad como proceso:
- La usabilidad está estrictamente tratada desde una perspectiva de proceso, no centrada en el producto.
- No tiene en cuenta la característica de “facilidad de aprendizaje”, siendo esta recomendada por otros estándares y expertos en usabilidad.
- No tiene en cuenta aspectos de seguridad, considerados importantes por expertos del dominio.
Las ventajas de la definición de usabilidad como producto:
- Existe un marco claramente definido y acordado en el modelo, que aclara la
- Definición de usabilidad, y propone métricas para proporcionar evidencia objetiva de los logros.
- Se puede utilizar como una referencia para los acuerdos contractuales entre un comprador y un proveedor de software, pudiendo ser utilizados además, para eliminar una serie de malentendidos entre el comprador y el proveedor.
- Se propone un proceso de evaluación que puede ser adaptado a compradores, desarrolladores y evaluadores externos.
Desventajas de la definición de usabilidad como producto:
- El conjunto de métricas se proporciona para sub‐características que a su vez engloban conceptos difícilmente medibles si no se descomponen en atributos
- Existe superposición de conceptos, al definir usabilidad como una característica de calidad interna‐externa, y llamar calidad en uso a otras características también vinculadas a la usabilidad.
- El tener por separado dos normas que se aplican conjuntamente produce inconsistencias en los ciclos de vida de ambas dificultando su uso.
ISO 25000 (SQUARE): unificación y revisión de los estándares ISO/IEC 9126 e ISO/IEC 14598
La ISO 25000:2005 se conoce como SQUARE (Software Quality Requirement Evaluation) y básicamente se trata de una unificación y revisión de los estándares ISO/IEC 9126 e ISO/IEC 14598.
Su objetivo principal es guiar el desarrollo de los productos de software con la especificación y evaluación de requisitos de calidad.
Figura 4. Imagen de [ISO25000.com]
La norma está formada por las siguientes divisiones [ISO25000.com, b]:
- División de gestión de calidad (ISO/IEC 2500n): los estándares que forman esta división definen todos los modelos comunes, términos y referencias a los que se alude en las demás divisiones de SQuaRE.
- División del modelo de calidad (ISO/IEC 25001n): el estándar que conforma esta división presenta un modelo de calidad detallado, incluyendo características para la calidad interna, externa y en uso.
- División de mediciones de calidad (ISO/IEC 25002n): los estándares pertenecientes a esta división incluyen un modelo de referencia de calidad del producto software, definiciones matemáticas de las métricas de calidad y una guía práctica para su aplicación. Presenta aplicaciones de métricas para la calidad de software interna, externa y en uso.
- División de requisitos de calidad (ISO/IEC 25003n): los estándares que forman parte de esta división ayudan a especificar los requisitos de calidad. Estos requisitos pueden ser usados en el proceso de especificación de requisitos de calidad para un producto software que va a ser desarrollado ó como entrada para un proceso de evaluación.
- División de evaluación de la calidad (ISO/IEC 25004n): estos estándares proporcionan requisitos, recomendaciones y guías para la evaluación de un producto software, tanto si la llevan a cabo evaluadores, como clientes o desarrolladores.
En el modelo de calidad hay tres vistas del modelo según el contexto: modelo de calidad de software, modelo de calidad de datos y modelo de calidad en uso, que puede tener distintas vistas según la parte beneficiaria que consideremos (usuario final, organización y soporte técnico)
Considerando la vista del usuario final tendríamos una definición de usabilidad más cercana a la planteada en la ISO 9241‐11.
Figura 5. Imagen [Férnandez-Martinez, 2009]
En el modelo de calidad de software la usabilidad se mantiene como una característica más del producto, pero que se llama operabilidad, y tiene alguna diferencia respecto a la ISO 9126, siendo sus subcaracterísticas:
- Fácil de aprender: capacidad para ser aprendido en su manejo
- Fácil de entender: capacidad del producto de ser entendida por nuevos usuarios en términos de su propósito y cómo puede ser usado en tareas específicas.
- Fácil de usar: capacidad del producto de ser operado y controlado en cualquier momento.
- Atractivo: capacidad del producto de ser atractivo para sus usuarios.
- Conformidad: capacidad del producto para adherirse a estándares, convenciones, guías de estilo o regulaciones relacionadas con la usabilidad.
- Facilidad de ayuda: hace referencia al grado con el que el producto ofrece ayuda a los usuarios cuando la necesitan, algo que en la ISO 9126 se consideraba implícita en la facilidad de aprender.
- Accesibilidad técnica: hace referencia a cómo el producto software puede ser usado por personas con discapacidad.
Tanto [Férnandez-Martinez, 2009, pp. 48 y ss] como [RUIZ MORILLA, 2009] comparan y enumeran las ventajas y desventajas de la ISO 25000 frente a sus predecesoras ISO/IEC 9126 y ISO/IEC 14598.
Aplicación práctica de los estándares formales en la evaluación heurística de la web
Hemos visto que la ISO 9126 es un estándar oficial de usabilidad orientado al producto que ha sido revisado en la ISO 25000.
Por otra parte, hemos visto que en estas normas se definen una serie de características y subcaracterísticas de la usabilidad.
¿Cómo podemos aplicarlo de forma práctica en la evaluación heurística de una web?
Una buena respuesta es mediante WUEP (Web Usability Evaluation Process), la tesina de Adrián Fernández Martínez [FERNANDEZ-MARTINEZ, 2009]
WUEP (Web Usability Evaluation Process)
La WUEP define un proceso genérico de usabilidad para metodologías de desarrollo Web basadas en modelos. Presenta una guía detallada para realizar evaluaciones de usabilidad integrando todos los atributos de usabilidad posibles desde la perspectiva del concepto de usabilidad que ofrece la ISO 25000 (SQUARE)
El modelo de usabilidad web tiene en cuenta la división en subcaracterísticas y el modelo de calidad propuesto por SQuaRE. Como están subcaracterísticas son muy genéricas y están a un alto nivel de abstracción, descompone dichas subcaracterísticas en atributos cercanos al dominio Web, intentando que las definiciones de las atributos se solapen lo mínimo posible entre ellas, con el objetivo de obtener un modelo de usabilidad lo más amplio posible centrado en el ámbito de las aplicaciones Web.
En esa extensión del modelo hacia productos Web se tienen en cuenta los criterios ergonómicos de [BASTIEN y SCAPIN, 1993], las pautas de usabilidad del Gobierno de EEUU [USABILITY.GOB] (conocidas como las HHS Guidelines), y otras métricas generalmente aceptadas con el objetivo de proveer un conjunto de métricas genéricas que puedan ser operacionalizadas en distintos niveles de abstracción y en distintos métodos de desarrollo Web.
Cada métrica tiene asociada un único atributo, pudiendo pertenecer este a cualquier vista del modelo, con el objetivo de descubrir problemas de usabilidad en base a los valores obtenidos de la métrica, pudiendo además cuantificar cómo dicho atributo afecta al nivel de usabilidad de la aplicación Web.
En este modelo hay dos tipos de evaluaciones uno sería el equivalente a una evaluación heurística, que a su vez puede ser de tres tipos: PIM o independiente de la plataforma, PSM o específico de una plataforma y CM o informe de usabilidad de la aplicación final; el segundo tipo de evaluación sería el de la evaluación de calidad en uso con test de usuarios.
Por otra parte, señalar que WUEP extiende y adapta el método de evaluación de calidad de la ISO 25004n para su integración en evaluaciones de usabilidad:
Otras propuestas
Mplu+a
En el año 2004, Toni Granollers i Saltiveri [GRANOLLERS, 2004], profesor de la Universidad de Lleida, presentaba su tesis doctoral: "MPIu+a. Una metodología que integra la Ingeniería del Software, la Interacción Persona-Ordenador y la Accesibilidad en el contexto de equipos de desarrollo multidisplinares", una metodología que emplea los estándares ISO/IEC 9126 e ISO/IEC 9241, así como las guías de accesibilidad propuestas por el World Wide Web Consortium (W3C). La trate con detenimiento en [CARRERAS, 2008]
WebQEM
[OLSINA y ROSSI, 2002] especifican características y atributos basados en la norma ISO/IEC 9126-1, aplicando métricas para cuantificar los atributos.
WQM (Web Quality Model)
[CALERO et al.] establece características de calidad basadas en la ISO/IEC 9126-1 y los procesos del ciclo de vida de un sitio Web basándose en la ISO/IEC 12207. Incorpora un total de 326 métricas Web que han sido validadas teórica y/o empíricamente, indicando cuáles de ellas se prestan mejor a automatizar su cálculo. Ver la clasificación de sus métricas
QUIM (Quality in Use Integrated Measurement)
[Seffah et al.] se basa en la ISO 9241-11 y establece 10 subcaracterísticas que se descomponen en 26 atributos o criterios medibles. En el tercer nivel encontramos 127 métricas de usabilidad asociadas a los atributos. Posee una herramienta de gestión llamada QUIM Editor [STRIKE, 2003]
Referencias
AENOR (Asociación Española de Normalización y Certificación)
BASTIEN, J. M.; SCAPIN, D. L. (1993): “Ergonomic Criteria for the Evaluation of Human-Computer Interfaces”, version 2.1
BEVAN, N. (2005): "Guidelines and Standards for Web Usability"
- (2006): “International Standards for HCI” , mayo 2006
- BEVAN, N. , SPINHOF, L. (2007): “Are guidelines and standards for web usability comprehensive?”
- Nivel Began Published Papers: http://www.nigelbevan.com/cart.htm
CALERO, C.; RUIZ, J.; PIATTINI, M. (2005): “Classifying Web metrics using the Web Quality Model”. Emerald Group Publishing Limited. ISSN: 1468‐4527. Vol.29, nº 3, pp. 227‐248,
CARRERAS MONTOTO, O. (2008), “Metodología DCU MPlu+a”, marzo 2008
Comité Europeo de Normalización (CEN)
FERNANDEZ MARTINEZ, A. (2009): “WUEP: Un Proceso de Evaluación de Usabilidad Web Integrado en el Desarrollo de Software Dirigido por Modelos”
GRANOLLERS, T. (2004): “MPIu+a. Una metodología que integra la Ingeniería del Software, la Interacción Persona‐Ordenador y la Accesibiiad en el contexto de equipos de desarrollo multidisciplinares”. Tesis Doctoral, Departament de Llenguatges i Sistemas Informàtics. Universitat de Lleida
ISO25000.com: “Calidad del Producto Software y la norma ISO/IEC 25000”,
- [ISO25000.com, b]: “La Norma ISO/IEC 25000:2005”,
MONTERO SIMARRO, F. (2008): “Tema 2. El diseño centrado en el usuario”
OLSINA, L.; ROSSI, G. (2002): “Measuring Web Application Quality with WebQEM”. IEEE Multimedia, Vol. 9, nº 4, pp. 20‐29.
Organización Internacional de Estandarización (ISO)
RUIZ MORILLA, J.J. (2009): “ISO 9126 vs. SQuaRE”
SCALONE, F. (2006): “Estudio comparativo de los modelos y estándares de calidad del software”, junio de 2006
TRAVIS, D. (2011): “ISO 13407 is dead. Long live ISO 9241-210!”, Userfocus, 6/6/2011
SEFFAH, A.; Donyaee, M.; Kline, R.B.; Padda, H.K. (2006): Usability measurement and metrics: A consolidated model . Software Quality Journal 14(2), pp. 159-178.
STRIKE, J. (2003): “QUIM Editor: a Tool for Quality in Use Measurement”
USABILITY.GOB: “Research-Based Web Design & Usability Guidelines”
USABILITYNET (2006): “International standards for HCI and usability”
Normas ISO referenciadas:

Arquitectura de información. Fundamentos

2011-07-14T11:30:00.007+02:00

Arquitectura de información, usabilidad, accesibilidad… todas ellas son disciplinas diferentes aunque íntimamente relacionadas, englobadas en una macrodiscisciplima denominada Experiencia de usuario (UX) que aglutina la arquitectura de información y la mayoría de las disciplinas cercanas a ella [1].

El objetivo de este artículo es introducir los fundamentos de la arquitectura de información (AI), es decir, los principios y cimientos de la disciplina. Para estructurar el contenido he tomado como guión uno de los mejores libros que existen sobre el tema “Arquitectura de información en entornos web” de Mario Pérez-Montoro Gutiérrez (Pérez-Montoro, 2010).

Para los que ya lo han leído, este artículo puede servir de esquema resumen. A los demás os animo a leerlo, pues en él se desarrollan en profundidad todos los apartados con gran rigor y muy bien documentados.

¿Qué es la arquitectura de información?

Disciplina (arte y ciencia) encargada de estructurar, organizar y etiquetar los elementos que conforman los entornos informacionales para facilitar de esta manera la localización (o el acceso) de la información contenida en ellos y mejorar, así, su utilidad y su aprovechamiento por parte de los usuarios (Pérez-Montoro 2010).

El arquitecto de información es la persona que debe identificar la misión (los objetivos) y la visión (las expectativas de los usuarios) de la pagina web, determinar los contenidos y funcionalidades de la página, facilitar el acceso mediante sistemas de organización, etiquetado, navegación y búsqueda y planificar en previsión de futuras modificaciones y crecimiento de la página (Morville y Rosenfeld, 1998)

Durante la fase de “estrategia” identifica los objetivos, en la fase de “alcance” las necesidades de los usuarios, en la fase de “estructura” especifica las funcionalidades y requerimientos de la web, en la fase de “esqueleto” el diseño de los sistemas de navegación, organización, etiquetado y búsqueda y en la fase de “interfaz” prototipa la página (Garret, 2003)

Tipos de necesidad de información

El objetivo habitual de un usuario al acceder a una web es satisfacer una necesidad de información y/o realizar una transacción (por ejemplo comprar un billete de tren). Desde el punto de vista de las necesidades informativas, se pueden distinguir tres tipos:

Necesidad de información concreta (NIC): por ejemplo, “¿qué precio tiene este producto?”
Necesidad de información orientada a problemas (NIOP), por ejemplo, “¿cuál es la relación entre la usabilidad y la arquitectura de información?”
Necesidad de información exploratoria (NIE), por ejemplo “quiero escoger un buen hotel para este fin de semana”
Necesidad de información sobre búsquedas previas (NIBP), es decir, localizar información que ya había localizado previamente.

Las estrategias de las que dispone un usuario para satisfacer estas necesidades de información en una página web son:

Búsqueda, utiliza la caja de búsqueda y analiza e interacciona con los resultados.
Navegación, explora a partir de los enlaces de la web.
Ayuda, por comodidad o desesperación reclama que se le oriente y señale dónde se encuentra el contenido.

El usuario utiliza una de estas estrategias - o una combinación de ellas- para localizar información que asimila y evalúa para así reformular o refinar su necesidad de información, hasta que considera que ha quedado resuelta. Es lo que se conoce como el modelo berrypicking o recolección de bayas (Bates, 1989). Ver también modelo pearl-growing

Componentes o anatomía de la arquitectura de información

Una buena arquitectura de información se sustenta en tres pilares: el contexto organizacional en el que se desarrolla, el contenido que alberga y los usuarios que la visitan y consultan (Morville y Rosenfeld, 2006)

Los sistemas, estructuras o recursos para estructurar una web y que definen la AI de un sitio se llaman componentes o anatomía de la arquitectura de información y son los siguientes:

Sistemas de organización
Sistemas de etiquetado
Sistemas de navegación
Sistemas de búsqueda
Vocabularios o lenguajes documentales

Todos ellos son los responsables en gran de media de la findability de la página y los contenidos que alberga.

Sistemas de organización

Dependiendo de cómo organicemos la información contenida en una web lograremos que los contenidos que alberga sean más fáciles de encontrar por los usuarios. Para hacer un diseño adecuado del sistema de organización es necesario desarrollar correctamente los componentes que lo conforma:

Esquemas de organización: sistemas que organizan los grupos de ítems de información contenidos en una página web en grupos a partir de un criterio concreto:
- Exactos: grupos bien definidos y mutuamente excluyentes, sirven para conocer cosas previamente conocidas:
  - Alfabéticos
  - Cronológicos
  - Geográficos
- Ambiguos, para localizar contenidos que no conocemos:
  - Tema
  - Tarea
  - Audiencia
  - Metáfora, de la que no hay que abusar, pues si no está bien desarrollada su alta ambigüedad desorienta al usuario.
  - Híbrido, utilización de varios de los esquemas anteriores.
Estructuras de organización: sistemas que organizan los grupos de ítems de información resultantes de los esquemas mostrando las dependencias lógicas que existen entre ellos:
- Estructura jerárquica, una buena arquitectura de información incluye una jerarquía o taxonomía entre sus componentes. Permiten al usuario ubicarse y obtener un modelo mental de la estructura del sitio que visita:
  Consejos:
  - Diseñarla teniendo en cuenta a los usuarios.
  - Las opciones principales deben estar siempre visibles.
  - Combinarla con los otros tipos de estructuras para ofrecer al usuario flexibilidad a la hora de localizar la información.
  - Las categorías que la conforman deben ser mutuamente excluyentes. Si muchos contenidos pertenecen a varias categorías la taxonomía termina perdiendo su valor para localizar la información.
  - Sobre la anchura (nº de ítems al mismo nivel) y profundidad de la estructura (niveles de división verticales) recomendada se han escrito ríos de tinta [2]
  - Definir la estructura pensando en la escalabilidad del portal, que sea posible incluir nuevas categorías sin modificarla sustancialmente, sin provocar cambios en la imagen mental que tiene el usuario que ya la ha visitado y sin tener que introducir modificaciones visuales en la home.
- Basada en registros (o en el modelo de base de datos), idóneo para los contenidos bien estructurados y homogéneos
- Estructura hipertextual (o en red), que debe ser complemento de otros tipos de estructuras y no la única opción de organización de la información. Permite reflejar relaciones menos estructuradas y más creativas existentes entre los contenidos.
- Estructura secuencial, con un principio y un final claro y un único itinerario de consulta o exploración
- Estructura en tabla (o matriz), sólo para aquellos contenidos que admitan su representación en una tabla, y debe ser utilizado en combinación con otras estructuras.

Algunos problemas que debemos resolver al diseñar el sistema de organización son:

La ambigüedad del propio lenguaje lingüístico.
La heterogeneidad de los contenidos.
Las diferentes perspectivas, siendo imprescindible tener en cuenta a nuestro público objetivo.
Los intereses de la organización, que es necesario conocer a fondo.

El mejor consejo es que, dependiendo del contexto y los usuarios, elegir y articular aquellos sistemas que sean realmente útiles, intentando simultanear esquemas exactos y ambiguos para ofrecer al usuario diferentes vías para acceder y localizar la información. La combinación de diferentes estructuras, si se combinan adecuadamente, permiten obtener un sistema sólido, coherente y flexible.

Sistemas de etiquetado

A la hora de definir el sistema de etiquetado debemos tener cuidado con:

La ambigüedad intrínseca al lenguaje, tanto sintáctica, léxicas (sinonimia y polisemia) como semántica (uso de metáforas, ironía, etc.)
La arbitrariedad, evitando utilizar términos con un significado diferente con el que normalmente se asocian.
La desorientación que producen las etiquetas que no anticipan ni dan pista sobre lo que esconden.
Las etiquetas que utilizamos se asociación al branding de la empresa, y unas etiquetas mal elegidas pueden dar una mala impresión de la misma.

Todo ello puede suponer que el usuario abandone la página porque no encuentra lo que necesita.

Las etiquetas pueden ser textuales o icónicas, estas deben utilizarse siempre junto a las primeras porque son intrínsecamente ambiguas.

Los sistemas de etiquetado con formato textual que deben planificarse son:

Enlaces contextuales. Deben identificarse visualmente como tales, diferenciar los que sean externos y utilizarse de forma consistente. No deben ser ambiguos y se debe tener en cuenta el contexto en el que se insertan, siendo además independientes del mismo.
Títulos. Deben estructurar coherentemente el contenido y su diseño debe reflejar su jerarquía. Tienen que ser descriptivos y coherentes con los literales utilizados en los otros sistemas de etiquetado. Deben ser consistentes a lo largo del sitio tanto en su ubicación como en su aspecto.
Opciones del sistema de navegación. Deben ser consistentes y coherente siguiendo un mismo patrón visual y de ubicación a lo largo de todo el sitio. Deben describir adecuadamente los contenidos que incluyen y ser entre ellos lo más excluyentes posibles.
Términos de indización. Son el conjunto de etiquetas utilizadas para describir cualquier tipo de contenido en un entorno web y facilitar su localización, búsqueda y recuperación. Su enlace permite acceder al listado de todos los contenidos indizados con ese término y además alimentan el índice inverso del sistema de búsqueda. Cuando los propios usuarios o los autores de los contenidos proponen las etiquetas (tag) hablamos de marcadores sociales. Una folksonomía es el resultado de la agregación de las etiquetas o tags propuestos por uno más usuarios. Se pueden visualizar en forma de listado, nubes de etiquetas, los más populares, etc.

Consejos y recomendaciones

Acotar el significado de las etiquetas teniendo en cuenta a los usuarios.
Diseñar el sistema de etiquetado de forma global y no etiquetas de forma aislada.
Mantener la consistencia tanto en el literal como en el formato.
Usar el mismo registro: si usas “linfoma” no uses “dolor de cabeza” sino “cefalea”.
Reconocibles por ser conceptos familiares, el usuario no debe tener que aprender su significado.
Utilizar estrategias para desambiguar las etiquetas, por ejemplo mediante el contexto (acompañada de otros elementos similares; mediante un texto que la acompañe, etc.)

Orientaciones metodológicas

Crear una tabla con tres columnas: etiqueta, explicación de la etiqueta y contenido que representa, para detectar inconsistencias y duplicidades.
Involucrar a los autores de contenidos.
Involucrar a los usuarios con pruebas de cardsorting.
Ver cómo etiquetan nuestros contenidos los usuarios por ejemplo en Del.icio.us
Analizar los términos que utilizan los usuarios en el buscador de nuestra web.
Aprovechar tesauros y vocabularios controlados ya existentes que podamos adaptar y refinar, pero siempre deben coincidir con nuestra audiencia.

Sistemas de navegación

Son estructuras que ordenan y agrupan los contenidos de una página web bajo unas categorías que forman una clasificación. Nos permiten:

Identificar las relaciones entre los contenidos de la web y entre esos contenidos y la página que se está visitando en ese momento.
Habilitar y facilitar la navegación entre esos contenidos
Orientarnos, saber dónde estamos, que hay aquí, de dónde venimos y cómo podemos ir hacia donde deseamos ir.
Formar una imagen mental del tamaño y estructura del sitio.

Los usuarios pueden navegar de formas muy distintas: con dirección, cuando buscan una información determinada, sin dirección, cuando ojean la web sin un objetivo claramente preestablecido, además puede navegar en amplitud o en profundidad.

Tipos de sistemas de navegación

Sistemas básicos
- Sistemas integrados
  - Sistemas constantes (o globales)
  - Sistemas locales, deben estar correctamente articulados con el sistema constante.
  - Sistemas contextuales, que permiten identificar contenidos relacionados y enlazar con ellos. Es importante que los contenidos o páginas críticas se enlaces desde otros contenidos.
  Se deben articular estos tres sistemas sin saturar de enlaces y sin que ocupen todo el espacio de la página. Deben situarse de forma consistente, fija y diferenciada entre ellos.
- Sistemas complementarios, son recursos para localizar información y para orientarse que suelen ser páginas propias e independientes.
  - Mapa del sitio
  - Índices, listado de términos que representan el contenido del sitio, normalmente ordenados alfabéticamente
  - Guías, para introducir a los nuevos usuarios en los contenidos y la funcionalidad de una parte concreta del sitio: wizards, configuradores, visitas guiadas, tutoriales, etc.
Sistemas no básicos
- Sistemas de personalización, estructuras de navegación proactivas que se autodiseñan en función de lo que espera el usuario, ofreciéndole enlaces a partir de su perfil. El principal problema es que los comportamientos pasados no son garantía de inferir sus comportamientos futuros.
- Sistemas de customización: estructuras reactivas que permiten que el usuario pueda diseñar su propio sistema de navegación. El principal problema es que a los usuarios les pasen desapercibidas estas opciones, que si sus necesidades cambian deben redefinirlas o que simplemente no tengan tiempo de hacerlo.
- Sistemas de navegación visual, permiten explorar usando recursos icónicos o visuales.
- Sistemas de navegación social, inferidos a partir del comportamiento de la mayoría de usuarios que visitan la página (lo más popular, lo más comprado, etc.)

Recomendaciones

Utilizar recursos de contextualización que permitan al usuario saber dónde se encuentra, adónde puede ir y la relación del contenido con el resto del sitio: incluir siempre el logo de la organización, marcar visualmente las opciones de menú donde nos encontramos, incluir migas de pan, etc.
No anular funcionalidades del navegador. Al posicionar el cursor sobre un enlace la URL debe verse en el pie del navegador; no eliminar las barra de menú del navegador al abrir una ventana nueva; no impedir al usuario que utilice el menú contextual del botón derecho; no impedir que la página muestre el scoll cuando sea necesario; permitir que los enlaces visitados cambien de color, etc.
Diseño de navegación: incluir siempre un mapa web. Si se usan menús desplegables es mejor que se desplieguen al activarlos y se mantengan desplegados (Chaparro, Minnaert y Phipps, 2000).

Sistemas de búsqueda

Utilizados normalmente para localizar información a partir de una necesidad concreta. Ofrecen los resultados que coinciden con los definidos por el usuario en la ecuación de búsqueda. Los problemas a superar son:

Ruido: contenidos recuperados no pertinentes, se mide con el índice de precisión.
Silencio: documentos pertinentes no recuperados, se mide con el índice de exhaustividad.

Los sistemas de búsqueda pueden ser:

Reactivos: reaccionan frente a la conducta informativa del usuario.
Proactivos: ofrecen proactivamente la información al usuario sin que tenga que reclamarla continuamente:
- Sistemas de difusión selectiva de información (DSI), ofrecen una actualización informativa automatizada sobre un tema concreto a partir de la sindicalización de contenidos.
- Sistemas de workshop, suministran automáticamente la información dentro de un proceso a partir del perfil del usuario.
- Agentes inteligentes: infieren el perfil de interés informacional de un usuario a partir de criterios como su histórico de comportamiento o su similitud con el de otros usuarios.
RSS, es reactivo porque has de suscribirte y proactivo porque desde ese momento los recibes automáticamente.

Recomendaciones

Evaluar la necesidad de un vocabulario controlado y definir los metadatos implicados en su descripción.
Seleccionar como términos de indización ciertos componentes de los contenidos (título, url, etiquetas de los enlaces o títulos de las imágenes)
Si se indiza el texto completo de todos los contenidos, introducir recursos como la búsqueda por campos para refinar el resultado y evitar una tasa de ruido elevada.
Evaluar si se indiza sólo algunos contenidos, algunas zonas de esos contenidos o algunos componentes determinados de ellos.
Indizar los contenidos según el tipo de usuario o audiencia al que va dirigido.
Inferir patrones en el comportamiento de los usuarios.
Tratar de indizar las páginas según el tipo de contenido.
Incluir siempre que se pueda:
- corrector ortográfico: corrigen automáticamente la ortografía dando alternativas.
- herramientas fonéticas: para identificar términos con grafías diferentes pero fonéticamente idénticas
- herramientas de procesamiento del lenguaje natural: obvian las palabras vacías e introducen AND entre los términos propuestos.
- en función del proyecto, evaluar la inclusión de sugerencias de términos en la caja de búsqueda, que se va adaptando a lo que se escribe y que permiten identificar las búsquedas con más resultados.
Poder refinar y mejorar manualmente los resultados de las búsquedas más habituales.
Formar a los autores del contenido sobre cómo deben redactar los títulos o etiquetar el contenido.
La caja de búsqueda debe estar identificada como tal y cerca del sistema de navegación.
Diseñar la interfaz de búsqueda teniendo en cuenta a los usuarios, el tipo de necesidad informativa, la cantidad de información recuperada y el tipo de contenidos a recuperar.
En la página de resultado:
- indicar los términos por los que se ha buscado
- indicar el número de resultados mostrados y encontrados
- poner en negrita las coincidencias
- permitir refinar la búsqueda (no solo semánticamente sino por fecha, lengua, tipo de documento, etc.)
- permitir realizar búsquedas sólo en los resultados.
- permitir personalizar el número de resultados a mostrar.
- poder imprimir o enviar por email los resultados
- poder guardar la búsqueda, para ello es necesario que sea mediante GET para que tenga una URL propia.
- ofrecer opciones de ordenación (por precio, por relevancia, por cronología, etc.)

Vocabularios o lenguajes documentales

La indización es la operación en la que se asigna a cada contenido una serie de términos (palabras clave) que representan el tema o temas sobre los que versa. Es una operación de análisis. La clasificación es la operación por la cual se asigna a cada contenido un único término que representa el tema principal sobre el que versa ese documento. Es una operación de síntesis.

La información resultante de la indización y la clasificación suele incorporarse al contenido mediante metadatos asociados para que funcione con los sistemas de organización, etiquetado, navegación y búsqueda.

Un lenguaje documental se constituye a partir de un subconjunto de términos del lenguaje natural (acompañados a veces de números como en el caso de las clasificaciones) para facilitar la búsqueda y recuperación de la información contenida en los documentos.

Aunque el uso de un lenguaje documental reduce el ruido y el silencio en las búsquedas, su construcción y mantenimiento lleva asociado un coste de personal y de tiempo importante, además de que hay que asegurar que se hace correctamente. Por ello hay que evaluar con criterio la necesidad de ese esfuerzo y su viabilidad.

Un lenguaje documental está formado por:

El vocabulario del lenguaje documental: subconjunto del lenguaje natural. Se distingue:
- el término de indización principal (descriptor): es unívoco. Identifica la representación estándar de ese concepto. Por ejemplo, “sacerdote”.
- término de indización secundario: es sinónimo del principal y una buena representación del concepto que el primero también representa, pero se decide no identificarlo como la representación estándar. Por ejemplo: “cura”, “clérigo”
Relaciones semánticas entre los términos de indización, que pueden ser de:
- Equivalencia: sinónimos, acrónimos, abreviaciones, variantes léxicas, posibles errores ortográficos, cuasisinónimos.
- Jerarquía, que puede ser:
  - Genérica: soltero-hombre
  - Relación parte-todo: rueda-coche
  - Relaciones de instanciación: Mediterráneo-mar
- Asociativa: por afinidad semántica o evocación. Por ejemplo, veneno-toxicidad.

Tipos de lenguajes documentales

Libres, por ejemplo extraer automáticamente de un texto las palabras que no pertenecen al fichero de palabras vacías.
Controlados:
- Anillos de sinónimos, entre los términos se establecen relaciones de equivalencia pero no de jerarquía ni de asociación. Al hacer una búsqueda se recuperan también los indexados por sus sinónimos. Reduce el silencio en las búsquedas pero aumenta el ruido.
- Fichero de autoridades, listado de términos principales (con sus respectivos sinónimos) para describir y normalizar un conjunto de entidades (personas, organizaciones, lugares geográficos) ante la variedad de homónimos, sinónimos o nombres con los que puede ser denominada una persona, entidad, obra, tema o concepto. Se utiliza especialmente en la catalogación de los fondos de las bibliotecas.
- Lista de encabezamientos de materia (LEM), en el cual el encabezado condensa el tema del documento con uno o varios términos. Presentan relaciones asociativas, jerárquicas y de equivalencia. Se usan preferentemente en las bibliotecas y en los centros de documentación cuyos fondos son esencialmente enciclopédicos.
- Taxonomías, sus términos presentan relaciones de equivalencia y jerarquía pero no asociativas.
- Clasificación, representa entre sus términos relaciones asociativas, jerárquicas y de equivalencia y algunas veces asocia un código identificativo a cada uno de sus términos.
  La más utilizada en web es la clasificación facetada para poder clasificar simultáneamente desde distintos puntos de vista, o a partir de diferentes criterios, un mismo conjunto de objetos.
  Cada una de las clasificaciones o facetas es paralela a las demás en un mismo nivel semántico. Cada faceta sería una etiqueta del sistema de navegación global, o un campo de la base de datos; y las categorías de esa faceta serían las de uno de los sistemas de navegación local, o las de los posibles valores de un campo de la base de datos. Por ejemplo, cada faceta seria (corriente literaria, género literario, etc.) y las categoría (realismo, modernismo,…; novela, poesía,…).
- Tesauro, se encuentran integrados en los sistemas de navegación y búsqueda. Sus términos presentan relaciones asociativas (términos relacionados, TR), jerárquicas (términos genéricos, TG y términos específicos, TE) y de equivalencia.

En este apartado recomiendo también la lectura de dos artículo de Yusef Hassan Montero:

Bibliografía

BATES, M.J. (1989): “The Design of Browsing and Berrypicking. Tecniques for the Online Search Interfaces”, Online Reviews, vol. nº3, pp. 407-424

CHAPARRO, B., G.MINNAERTS y C.PHIPPS (2000): “Limitations of Using Mouse-Over with Menu Item Selection”, Human Factors and Ergonomics Society Annual Meeting Proceedings

GALLETTA, D., R. HENRY, S.McCOY y P.POLAK (2006), “When the Wait isn’t So Bad: The Interacting Effects of Website Delay, Familiarity, and Breadth”, Information Systems Research, vol. 17, núm. 1, pp. 20-37”

GARRET, J. (2003): The Elements of User Experience. User-Centered Design for the Web, Nueva York: American Institute of Graphic Arts

JACKO, J.A y G. SALVENDY (1996): “Hierarchical Menu Design: Breadth, Depth and Task Complexity”, Perceptual and Motor Skills, vol. 82, pp. 1187-1201

KRUG, S (2000): Don’t Make Me Think: A Common Sense approach to Web Usability, Indianápolis (Indiana): New Riders

MORVILLE, Peter y ROSENFELD, Louis (1998): Information Architecture for the World Wide Web, Sebastopol (California): O’Reilly Media Inc.

- (2006): Information Architecture for the World Wide Web, 3ª edición, Sebastopol (California): O’Reilly Media Inc.

MILLER, D.P (1981): “The Depth/Breadth Tradeoff in Hierarchical Computer Menus”, Proceedings of the Human Factors Society 25^TH Annual Meeting, pp. 296-300

MILLER, C. y R.REMINGTON (2002): “Effects of Structure and Label Ambiguity on Information Architecture”, Conference on Human Factors in Computing Systems, pp. 630-631

- (2004): “Modeling Information Navigation: Implications for Information Architecture”, Human-Computer Interaction, vol. 19, núm.3, pp. 225-271

PEREZ-MONTORO, Mario (2010): Arquitectura en entornos web, Gijón: Ediciones Trea

SNOWBERRY, K., S. PARKINSON y N. SISSON (1983): “Computer Display Menus”, Ergonomics, vol. 26, núm.7, pp. 699-712

[1] Consultar "Disciplinas relacionadas con la usabilidad"

[2] Miller, 1981 indica que el máximo de enlaces que retenemos mentalmente cuando navegamos es de 7.

Pero Krung, 2000 defiende que el número de enlaces que recordamos depende de lo que se tenga que recordar. Lo importante es utilizar etiquetas adecuadas al nivel cultural y profesional de los usuarios y discriminar visualmente lo principal de lo secundario.

Porter, 2003 demostró que la regla de los 3 clics es falsa y por tanto no debe fundamentarse en ella la selección de jerarquías anchas y poco profundas, pues lo importante es que cada clic sea significativo y no ambiguo (Krug 2000). Hay que tener en cuenta que las jerarquías muy anchas y poco profundas exigen un mayor esfuerzo cognitivo del usuario para elegir entre todas las opciones del mismo nivel, mientras que las jerarquías estrechas exigen menor esfuerzo cognitivo al tener que elegir entre pocas opciones, de modo que a medida que se avanza, se van desambiguando y da sensación de ser una web menos compleja (ver modelo modelo pearl-growing).

Miller, 1981 defiende que hay que buscar un equilibrio entre la anchura y la profundidad de la estructura. Si el usuario se encuentra demasiadas opciones en el menú principal, en una jerarquía muy ancha y poco profunda, tiene la sensación de escasez de contenido, y si es muy profunda puede sentirse perdido.

Snowberry, Parkison y Sisson, 1983 defienden las jerarquías anchas. Las profundas reclaman mayor memoria a corto plazo, y las anchas transmiten más sensación de orientación, aunque exigen mayor habilidad de análisis visual para identificar las correlaciones semánticas entre los contenidos categorizados.

Galletta, Henry, McCoy y Polak, 2006 defienden las estructuras planas cuando la web es lenta, concluyendo que lo importante realmente es la familiaridad de los contenidos que es lo que más reduce el tiempo de localizar la información.

Jacko y Salvendy, 1996 especifican que el tiempo para completar un tarea aumenta tanto en estructuras anchas como profundas (en este caso más) pero que minimizar la profundidad reduce la percepción de complejidad.

Si la ventaja de las jerarquías anchas es la sensación de orientación, Miller y Remington, 2002, 2004 defienden que un buen sistema de etiquetado no ambiguo en una estructura profunda alteraría la máxima de que las planas son más eficientes, que completaría la tesis de Galletta, Henry, McCoy y Polak, 2006 de que los efectos negativos de la estructura ancha se mitigan con se establece una relación de familiaridad con sus contenidos.

Últimos anteriores

Servicios relacionados

Análisis de interfaz (AI & UX): Arquitectura de información. Diseño de interacción. Prototipado. Experiencia de usuario.

Cuando los problemas de usabilidad afectan a la vida real de las personas

2009-11-09T20:49:00.007+01:00

Estoy furiosa. Supongo que no debería escribir furiosa, pero que le vamos hacer.

Esta mañana me he vuelto a enfrentar a la web de "Cita previa" del Gobierno de Aragón, un servicio que debería facilitarnos la vida y no complicárnosla más.

Lo sencillo sería poder ver las franjas horarias de un día y de un vistazo comprobar las que están libres y seleccionar una. Eso sería lo sencillo, claro.

En su lugar tienes que introducir la hora a la que quieres la cita, el sistema hace la consulta y te sale una alerta (sí, sí, un "alert") proponiéndote la hora libre más cercana, a partir de ahí, a prueba y error, vas introduciendo horas hasta que te propone una que te va bien. Tampoco puedes probar mucho porque entonces te impiden seguir y tienes que salir y volver a entrar al sistema.

Tanteé varias horas, el sistema me propuso las 16:45 y acepté.

Saqué a la niña del colegio antes, cogí un taxi y esperé con ella hora y media en la consulta porque acumulaban mucho retraso. Entonces, cuando me tocaba entrar, llamaron a una persona que tenía hora para las 16:55, es decir, posterior a la mía.

En un momento de lucidez una terrible sospecha me vino a la cabeza... sería posible que...

Me acerco a recepción y le pido a la amable señorita que compruebe si mi cita está registrada. En efecto, lo estaba... pero, como sospechaba, para el día siguiente. La chica me consoló diciéndome que eso mismo le había pasado hoy a varias personas. Como el caso no era urgente siempre podía espera otra horita u horita y media para que la viera el médico.

Quien tiene hijos sabe que esperar hora y media en la consulta es una odisea, pero esperar tres es un suicidio. Así que volveremos mañana otra vez.

¿Que pasó? Como el día de hoy estaba completo, el sistema de "Cita previa" me dió la primera hora libre para el día siguiente. ¿Tanto costaba poner un mensaje indicando que para hoy no había horas libres? ¿Tanto costaba remarcar que la cita me la daban para otro día?

¿Es que los que han ideado esta web no piden cita a través de ella? Intentar pedir una revisión para un niño es imposible. Primero no puedes indicar que quieres una cita para revisión, segundo no te informan si para esa revisión debes pedir cita con la enfermera o también con el médico, en cuyo caso, ¿cómo podría a prueba y error encontrar un día y una hora en que ambos estén disponibles? ¿es un juego de azar para poner a prueba tu inteligencia o es un sistema para ayudar al ciudadano?

Por favor, si me lee algún responsable del sistema de "Cita previa", se lo suplico, háganos un favor a mucha gente, mejoren la usabilidad de la aplicación, no pido mucho, sólo que apliquen el sentido común.

En fin, como digo, estoy bastante enfadada.

Documentos que recomiendo conocer(7)

2009-10-22T15:00:00.004+02:00

Serie "Documentos que recomiendo conocer"

Usabilidad

Libros

"The Principles of Readability", William H. DuBay, 2004 (PDF)

"Introduction to Good Usability", Peter Conradie, 2008 (PDF)

"Search User Interfaces", Marti A. Hearst, 2009

"Research-Based Web Design & Usability Guidelines", Michael O. Leavitt y Ben Shneiderman , 2006 (PDF, 157 MB)

Accesibilidad

Libros

"Guía de estilo sobre discapacidad para profesionales de los medios de comunicación", José Luis Fernández Iglesias, 2006. Permite la descarga gratuita en PDF.

"Diseño de Páginas Web Accesibles", Sección de Documentación Consejería de Trabajo, Consumo y Política Social de la Región de Murcia. Permite la descarga gratuita en PDF.

"Delivering inclusive websites", COI, 2009 (PDF)

Recursos

"IMS Guidelines for Developing Accessible Learning Applications", 2002

"IBM Web accessibility checklist", IBM

"Evaluación de la accesibilidad de sitios web con la barra de herramientas de Firefox Web Developer Toolbar" de Sergio Luján

"Google accessibility"

Accesibilidad en documentos de Office

"Pautas de accesibilidad en presentaciones PowerPoint", CEAPAT. [Visto en accesibilidadweb.com]

"Accessible Web Publishing Wizard", Virtual508.com. Accesibilidad de documentos Word y PPT.

Navegadores

"When can I use... Compatibility tables for features in HTML5, CSS3, SVG and other upcoming web technologies", Alexis Deveria.

SEO y marca

"Audiciencia de Internet", AICM (Asociación para la Investigación de Medios de Comunicación)

"Personal Branding", Colin Wright [Visto en sortega]

"How to convert clicks into profit", Google [Visto en Daniel Ulczyk]

Enlaces en los que perderse (5)

2009-10-22T14:58:00.000+02:00

User Experience

"So you wanna be a user experience designer", Whitney Hess, 2009. La autora nos propone todo tipo de recursos: libros, blogs, publicaciones, eventos, listas de correo, etc.

Information Architecture

Information Architecture Institute. Learning IA. En el portal del Information Architecture Institute podemos encontrar todo tipo de recursos relacionados con Arquitectura de Información.

"Gestión de proyectos web – Arquitectura de la Información", Anna García Sans, 2009.

Maquetación

Code.google.com

Artículos relacionados:

Documentos que recomiendo conocer(6)

2009-07-07T20:52:00.005+02:00

Serie "Documentos que recomiendo conocer"

Guías e informes

"Guía de Accesibilidad en los contenidos para dispositivos móviles" de Inteco.

Es especialmente recomendable leerse el apartado "5. Directrices para el desarrollo de contenidos para dispositivos móviles".

Artículo relacionado: Web móvil y W3C en el que se explica qué es la MWI (Mobile Web Initiative), las MWBP (Mobile Web Best Practices) y su relación con las WCAG (Web Content Accessibility Guidelines)

"Informe sobre la normativa aplicable y evolución legislativa en el sector de las Tecnologías de Accesibilidad en España 2008" y el "Informe sobre la homologación y normalización en el sector de las Tecnologías de Accesibilidad en España 2008" del Centro Nacional de Tecnologías de la Accesibilidad. Ambos en formato PDF.

Artículo relacionado: "Referencia sobre legislación española relacionada con la accesibilidad web".

"Informe APEI sobre usabilidad" 2009, por Yusef Hassan Montero y Sergio Ortega Santamaría".

Una gran introducción a la Usabilidad y el Diseño Centrado en el Usuario. [Vía Human-Computer.net]

Cursos, revistas y libros online

Journal of Information Architecture

"Search User Interfaces" de Marti Hearst, Cambridge University Press (2009). El libro está en inglés y es gratuito. [Vía Human-Computer.net]

"Estándares y accesibilidad: mínimo indispensable (o Cómo convertirse en un estandarista en 15 horas)", un curso online gratuito de codexexempla.org

"Curso Introducción a la Interacción Persona-Ordenador ", un clásico de AIPO. También disponible en PDF.

Otros

Proyecto MUPA-UOC. Metodología de usabilidad para aplicaciones de la Universitat Oberta de Catalunya

"Research Paper - Real or Imaginary: The effectiveness of using personas in product design" de Frank Long [Vía Human-Computer.net]

El objetivo del estudio era averiguar si el uso de personajes aseguraba efectivamente un producto más centrado en el usuario. El estudio demuestra con pruebas objetivas la eficacia de la utilización de personajes especialmente en las primeras etapas del proyecto:
- El uso de personajes fortalece el enfoque en las necesidades de los usuarios finales y, por tanto, la toma de decisiones se centra más en esas necesidades.
- El uso de personajes puede mejorar la comunicación entre los equipos y facilitar una discusión más constructiva basada en el diseño centrado en el usuario.
- El uso de ilustraciones en lugar de fotografías disminuye su eficacia: puede conducir a un examen selectivo de las características de la persona, un menor nivel de empatía hacia la persona ilustrada y una menor capacidad para recordar los detalles de la persona después de un tiempo.
- El escenario en forma de storyboard fue más eficaz que la versión más detallada.
- Su eficacia disminuye cuando no se invierte el suficiente tiempo o recursos en esta técnica y entonces puede causar más daño que bien. Si la investigación y el análisis no son exhaustivos, la confianza en los personajes se verá menoscabada. Si el personaje y sus objetivos no son correctos entonces la dirección del diseño será inapropiada.
Artículo relacionado: "La usabilidad como metodología para el desarrollo de una aplicación"

Imprescindibles (14)

2009-03-08T16:21:00.007+01:00

Estos son los artículos que han llamado mi atención últimamente (no tienen porque ser recientes):

Usabilidad

Gestión y prevención de errores en interfaces de usuario de Deinterfaz.

¿Qué es necesario saber para dedicarse a la usabilidad? de Torres Burriel.

"Medir al consultor de usabilidad" de Alberto Lacalle.

Cómo evitar contenido duplicado de Daniel Ulczyk. Relacionado: "Multi categories website structure. Who needs the canonical tag?" de Ani López.

rel=”canonical”, lo último para combatir el contenido duplicado de Andrés Nieto.

User Experience Deliverables de Peter Morville.

Diseño defensivo en formularios de Usolab.

¿Conoces los microformatos que están por venir? de Torres Burriel.

Eyetracking, movimiento e información neuronal de Sopa de bits.

Consejos para diseñar emails de Sentido Web.

Diseño y maquetación

Reemplazo de textos – una comparación de Diseñorama.

A vueltas con los 72 dpi de Diario de un Infografista.

Accesibilidad

Survey of Preferences of Screen Readers Users de Webaim.

Accessibility footnotes (o cómo implementar de otra manera el LONGDESC) de Andy Clarke.

Varios

Qué acciones tomar cuando roban tus contenidos de Maestros del Web.

Enlaces en los que perderse (3)

2009-03-05T15:01:00.001+01:00

Accesibilidad

Curso de accesibilidad online y gratuito de SEDIC. El nivel es muy básico pero puede ser interesante el apartado de recursos sobre accesibilidad.

100 Killer Web Accessibility Resources: Blogs, Forums and Tutorials en WHDB.

Publicaciones de capaces.org

Accessibility en icant.co.uk de Christian Heilmann.

Usabilidad

Proyecto nuevo portal web Unicauca, ¿quieres seguir paso a paso la creación de un portal? Puedes consultar los wireframes, las pruebas de cardsorting, seguir el proceso de diagramación del portal o consultar el análisis de otros portales similares mediante evaluaciones heurísticas.

Publications, Nielsen Norman Group. Y por supuesto Useit de Jakob Nielsen

Usability Resources, Information & Design

Diseño

Preimpresión, "apuntes personales sobre el curso de diseño y producción editorial" por Percy Emerson (en español)

CSS Feeder Design Aggregator

Varios

Materiales de formación del CNICE

Imprescindibles (13)

2009-01-21T22:39:00.002+01:00

Estos son los artículos que han llamado últimamente mi atención (no tienen porque ser recientes):

"Best of CSS Design 2008" de WebDesigner Wall.

30 Usability Issues To Be Aware Of, un artículo imprescindible donde se resumen reglas, términos y principios relacionados con la usabilidad.

10 Reasons Clients Don't Care About Accessibility. Relacionado con Argumentos para vender accesibilidad

"¿Qué no es la experiencia de usuario?" de Itákora.

"Analizar y representar gráficamente los resultados de un card sorting" de deinterfaz.com. Y relacionado con el tema "Card sorting: un caso práctico en el diseño de un sitio web universitario" de NSU.

"Principios del diseño de interacción importantes para la accesibilidad" de areia.info

Imprescindibles (12)

2008-11-22T22:04:00.000+01:00

Estos son los artículos que han llamado últimamente mi atención (no tienen porque ser recientes):

Diseño

"Escogiendo tipografías", de Letritas.

Si estuviéramos trabajando en condiciones ideales, donde sólo nos debatimos a elegir entre las tipografías que tenemos, y todas funcionan correctamente (todas tienen "eñe", "acentos", y están bien espaciadas) ¿Cuál debiese ser nuestro principal criterio de elección?

"11 Images you might want to avoid in your designs", de snap2objects.

I will show some images I considered overused since the beginning of the web and could make your website (or any design) look generic, unimaginative and dated - if use them just for the sake of it.

Un recurso para cuando te piden que incluyas las típicas imágenes de manos dando apretones o edificios acristalados.

"Editores web que facilitan tu trabajo" de Maestros del Web.

Usabilidad

"12 preguntas clave para un proyecto web", de MoccaBlog Café.

El objetivo es definir el diseño y el acercamiento al usuario final (cliente de tu cliente).

"La evolución de los errores según Jakob Nielsen", de Interacciones. Relacionado con este post se puede leer el artículo "Error Message Guidelines" de Jakob Nielsen.

"Consejos para presentar los resultados de un test de usabilidad", deinterfaz.

Simplificando, podríamos decir que se pueden generar resultados rápidos (informes ligeros que van al grano) y resultados formales (informes completos y documentados), cada uno con sus ventajas y sus inconvenientes. Yo me voy a centrar los segundos.

Relacionado con este artículo está el de Jakob Nielsen: "Formal Usability Reports vs. Quick Findings"

"What reading Tufte won’t teach you: Interface design guidelines", de glyphobe

Estudio "Publicidad y Contenidos en medios de comunicación online Estudio de Eyetracking a diarios online chilenos" de AyerViernes.

Estudio "Eyetrack Medios España" de Alt64. Se puede descargar directamente en formato PDF.
Eyetracking Medios España tiene por objetivo:
- Estudiar el comportamiento visual de los internautas españoles.
- Estudiar la efectividad de la publicidad online.

"Eyectrack III: Cómo lucen los sitios web a través de los ojos de los lectores" de Steve Outing y Laura Ruel.

"Dónde estudiar HCI en España" en Itákora.

"Quién es quién en el mundillo de HCI española" de Itákora.

Accesibilidad

"Serie 'Guía breve para crear sitios web accesibles'", de Accesibilidad en la Web.

"Navegando una página Web con Jaws: consideraciones de accesibilidad para desarrolladores" deinterfaz.

Vamos a ver de qué manera un usuario que utiliza Jaws navega entre los diferentes elementos de una página Web y como un desarrollador de páginas Web debería actuar para alcanzar el nivel de accesibilidad Doble A (AA).

"Redactar una auditoría de Accesibilidad Web de alto nivel" de interfaz.

"Presentaciones sobre Accesibilidad" de Usabilidad y Accesibilidad.

"Data Table Accessibility Test Page" de Web Usability.

"Enlaces para 'leer más' que sean simples y accesibles" de Torres Burriel.

Imprescindibles (11)

2008-10-07T09:01:00.000+02:00

Estos artículos han llamado mi atención últimamente:

¿DOM (Document Object Model) o innerHTML?

¿Cuál de los dos métodos es más rápido para generar grandes cantidades de contenido?

Podemos ver el resultado de esta pregunta, en función del navegador utilizado, en Benchmark - W3C DOM vs. innerHTML.

Nielsen: sólo el 7% de los usuarios utiliza los sitemaps

Así lo explica Jakob Nielsen en el estudio Site Maps Usability

Baquía nos reseña el estudio:

Según un estudio elaborado por Jakob Nielsen, apenas un 7% de los usuarios recurre a los mapas de una web. Sin embargo, es aconsejable mantenerlos, puesto que suponen una forma fácil y directa de acceder a todo el contenido de una web.

¿Te has preguntado de dónde obtienen sus beneficios las empresas web 2.0?

Web 2.0: ¿Dónde se esconde el negocio? (II)

Fundamentos teóricos de esta profesión

Usándolo nos los va resumiendo en distintos artículos:

Leyes y principios: Fitts’ Law

Principios de usabilidad: La regla de los 3 clicks

10 errores principales en el diseño de aplicaciones (Nielsen)

El artículo de Nielsen Top-10 Application-Design Mistakes es resumido y traducido por el blog del grupo SQUaC(Software Quality Usability and Certification).

Estos errores son:

Controles GUI (Graphical User Interface) no estándar

Inconsistencia

No mostrar claramente su funcionamiento

Sin retroalimentación

"He salido a comer" sin un indicador de progreso

Malos mensajes de error

Pedir la misma información varias veces

Sin valores por defecto

Usuarios "lanzados" contra la aplicación

No indicar cómo se usará la información

Funcionalidades centradas en el sistema

Error extra: botones de reset en formularios web

34 buenas prácticas para hacer tus páginas más rápidas

Las best practices for making web pages fast que propone el Yahoo!'s Exceptional Performance son:

Make Fewer HTTP Requests

Use a Content Delivery Network

Add an Expires or a Cache-Control Header

Gzip Components

Put Stylesheets at the Top

Put Scripts at the Bottom

Avoid CSS Expressions

Make JavaScript and CSS External

Reduce DNS Lookups

Minify JavaScript and CSS

Avoid Redirects

Remove Duplicate Scripts

Configure ETags

Make Ajax Cacheable

Flush the Buffer Early

Use GET for AJAX Requests

Post-load Components

Preload Components

Reduce the Number of DOM Elements

Split Components Across Domains

Minimize the Number of iframes

No 404s

Reduce Cookie Size

Use Cookie-free Domains for Components

Minimize DOM Access

Develop Smart Event Handlers

Choose <link> over @import

Avoid Filters

Optimize Images

Optimize CSS Sprites

Don't Scale Images in HTML

Make favicon.ico Small and Cacheable

Keep Components under 25K

Pack Components into a Multipart Document

La aventura de crear tu propia empresa

Aunque no tiene que ver con la temática del blog, me ha parecido una bitácora muy original e interesante. Jaime Estévez narra el día a día en la creación de su nueva empresa.

Jaime Estévez. 100 días en la vida de un emprendedor

Faz nº2: artículos que han llamado mi atención

2008-08-27T09:00:00.000+02:00

Tres son los artículos que más han llamado mi atención en el número 2 de la revista Faz.

1

En "Evaluación de Valencia y Contenido Emocional Para Interfaces Web Gráficas: Un Caso de Estudio en Banca Chilena", Claudio Lavín y René San Martín sintetizan un estudio cuyo objetivo ha sido evaluar las reacciones emocionales generadas por el nuevo sitio Web de una de las principales instituciones bancarias de Chile, y el desafío metodológico que ello les ha supuesto.

Como las emociones son un fenómeno dinámico y multicausado, la herramienta ideada es una batería de pruebas que han denominado "batería para la evaluación de emociones elicitadas por interfaces Web gráficas (BEEI Web)".

Estas pruebas son:

"Contraste de sitios". Esta prueba operacionaliza la valencia emocional (1) en término de expresiones de agrado y desagrado hacia las interfaces Web gráficas.

Resumido muy, muy escuetamente, se proyectan imágenes de páginas web y en tres segundos los participantes deben decidir si les agrada o no cada imagen.

“Elicitación de conceptos” permite evaluar el componente semántico asociado a las emociones. Dicho componente semántico dice relación con los conceptos y el significado que se asocia a una interfaz Web gráfica.

Resumiendo de nuevo, consiste en proyectar imágenes de webs y que los participantes escriban los cinco primeros conceptos que les vienen a la mente en relación con las mismas.

2

En "Diez heurísticos emocionales" Eva de Lera y Muriel Garreta-Domingo explican su estudio piloto.

En el análisis de evaluación de la interfaz se consideraron las tres dimensiones.

La dimensión cognitiva se analizó a través del número de clics, el tiempo que se necesitó para llevar a cabo la tarea y el número de errores.

La percepción emocional del usuario se obtuvo a través del cuestionario de respuesta y la dimensión afectiva se observó a través de los diez signos emocionales. Asímismo se registraron las expresiones y los comentarios de los usuarios para complementar los resultados de la evaluación.

Un equipo multidisciplinario observó las pruebas: un director de la experiencia del usuario, un psicólogo y un diseñador gráfico.

En el análisis realizado por los observadores, tanto de las interacciones como de las observaciones registradas, se llegó a la conclusión de que los signos emocionales, junto con los datos objetivos, aportaban una comprensión más precisa sobre la experiencia del usuario y su nivel de satisfacción que el cuestionario rellenado al final de la prueba.

Los diez heurísticos son:

Fruncir el ceño

Elevar las cejas

Desviar la mirada

Sonreír

Apretar los labios

Mover la boca

Expresarse oralmente

Tocarse la cara con las manos

Reclinarse hacia atrás

Inclinar el cuerpo hacia adelante

3

En "Aprendiendo de los videojuegos" Joaquín Márquez Correa nos hace una propuesta muy interesante: levantar la cabeza de la mesa de trabajo y mirar alrededor. Abrir la mente para ofrecer nuevas soluciones.

Propone observar el diseño de otro tipo de productos para buscar inspiración y buenas ideas para el diseño de interfaz. Como ejemplo, en el artículo habla de las cuatro características que tiene todo videojuego y que deberíamos tener en cuenta también en el diseño de nuestros portales:

Adaptación a la tarea: abandono y retomo cuando quiero

Apoyando el proceso de aprendizaje: más experto, más opciones

Personalización estandarizada: mis preferencias siempre conmigo

Modo arcade v/s modo historia; tareas simples v/s tareas complejas

Notas
(1) Capacidad de los objetos que percibimos para provocar una emoción, y que es prácicamente automática.

Documentos que recomiendo conocer (1)

2008-07-29T18:00:00.002+02:00

Artículos relacionados
[15-11-08] Documentos que recomiendo conocer (2)

1
"Guía Web 2.0". La Guía Web 2.0 es el instructivo gubernamental orientado a mejorar la usabilidad en los sitios del Gobierno de Chile. Se puede descargar en PDF.

2
"Web Accessibility for Older Users: A Literature Review" del W3C.

Ese documento contiene análisis y revisiones de recomendaciones y artículos relacionados con las necesidades de las personas de edad avanzada y la accesibilidad web requerida por los efectos de esa avanzada edad en las personas, comparándolas con las necesidades de las personas ya descritas en las Pautas de Accesibilidad para el Contenido en la Web.

Vía Torres Burriel

Artículo relacionado: "Análisis de usabilidad de los portales en español para personas mayores" de NSU.

3
"Sistemas y esquemas de evaluación de la conformidad para requisitos de accesibilidad", informe realizado en el grupo europeo Project Team CEN/BTWG 185 "e-Accessibility".

Artículo relacionado: "Metodologías, certificaciones y entidades certificadoras de la accesibilidad web en España" en este blog.

4
"El imperativo de la accesibilidad: Implicaciones de la Convención de Derechos de las Personas con Discapacidad para las Tecnologías de la Información y la Comunicación" de G3ict, Iniciativa Global para las Tecnologías de la Información y la Comunicación inclusivas.

Trata de los retos y oportunidades que supone la aplicación de la Convención en lo referente a la accesibilidad de las TIC.

5
"Decálogo de León", conclusiones de la Conferencia Europea EDeAN (European Design for all e-Accessibility Network) que se celebró en León (España) los días 12 y 13 de junio de 2008 y en la que participaron más 200 expertos y representantes de organismos nacionales y europeos.

6
UNE 139804:2007. Requisitos para el uso de la lengua de signos en redes informáticas

7
WCAG Samurai Errata for Web Content Accessibility Guidelines (WCAG) 1.0

Artículos relacionados
[15-11-08] Documentos que recomiendo conocer (2)

Imprescindibles... (10)

2008-07-28T14:01:00.000+02:00

Lo que todo diseñador debería saber, y son muchas las que propone MoccaBlogcafé.

Las 8 principales razones por las que la gente abandona una página Web de Jorge A. Mendoza. Entre ellas destacan: "Páginas lentas o vínculos inexistentes" (84%), "No se encontró la información requerida" (68%), "No se encontró la información de la empresa" (31%) o "Facilidades de búsqueda limitadas" (23%).

15 sitios que necesitas conocer si buscas inspiración de Kabytes

¿Minusválido, inválido, disminuido, incapacitado o discapacitado? de Sergio Luján. En el artículo se concluye que se debe hablar de "persona con discapacidad" o "personas con diversidad funcional", siempre de personas, porque antes de tener una discapacidad, se le considera persona, por eso debe anteponerse esta palabra.

Mejorar el código de una página web de Javier García

Hablando sobre internacionalización de pixelco.us. Un sitio Web internacional permite garantizar su utilización universal incluyendo todos los idiomas y culturas.

Diseño de Interfaz y objetivos de proyecto de Daniel Torres Burriel. Cómo se relacionan cuatro conceptos básicos: Diseño de Interfaces, Diseño de interacción, Arquitectura de Información y Experiencia de usuario.

Usabilidad para frikis

2008-07-24T09:01:00.001+02:00

Me ha hecho mucha gracia este artículo, que explica de forma muy amena qué es la usabilidad.

La Guerra de las Galaxias se perdió por un problema de usabilidad, o por qué el X-Wing es mejor que el TIE-Fighter

Muchas gracias al que me ha pasado el enlace.

Imprescindibles... (9)

2008-07-21T09:00:00.001+02:00

Los artículos que más han llamado mi atención durante estos últimos meses han sido:

1
Revisión automática de páginas con la norma UNE 139803 mediante PISTA

En diciembre comentaba en Mis validadores que una de mis herramientas preferidas para la revisión automática de la accesibilidad de un sitio Web era PISTA, herramienta del Ministerio de Industria, Turismo y Comercio.

Una de sus muchas ventajas es que permite realizar análisis de accesibilidad con normativas distintas a la WAI WCAG1.0 (normativa por defecto). El único requisito que deben cumplir las normativas que se añadan a la herramienta es que estén especificadas en un fichero XML que siga el DTD "normativas.dtd".

En el manual de la herramienta se explica como realizarlo.

Tenía pensado desde hace tiempo incluir un nuevo fichero para poder validar automáticamente con la Norma UNE 139803, que como ya he comentado otras veces, es la norma que han de cumplir muchos sitios Web españoles desde finales de año, y que sólo se diferencia en cuatro puntos de las WCAG 1.0, como ya expliqué en Diferencias de prioridad entre los requisitos UNE 139803:2004 y los puntos de control de las WCAG 1.0

Pues bien, Olga Revilla nos ha ahorrado el trabajo y nos facilita la vida desde su blog Itákora. En Cómo validar las normas UNE 139803 con la herramienta PISTA te explica como descargarte e importar en PISTA el XML para validar automáticamente con la Norma UNE 139803.

Otro artículo de Itákora relacionado es: Comparativa de accesibilidad de las WCAG 1.0 y la norma UNE 139803/2004.

2
Cómo definir un menú de navegación

En "Sugerencias para definir un menú de navegación" Jorge Garrido ofrece unas interesantes pautas para planificar nuestro menú de navegación.

3
Word accesible

En "Cómo crear un documento Word accesible" Fran Tarifa remata una discusión dentro de la lista AccesoWeb.

Emmanuelle comentaba:

Si por accesible entendemos que pueda ser usado por cualquier persona en cualquier situación y mediante cualquier dispositivo, evidentemente la respuesta es no. Puesto que se trata de un formato propietario, debe siempre ofrecerse la información que se tenga en ese formato en otro formato que sea abierto y accesible o en varios formatos para cubrir las necesidades de todos los usuarios potenciales.

Ahora, lo que sí se puede y se debe hacer, es ofrecer los contenidos en word de manera que puedan acceder a ellos los usuarios de lectores de pantalla, y seguir unas pautas en su elaboración.

Entonces, aparte de que ofrezcas los contenidos en otros formatos, además de en Word, deberás estructurar el contenido de los documentos, usar correctamente los estilos, simplificar el lenguaje, etc.

Se daban dos referencias interesantes sobre cómo hacer documentos Word accesibles:

"Microsoft Word" de WebAIM

Guidelines: Accessible Word Documents

En este contexto, es interesante la herramienta aDesigner que permite evaluar la accesibilidad de documentos ODF.

4
La crueldad de los internautas según Nielsen

En "La crueldad de los internautas" la BBC comenta el informe anual sobre los hábitos en el uso de Internet de Jakob Nielsen. Me llama especialmente la atención que el 75% de los usuarios no navega por un sitio, sino que utiliza directamente el buscador del mismo.

"Los usuarios de internet siempre han sido despiadados y ahora lo son más que nunca", dijo Nielsen. "La gente quiere sitios que los lleve, sin rodeos, al punto. Tienen muy poca paciencia", señaló. "Creo que los sitios todavía no han apreciado eso", agregó. "Aún sienten que su sitio es interesante y especial y que la gente estará feliz con todo lo que se le arroje".

[...]

Los internautas también se están frustrando mucho con todas las adiciones, como los "widgets" (artilugios) y las aplicaciones que se vienen agregando a los sitios para hacerlos más amigables. Tales adiciones sólo están sirviendo para que las páginas se tarden más en cargar, afirma Nielsen.

[...]

En 2004, un 40% de los internautas visitaba una página principal y luego navegaban hacia donde querían ir, y un 60% usaba un vínculo que los llevaba directamente al destino buscado dentro de un sitio.

En 2008, dijo Nielsen, sólo un 25% de las personas navega a través del "homepage" o página principal. El resto usa el buscador o "search engine" y se va directo a donde quiere.

5-6
No justifiques el texto en la web

Estoy totalmente de acuerdo con el artículo "La justificación de texto en la web" de Duopixel. La próxima vez que me pidan que justifique un texto les pasaré directamente su post.

Se puede seguir la lucha dialéctica sobre este tema en AccesoWeb.

Leyendo este artículo me llama la atención el título de otro, "¿Cómo llamar a la persona que usa un objeto de diseño?", en el cual reflexiona sobre las alternativas al odiado "usuario" de Donald Norman, que aboga por el término "persona".

7
URLs y usabilidad

En "La usabilidad también tiene en cuenta las URLs" Gabriel Porrás introduce el artículo "URL semántica / Clean URL / Friendly URL" de Viv Dehaes.

8
Google y accesibilidad

En "Google y Accesibilidad" Nelson concluye que la accesibilidad no sólo beneficia los usuarios que por ejemplo navegan en condiciones no tradicionales (conexiones de baja velocidad, uso de dispositivos móviles, etc.) sino que "facilita la labor de los robots indexadores como Googlebot, lo que te beneficia porque genera mejores puntajes y posicionamiento en los resultados de búsqueda, por lo tanto, más visitas".

Y como bien dice él: "esta relación, independientemente de cualquier argumento humanista que se pueda hacer al respecto, es desde ya un muy buen argumento de ventas de la accesibilidad".

9
Frases que asesinan a la accesibilidad

Didáctica de la accesibilidad y "frases asesinas" recopila las frases que funcionan como excusas o impedimentos para justificar la accesibilidad de un sitio. Lo triste es que son ciertas, yo al menos he oído cinco de las diez que citan.

10
Bug de Internet Explorer 7

Andrés Nieto comenta un Curioso bug en Internet Explorer 7 . Aunque parezca increíble, una lista OL pierde la numeración cuando se le aplica un HEIGHT en la CSS.

11
Cosas que no debes hacer al construir un sitio web

En microsiervos encontramos un resumen en español de 19 Things NOT To Do When Building a Website, de Josiah Cole

Wireframes

2008-03-11T11:32:00.028+01:00

Artículos relacionados:

Última actualización: 21 de enero de 2011

Terminología

Wireframe, Blueprint, Prototipo, Storyboard, Mock Up, Diagrama de contenido, Sketching …

Lo primero aclaremos la terminología.

Como expliqué en "Disciplinas relacionadas con la usabilidad", hay diversas disciplinas que intervienen en el Diseño de Interfaz de Usuario, entre ellas se encuentra la Arquitectura de Información (AI).

El Arquitecto de Información se encarga de definir la organización, etiquetado, navegación y sistema de búsqueda de un sitio web, elementos que ayudan a los usuarios a encontrar y gestionar la información de manera efectiva.

Para llevar a cabo estas tareas nos valemos de la diagramación para especificar cuál será la organización, estructura, funcionamiento y navegación del sitio.

Existen dos tipos de diagramas (sin contar los que pueden surgir de la aplicación de otras técnicas como el Card Sorting) como podemos ver en este gráfico de NSU:

[DE-1]

Así pues distinguimos:

los PLANOS, que son diagramas de organización y funcionamiento
las MAQUETAS, que son diagramas de presentación

Planos: diagramas de organización y funcionamiento

Los diagramas de organización y funcionamiento se llaman BluePrint (también Architecture Map o Diagramas de contenido o flujo) y pueden ser más o menos avanzados. Es lo que también se denomina mapa web. En NSU vemos dos ejemplos, uno más sencillo y otro más completo:

[DE-2]

[DE-3]

Como se ve, el objetivo de estos diagramas es mostrar la estructura del sitio y su flujo de navegación.

Para la realización de este tipo de diagramas de recomienda siempre el "Vocabulario visual para describir arquitectura de información y diseño de interacción" de Jesse James Garrett.

Una herramienta sencilla y gratuita, recomendable para realizar mapas web sencillos, es XMind. Para realizar diagramas más complejos se pueden utilizar cualquiera de las herramientas recomendadas más adelante para la realización de wireframes.

Maquetas: diagramas de presentación

Por otro lado hemos visto que tenemos los diagramas de presentación, cuyo objetivo es mostrar el contenido de las páginas, concretando los elementos que se plantearon en los primeros planos (blueprints) y ubicándolos en las páginas o pantallas del producto final.

Podemos tener distintos tipos de prototipos, que en ningún caso incluyen el diseño gráfico puesto que este se aplica en una etapa posterior. Para simplificar, podemos hablar de:

Prototipos de Baja fidelidad: son un conjunto de dibujos que representan cómo estarán organizados los elementos en las páginas, de tal manera que implementan aspectos generales del sistema sin entrar en detalle. Dentro de prototipos de baja fidelidad hablaremos de:
- Sketching: un sketch es un boceto rápido e informal que se realiza en papel para transmitir una idea o concepto con rapidez y claridad. Suele realizarse durante las entrevista iniciales como técnica eficaz para comunicar al cliente conceptos o proponer alternativas a un problema; también es muy útil durante un brain-storming o en las reuniones con el equipo de trabajo. Es una forma eficaz de comenzar el prototipado de un sitio web, pues permite trabajar ágilmente con varias ideas y esquematizar las páginas.
- Wireframe: permite crear una referencia visual de la estructura de una página web, definiendo al detalle el contenido y su distribución visual, organizando así la información a nivel de página. Lo trataremos en detalle en el siguiente apartado.
- StoryBoard: secuencia de wireframes que muestran cómo se realiza una tarea.
  Imagen tomada de "Wireframes for the Wicked", de Michael Angeles, Nick Finck and Donna Spencer
  
  El doctor Granollers propone un nuevo tipo de prototipado, el StoryBoard Navegacional, que une los dos tipos de prototipado. Lo expliqué en el artículo, "Metodología DCU MPlu+a".
  También podemos oír hablar de “Thumbnail Sketches”, que es simplemente un storyboard de scketches:
  Imagen tomada de "Close Photoshop and Grab a Pencil: The Lost Art of Thumbnail Sketches", de Joshua Johnson
Prototipo de Alta Fidelidad (también llamados maqueta, mockUp o prototipo funcional), con los que se representan aspectos más precisos. Sirven, por ejemplo, para detallar el proceso interactivo global de una o varias tareas concretas. Son prototipos o maquetas dinámicas, normalmente en (X)HTML, que simulan o tienen implementadas partes del sistema final a desarrollar. Pueden ser de muy distintos tipos, completo o parcial, horizontal o vertical, etc.

En Sidar tienes un excelente artículo sobre distintos tipos de prototipado.

El propósito de crear estos prototipos es dar la oportunidad de evaluar el diseño prematuramente. El objetivo es producir estos prototipos rápidamente y evaluarlos eficazmente para que puedan ser refinados, elaborados y reevaluados antes del producto final. Ingeniería de la Usabilidad aplicada al desarrollo de un portal web administrado dinámicamente, José M. Belmonte Marín

Una vez aclarados los términos, me voy a centrar en los diagramas de presentación Wireframes.

¿Cómo es un Wireframe?

Como hemos visto, un wireframe es una representación esquemática de una página web sin elementos gráficos que muestran contenido y comportamiento de las páginas. Sirven como herramienta de comunicación y discusión entre arquitectos de información, programadores, diseñadores y clientes. También se pueden utilizar para pruebas de usuarios. "Wireframes: recopilación de enlaces" en No lo entiendo.

Es muy importante aclararle siempre al cliente qué es un Wireframe, estar seguros de que entiende que ese no es el aspecto final del sitio, sino una mera representación gráfica de su contenido.

Ejemplo 1: Wireframe del Rediseño del blog El Factor Humano 2.0 de WebStudio
Ejemplo 2: Representing Data in Wireframes de Dan Brown
Ejemplo 3: Wireframes for the Wicked, de Michael Angeles, Nick Finck and Donna Spencer:

¿Cuándo se realizan?

Una vez tengamos delimitados los objetivos del cliente, las necesidades de los usuarios y los contenidos y funciones de la web; antes de empezar a programar y de crear el diseño visual de la página. "Wireframes: recopilación de enlaces" en No lo entiendo

Por tanto, antes de hacerlo, es necesario tener todos los requisitos del proyecto: requisitos de negocio, de contenido, de diseño, de accesibilidad, etc.

Personalmente, antes de acometer un wireframe, realizo una serie de tareas previas:

Entrevistas con el cliente y el equipo de desarrollo para definir los requisitos, los objetivos y el público objetivo.
Estudio del portal actual (si existe): problemas de usabilidad y accesibilidad, estadísticas de acceso, test con usuarios y encuestas (en función del tipo del portal).
Benchmarking, o estudio comparativo de la competencia.
Definición de la arquitectura de informacón y mapa web.

Por otra parte, antes de comenzar a prototipar con Axure (herramienta que recomiendo como explicaré más adelante) suelo comenzar con bocetos personales (sketches) para trabajar las zonas que tendrán las páginas y esquematizarlas, para probar, desechar y tomar decisiones de forma ágil.

Ventajas de crear Wireframes

Hay dos grandes ventajas, por un lado el equipo y el cliente se centra en el diseño de contenidos y no en el diseño visual, y por otro lado, definiendo la organización y estructura en etapas previas al diseño y programación se evitan cambios posteriores más costosos, reduciendo así costes y tiempos.

El doctor Granollers resume estupendamente las principales características o ventajas de los prototipos (se refiere a los prototipos en general, no a los wireframes en particular):

Son formidables herramientas de:
- Comunicación entre todos los componentes del equipo de desarrollo y los usuarios
- Participación, para integrar activamente a los usuarios en el desarrollo.
Dan soporte a los diseñadores a la hora de escoger entre varias alternativas.
Permiten a los diseñadores explorar diversos conceptos del diseño antes de establecer los definitivos.
Permiten evaluar el sistema desde las primeras fases del desarrollo (facilitan la exploración de ideas sobre nuevos conceptos tecnológicos).
Son esenciales para la documentación, tanto de conceptos funcionales del sistema como de tareas concretas del mismo.
Son el primer paso para que ideas abstractas sean concretas, visibles y testables.
Fomentan la iteratividad.
Mejoran la calidad y la completitud de las especificaciones funcionales del sistema.
Son herramientas de propósito general, pues sirven para comprobar la fiabilidad técnica de una idea, clarificar requisitos que quedaron “indeterminados” o ver como responde con el resto de la aplicación.

¿Qué información debe contener un Wireframe?

Como bien indica "Using Wireframes" de Strange Systems:

Inventario de contenido. Qué contenido debe estar presente en cada página
Elementos de la página. Cabeceras, enlaces, listas, imágenes, formularios, etc.
Etiquetado. De vínculos, títulos, etc.
Layout. Ubicación, colocación y agrupación de los elementos de la página (cabeceras, pies, navegación, áreas de contenido, titulares, etc.) Muestra la estrategia de navegación y la priorización de contenidos dentro de la página, así como la agrupación en barras laterales, barras de navegación, áreas de contenido, etc.
Comportamiento. Mediante notas asociadas a los elementos para indicar cómo se deben mostrar (nº de elementos, visualización por defecto) o definir el comportamiento funcional cuando un elemento se activa (enlace externo, etc.)

Tipos de Wireframe

Como especifica "Using Wireframes" de Strange Systems, pueden ser más o menos detallados:

Content-only: tan sólo consta del nombre de la página y un listado de contenidos
Diagrama de bloques: contiene sólo la información básica a través de bloques de funcionalidad y agrupamiento de contenidos.
Wireframe detallado: tendría todos los elementos antes mencionados incluidas las notas de comportamiento (Ejemplo: Wireframe del Rediseño del blog El Factor Humano 2.0 de WebStudio)

¿De cuántas páginas creamos un Wireframe?

De la página principal y de los principales tipos de subpáginas o plantillas, entre las que deberán incluirse, una página de formulario, una página de resultado búsqueda y una página de error. Si estamos ante una aplicación deberá incluir una página de ingreso de datos, una página de detalle y una página de listado.

¿Cómo se hace un Wireframe?

37signals propone en "Una introducción a la utilización de patrones de diseño en la web" una metodología para hacer un Wireframe que consta de 6 pasos. No ha de tomarse como una receta mágica, pero puede orientarnos:

Haz una lista numerada de toda la información que debe tener tu página (no sólo datos, sino también acciones, actitudes), lo que llaman "bit".
Agrupa los "bits" que se relacionan entre sí. A cada grupo lo llamarías con una letra y asociada a esa letra pondrías los números de la información que relaciona. Por ejemplo A:1,3,5
Prioriza qué grupos son los más importantes desde un punto funcional, agrupando los grupos en tres prioridades: Lo más importante, Lo necesario y Lo que es bueno tener.
Diseña cada fragmento, cada agrupación de "bits". Lo podemos hacer sin preocuparnos de los conflictos porque ya sabemos que incluyen a todos los elementos relacionados entre si.
Junta los fragmentos teniendo en cuenta la prioridad y el equilibrio.
Hazlo real. Hasta ahora todo lo hemos hecho en papel, es el momento de pasarlo a pantalla y hacer los ajustes necesarios para ello.

Errores en la creación de Wireframes

Debe ser claro, sin diseño gráfico y sin color (salvo el estrictamente necesario, por ejemplo para indicar que un elemento está seleccionado, para lo cual recomiendo usar gamas de grises)

Yo suelo trabajar con prototipos funcionales, pues la experiencia me dice que con ellos el cliente comprende mejor la interacción de las páginas y los cambios posteriores son menores. Por tanto yo siempre recomiendo que su funcionamiento se asemeje lo máximo posible al futuro funcionamiento del portal, lo cual además ofrece una herramienta de gran valor para el equipo de desarrollo.

Desde mi punto de vista, el mayor error es no presentar personalmente el prototipo al cliente. Es cierto que debe ser autoexplicativo y que las notas son importantes para que después puedan revisarlo, pero siempre es necesario explicar cada una de las decisiones que se han tomado y el por qué de las mismas.

Liz Danzico propone sus propias recomendaciones en "The Devil's in the Wireframes"

¿Cómo planteo un Wireframe para una aplicación RIA?

Recomiendo el artículo "The Guided Wireframe Narrative for Rich Internet Applications" de Andrés Zapata. También es recomendable "Crear prototipos de Rich Internet Applications en Visio" de Usolab.

¿Qué herramienta utilizo para realizar un Wireframe?

Depende de cual manejes con mayor fluidez. Puedes usar Illustrator, Photoshop, PowerPoint, Visio, OpenOffice Draw, Omnigraffe, etc.

Pero sí que existen herramientas específicas para realizar Wireframes, yo recomiendo Axure.

Axure permite crear de manera muy sencilla un prototipo funcional (mostrar y ocultar paneles, cambiar el estado o el contenido de los elementos, por ejemplo de los campos de un formulario; crear zonas fijas reaprovechables por todo el prototipo, etc.)

También permite exportar un documento Word con los pantallazos de la aplicación y sus partes para redactar el análisis funcional. Podéis conocer las novedades de Axure 6 en el artículo: Novedades Axure 6

Recursos para Wireframes

Stencil Kit de Yahoo que proporciona objetos predefinidos en diferentes formatos.
"Recopilación de plantillas y stencils para prototipar" en deinterfaz.
"Templates" de Information Architecture for Designers
"Tools" de The Information Architecture Institute
"Using Wireframes: Templates" de Strange Systems
"Visio Wireframe Stencil" de UrlGreyHot
"Graph Paper" (plantillas para wireframes y story boards) en Konigi
Kit para prototipado en papel de la consultora australiana Information & Design, listos para ser impresos
Stencils más "hand-drawn" para tus wireframes
Wireframes para móvil
I love wireframes: recopilatorio
960.gs Grid Based Prototypes
Quince
Wiki "Resources for designing and building mobile applications and website"
Libreria para prototipar aplicaciones de Android

Fuentes a consultar

"La diagramación en la arquitectura de información" de Rodrigo Ronda León
"Prototipado" de SIDAR
"Un vocabulario visual para describir arquitectura de información y diseño de interacción" de Jesse James Garrett
"Using Wireframes" de Strange Systems
“Wireframes for the Wicked”, de Michael Angeles, Nick Finck and Donna Spencer
"Wireframes: recopilación de enlaces" en No lo entiendo
"An Introduction to Using Patterns in Web Design" de Ryan Singer
"Representing Data in Wireframes" de Dan Brown
"The Devil's in the Wireframes" de Liz Danzico
"The Zen of Wireframes" de Gene Smith
"Wireframes" de Nelson Rodríguez-Peña:Rediseño: Wireframe de Portada y Rediseño: Wireframe de Página Interior
"The Guided Wireframe Narrative for Rich Internet Applications" de Andrés Zapata
"Crear prototipos de Rich Internet Applications en Visio" de Usolab
"Wireframes" de Drey Alexander Consulting
MPIu+a. Una metodología que integra la Ingeniería del Software, la Interacción Persona-Ordenador y la Accesibilidad en contexto de equipos de desarrollo multidisplinares del Doctor Granollers
Ejemplos: Storyboard navegacional, diagramas de flujo, etc.
DIseño en HCI, Universidad Carlos II de Madrid
Close Photoshop and Grab a Pencil: The Lost Art of Thumbnail Sketches, de Joshua Johnson
Wireframes Magazine, blog especializado.

Artículos relacionados:

Imprescindibles... (7)

2008-03-06T12:46:00.001+01:00

Enlaces recomendables sobre la revisión de la usabilidad de un sitio:

10 Principios para un Diseño Web Efectivo en Estándares y Accesibilidad

39 sugerencias para hacer un sitio usable en Accesibilidad, Usabilidad y Estándares Web

Autodiagnóstico de Usabilidad del Laboratorio Aragonés de Usabilidad

Checklist del Laboratorio Aragonés de Usabilidad

Plantilla Análisis Heurístico v1.2 de Torres Burriel.

Guía de Evaluación Heurística de Sitios Web de NSU

Guía para evaluación experta de Joaquín Márquez Correa

Manual de las técnicas de Evaluación y testing de Usabilidad de WebUsable.com

"Com es realitza una avaluació heurística per experts", PROYECTO MUPA-UOC - Metodología de usabilidad para aplicaciones de la Universitat Oberta de Catalunya

Taller de Usabilidad de la Semana de la Ciencia

Usability Toolkit

Imprescindibles... (6)

2008-02-28T09:05:00.000+01:00

Sobre Quirks Mode o modo "chapucero".

[Si no sabes lo que es, lo explicaba en: Plantilla Base XHTML]

Problemas con AJAX y Quirks Mode de anieto2k

Modo quirks vs. modo estándar en Mozilla Developer Center

Internet Explorer 8.0 modo super estándar de anieto2k

Las 75 directrices de accesibilidad de Jakob Nielsen

2008-02-22T12:23:00.000+01:00

El Nielsen Norman Group publicó estas Navidades de forma gratuita su informe "Beyond ALT Text: Making the Web Easy to Use for Users with Disabilities"

El documento no tiene desperdicio y su lectura es muy recomendable, por no decir obligatoria. Para aquellos a los que les dé pereza leerse las 148 hojas en inglés, incluyo un breve resumen del estudio que realizaron y las conclusiones que extrajeron en forma de 75 directrices de accesibilidad.

[Ir directamente a las 75 Directrices de accesibilidad]

Introducción

El estudio de dividió en dos:

uno cuantitativo con 60 participantes en el que se midió el éxito, los errores y los tiempos en realizar unas tareas encomendadas (del tipo "compra el último CD de Janet Jackson en www.target.com" o "encuentra la Tª media de Dallas (Texas) en Enero), y dentro del cual se incluyó una valoración subjetiva de la satisfacción de los usuarios mediante un cuestionario oral.

uno cualitativo con 44 personas, en el que se recogieron los comentarios y los comportamientos de los usuarios al realizar las tareas encomendadas.

Salvo el grupo de control, todos los demás participantes tenían alguna de estas discapacidades (no se incluyen otras como las discapacidades auditivas o cognitivas o ceguera al color):

Baja visión: estos usuarios utilizaron magnificadores de pantalla o bien aumentaron el tamaño de texto del navegador.

No visión: estos usuarios utilizaron lectores de pantalla (como Jaws, Windows Eyes o IBM Homepage Reader) y en el estudio cualitativo además algunos usaron dispositivos Braille.

Discapacidad motora: fundamentalmente parálisis cerebral (1), y también algún usuario con discapacidad del habla.

Todos los participantes estaban trabajando al menos desde hacía un año, pues se pensó que el resultado del estudio sería así más útil para los desarrolladores orientados a dar soporte a las empresas.

Los participantes eran usuarios intermedios o expertos, puesto que tenían al menos 3 años de experiencia en el dispositivo de asistencia que utilizaban, y una media de 3 años de experiencia en Internet, que usaban todos los días o varios días a la semana.

Su edad estaba entre los 20 y los 64, hombres y mujeres por igual, de EEUU y Japón.

La mayoría usaba conexión de alta velocidad e Internet Explorer "por ser el navegador por defecto de su equipo".

Propuesta para que los desarrolladores validen sus páginas

Para ponerse en la piel de los tres grupos de usuarios participantes (y sin que esto pueda sustituir a un test de usuarios serio o a un estudio de usabilidad/accesibilidad), el estudio propone:

Simular las dificultades motoras: desconectando el ratón o colocándose unos guantes de horno.

Simular la no visión: utilizar un lector de pantalla apagando el monitor o con los ojos vendados.

Simular la baja visión: utilizar unas gafas con celo y después utilizar un magnificador de pantalla o subir el tamaño de letra del navegador.

Conclusiones del estudio: 75 Directrices de accesibilidad

No abandone las reglas del buen diseño que ya conoce

1. Siga las reglas básicas de un buen diseño

Destaca cuatro normas del buen diseño:

Diseño centrado en el usuario

Escribir concisamente evitando el lenguaje comercial superfluo

Ofertar menos opciones, incluyendo sólo las más importantes

No incluir gráficos y sonidos sólo por contar con ellos

Gráficos y multimedia

2. Reducir al mínimo el uso de imágenes

Argumenta que reducir el número de imágenes permite aumentar la velocidad de carga de las páginas y disminuye el ruido superfluo, puesto que un exceso de imágenes dificulta comprender la finalidad del sitio.

3. Dar a todos los gráficos (incluso a los banners publicitarios) nombres que sean comprensibles y que transmitan de verdad lo que el gráfico es y hace.

Utilice el atributo ALT para describir brevemente las imágenes, y el atributo LONGDESC para describirlas minuciosamente

El contenido del ALT debe ser conciso y sencillo: su objetivo es transmitir lo que es la imagen, no describirla.

4. Nunca difuminar las imágenes para indicar no disponibilidad

Se refiere por ejemplo a una imagen que funciona como enlace, de tal manera que cuando el enlace no está disponible se indica difuminándola o poniéndola borrosa.

Es mejor idea eliminar por completo los gráficos cuando no están disponibles.

5. Cuando gráficos contengan información útil, también proporcione la información en texto

Cuando los gráficos comprenden información útil, los usuarios deberían ser capaces de acceder a dicha información en formato HTML.

6. Dé a los usuarios maneras alternativas de obtener la información contenida en cualquiera de los gráficos que se encuentren

Muchas veces los usuarios encuentran el gráfico y suponen que es la única fuente de información, pues les pasa desapercibido que hay una versión textual de la misma información. Para que sea más fácil de encontrar debe ir junto al gráfico o vinculado al mismo y no, por ejemplo, en una sección completamente diferente del sitio.

7. No utilice una imagen en miniatura de la página de su sitio para utilizarla como gráfico (o botón) en otra página

Se refiere a utilizar imágenes que son una captura de la pantalla, en pequeñito, a modo de enlace para ir a otra página.

Cuando ves la página en su totalidad los tamaños relativos hacen que este uso sea perfectamente claro. Sin embargo, para los usuarios que utilizan magnificadores de pantalla, a 6x de aumento, las imágenes en miniatura de una página adquieren un aspecto real.

8. Al hacer uso de gráficos, elija siempre imágenes claras y nítidas.

Las fotos de textos también plantean problemas, ya que las letras tienden a hacerse borrosas a medida que se amplían.

9. Facilite a los usuarios la posibilidad de saltarse cualquier elemento multimedia, aplicación Java o Flash.

En especial cuando producen sonidos, pues los usuarios que usan un lector de pantalla necesitan silencio para escucharlo.

10. No cree automáticamente una versión sólo-texto de su sitio.

No es aconsejable hacer una versión solo-texto, lo recomendable es hacer accesible la versión gráfica, pues crear y mantener dos versiones del sitio es costoso y lleva mucho tiempo.

Sin embargo, hay empresas que utilizan el grafismo y los elementos multimedia para transmitir cierta impresión, sentimiento o emoción de su sitio. En estos casos sí que puede estar justificado una versión sólo-texto, en cuyo texto se intente transmitir el mensaje que se envía a través del multimedia.

Pero hay que tener en cuenta que esa versión sólo-texto debe ser accesible, y que la página principal desde la que se accede a esta versión también debe ser accesible.

Pops-ups, rollovers, nuevas ventanas y menús en cascada

11. Evite el uso de ventanas emergentes.

Incluye ejemplos de lo mucho que desorientan y desconciertan las ventanas emergentes a las personas que utilizan lectores de pantalla o magnificadores así como a las personas con discapacidad motora.

12. En el caso de hacer uso de cuadros de diálogo en pop-ups, asegúrese de que la acción por defecto es la más "perdonable".

Ciertos usuarios pulsaban "Enter" sin más en estas ventanas, sin pararse a leer o a comprobar si la acción por defecto era Aceptar o Cancelar, de manera que se encontraban inadvertidamente instalándose, por ejemplo, Flash Player, algo que no querían ni esperaban hacer.

13. Evite abrir nuevas ventanas del navegador.

Al igual que las ventanas emergentes, las nuevas ventanas generan desconcierto en el usuario. Comprobaron que a menudo las ventanas quedaban ocultas unas por otras y cuando el usuario trataba de hacer clic en el botón "Atrás" del navegador éste parecía no funcionar, y por lo general terminan cerrando el navegador para recuperarlo por completo.

14. Si abre nuevas ventanas del navegador, siempre proporcione una forma sencilla de volver a la página principal del sitio principal.

A veces las personas que utilizan lectores de pantalla no se dan cuenta de que hay varias ventanas del navegador abiertas a la vez. Si un sitio abre automáticamente una ventana y el botón "Atrás" falla, buscan un vínculo para acceder a la página principal.

15. No confíe en los rollover de texto (tooltip) para transmitir información.

Se refiere a cualquier texto que aparece cuando te pones encima de un elemento.

Asegúrese de suministrar la misma información de otra forma más fácilmente accesible, pues muchos usuarios no llevan a cabo la acción o no pueden acceder a la misma. Pone ejemplos de los problemas que les surgen a los usuarios de magnificadores de pantalla.

16. Evite utilizar menús en cascada (menús que se despliegan)

Son muy difíciles de usar para usuarios con magnificadores de pantalla y con problemas motores, pues es necesario poder arrastrar y sostener el ratón mientras se hace clic con precisión. Estos menús son difíciles de seguir, además, con un magnificador de pantalla, hay zonas importantes del mismo que caen fuera de la pantalla y no son visibles.

Enlaces y botones

17. Limite el número de enlaces en una página

Recomienda un máximo de 20 enlaces por página.

Los usuarios con lectores de pantalla no pueden echar un vistazo a la página, deben escucharla. Algunos usuarios no piensan en hacer clic hasta que no han escuchado toda la página, otros hacen clic en el primer vínculo que creen que es el adecuado.

Aquellos que no utilizaban el ratón por problemas motores acababan agotados de moverse con las teclas de desplazamiento cuando la página era muy grande y había muchos enlaces.

18. Evite pequeños botones y enlaces con texto minúsculo

Es difícil y agotador acertar a pulsarlos para las personas con problemas motores.

19. Deje espacio entre los enlaces y botones

Para las personas con problemas motores o problemas de baja visión, el espacio entre los botones y entre los enlaces es sumamente importante, pero también para los usuarios videntes, cuando los enlaces están muy juntos es muy fácil errar y pulsar otro por equivocación.

20. Evite el uso de imágenes como el único método de enlazar a otra página.

También se debe evitar decirles a los usuarios instrucciones del tipo "haga clic en la imagen de arriba".

21. Asegúrese de que los comandos importantes aparecen con sus propios vínculos exclusivos.

Es necesario comprobar que con un lector de pantalla hay pausas suficientes que permitan identificar los enlaces importantes.

22. Subraye todos los enlaces

Es la manera más clara de identificar los enlaces cuando la pantalla se magnifica.

23. Crear vínculos dentro del texto cuando tenga sentido. Utilice los botones adicionales sólo cuando sea necesario.

Es algo muy típico que en las noticias de un sitio, en vez de que el enlace a la noticia sea el texto, se ponga un botón "Ir". Se ha de evitar esta práctica.

Organización de las páginas

Una buena organización de la página no significa lo mismo para una persona que ve que para una persona que utiliza un lector de pantalla. Para esta última una buena organización será por ejemplo que lo primero que se lea sea el título de la página y los primeros enlaces que se dicten sean los de búsqueda, saltar navegación o versión sólo-texto.

El estudio propone que estos enlaces se hagan mediante imágenes invisibles al comienzo de la página; serían invisible para los videntes y disponibles para los lectores de pantalla y los navegadores que proporcionen listados de enlaces.

24. Confirmar al inicio de la carga de la página principal el nombre de la compañía.

Este dato debe ser el primero que lea el lector de pantalla, así sus usuarios, que no pueden ojear la página, no dudarán acerca de a dónde han entrado. Para ello es necesario ponerle un "title" significativo a la página y un "alt" al logotipo de la parte superior de la página.

25. Confirmar al inicio de la carga de una página en qué página se está.

Los usuarios con un lector de pantalla necesitan saber que al hacer clic en un vínculo este les ha traído a donde pensaban, por ello es necesario, por ejemplo, poner un "title" significativo a todas las páginas.

26. No asociar la palabra "página principal" o "home" con el logotipo de su empresa si planea volver a utilizar el mismo gráfico en todas las páginas.

Cuando se usa el logo como enlace a la página principal, el "alt" de esta imagen no debería ser "página principal de XXXX" sino "Enlace a la página principal de XXXX", para que los usuarios de lectores de pantalla no piensen que es el título de la página sino un enlace.

27. Reducir la necesidad de desplazarse con scroll.

Escrolar es muy lento y tedioso para los usuarios que usan magnificadores de pantalla.

28. Cuando los usuarios deban hacer una elección, ponga todas las posibilidades en la misma zona.

Hay que buscar un equilibrio entre poner los enlaces y botones muy juntos o muy distantes.

29. Cuando los usuarios deben hacer una elección, adviértales de la elección mediante, por ejemplo, un texto del tipo "Selección de pedido", e infórmeles de la cantidad de opciones que tienen.

30. Haga un diseño de páginas consistente

Utilice un método de navegación coherente, que no se deba reaprender en cada página. Esto será especialmente útil para los usuarios con magnificadores de pantalla.

31. Considere la posibilidad de utilizar un enlace "Saltar Enlaces" para que los usuarios puedan saltar los enlaces o elementos de navegación.

Esto les evita a los lectores de pantalla tener que escuchar una y otra vez todos los enlaces de las barras de navegación superiores y laterales.

32. Elija una dirección Web de su sitio simple e informativa, y mantenga esa URL en el campo de la dirección de la página después de la carga.

Puesto que es lo primero que muchos usuarios con lectores de pantalla escuchan, es importante elegir una dirección que transmita el nombre de la organización o del sitio.

Páginas

33. Evite las "páginas portada" previas a la página de inicio de un sitio, haga que la primera página que la gente vea sea la página que mejor describe la compañía y el sitio.

Las páginas y los clic extras no sólo no ayudan a la eficiencia del sitio, sino que muchas veces conducen a la frustración de los usuarios que usan lectores de pantalla.

34. Incluya tan sólo los pasos y las páginas necesarias

Campos y formularios

35. Limite la cantidad de información que el formulario requiere; recoja sólo el mínimo necesario.

Los formularios demasiado largos suponen problemas para los usuarios con discapacidad motora, puesto que les cuesta rellenar los campos. Además, los usuarios que usan magnificadores de pantalla pierden fácilmente el contexto al intentar escrolar la página.

36. Ponga las etiquetas de texto de los campos muy cerca de los campos que les corresponden.

Cuando se magnifica la pantalla lo más probable es que los usuarios no vean la etiqueta que acompaña al campo, y asumirán que le corresponde el texto más cercano.

37. No indique los errores del formulario simplemente destacando un texto en rojo o amarillo.

Sin duda esta práctica es una ayuda, pero los usuarios que usan lectores pantalla o dispositivos Braille no tienen manera de saber que el texto es rojo. Estos textos también son difíciles de leer con la pantalla magnificada, más aun cuando a menudo se invierten los colores para ver las cosas mejor.

Propone que cuando haya errores se muestren sólo los campos con errores.

38. No confíe sólo en el asterisco para indicar que un campo es necesario.

Algunos usuarios que usaban lectores de pantalla se preguntaban qué significaba la continua repetición de la palabra "asterisco" y si sería un error del lector.

El estudio propone reforzar este indicador con otro, como por ejemplo poner el texto en negrita. También propone poner los campos obligatorios todos juntos al principio del formulario y evitar solicitar información que no sea necesaria.

39. Asegúrese de que el orden de tabulación es lógico.

Muchos usuarios usan el tabulador para desplazarse por los campos del formulario. Además, los usuarios de lectores de pantalla son también dependientes del orden lógico de los campos, puesto que es así como el lector de pantalla les lleva a través del formulario.

40. Haga coincidir el orden de tabulación con la disposición visual de los elementos cuando sea posible.

41. Apile los campos en una columna vertical.

Los campos en una única columna son mucho más fáciles de rellenar para los usuarios con baja visión que utilizan magnificadores de pantalla.

42. Ofrezca campos de entrada estándar para los números de teléfono.

Cuando se ofrecen varios campos para rellenar el teléfono la gente se confunde. Es mejor usar un único campo (o dos, uno para el prefijo y otro para el número) pero no más, especialmente si no se etiquetan.

43. En aquellas páginas que tenga un formulario con un único campo de entrada o selección, poner el botón lo más cerca posible del campo.

Muchos usuarios de magnificadores de pantalla no se dan cuenta de que deben desplazarse y encontrar el botón, esperan, por ejemplo, que ocurra algo al seleccionar en la combo una opción.

44. En los formularios, ponga el botón "submit" lo más cerca posible del último campo.

A menudo los usuarios de baja visión no encuentran el botón "enviar", más aún si se separa del formulario por ejemplo mediante una línea. También es importante que la tecla "Intro" envíe el formulario.

45. Ponga cualquier instrucción relativa a un campo en particular antes del campo y no después.

Los usuarios de lectores de pantalla necesitan escuchar las instrucciones acerca de los campos antes de llegar a la caja de entrada.

46. Considere cuidadosamente cuánto tiempo se pone de tope para hacer una acción como por ejemplo rellenar un formulario.

Textos

47. Seleccione colores de texto con buen contraste

48. No use un tamaño de fuente muy pequeño para el texto de la página

El usuario debe poder controlar el tamaño del texto, para lo cual deben tener un tamaño relativo (%, em). Se aconseja que por defecto no tenga un tamaño menor al equivalente de 11 puntos, puesto que así las letras seguirán siendo legibles cuando se magnifiquen.

49. No use texto pequeño o sutil (por ejemplo un gris rebajado) para los encabezados y categorías.

50. Cree siempre un buen contraste entre el color del texto y el color de fondo de la página

Cuando no es así muchos usuarios optan por invertir los colores o verla en monocromo.

51. No se base en una imagen de fondo para crear el contraste con el texto.

Muchos usuarios con baja visión desactivan la visualización de imágenes en el navegador. Asegúrese de que cuando desactiva las imágenes el color de texto sigue teniendo suficiente contraste con el color de fondo de la página.

52. Pruebe los colores y fuentes de su sitio con un magnificador de pantalla

Hasta a x6. El azul por defecto de los enlaces es poco legible a muchos aumentos, el negro sin embargo sí es legible. El texto de las imágenes tampoco debería estar suavizado para que se pueda leer magnificado.

53. Asegúrese de que es posible magnificar su sitio.

Utilice tamaños de fuente relativos (%, em), no absolutos (px, pt)

54. Escriba de forma concisa y elimine el texto superfluo

Tanto a los usuarios de lectores de pantalla como a los de magnificadores de pantalla les molesta escuchar información inútil.

55. Si el nombre de la compañía o el texto en general presenta abreviaturas y acrónimos, dígale al lector de pantalla como pronunciarlo mediante las etiquetas <abbr> y <acronym>.

56. Replantéese la forma en la que usa los paréntesis y los asteriscos.

La utilización de estos signos de puntuación distraen a menudo a la gente.

Búsquedas

57. Ofrezca un motor de búsqueda que perdone los errores de ortografía.

Google, por ejemplo, ofrece recomendaciones de búsqueda con las palabras escritas correctamente.

58. No base únicamente la capacidad de búsqueda de un sitio en la interfaz de navegación.

Ofrezca siempre una herramienta de búsqueda.

59. Coloque la caja de búsqueda donde los usuarios la esperan encontrar, no en una zona inesperada.

Se espera en la parte superior derecha o en la esquina inferior izquierda.

60. Describa claramente los resultados de la búsqueda.

Indique de inmediato cuántos resultados ha habido, ponga un título para cada uno y no sólo una url.

61. Avise a los usuarios cuando no han introducido nada en la caja de búsqueda

Si un usuario escribe algo sin tener la caja de búsqueda seleccionada, creerá haber escrito algo y que los resultados de la búsqueda se corresponden con lo que ha escrito, sin embargo no tendrán nada que ver con lo que intentaba buscar porque se buscó con la caja vacía.

62. No presente el ranking de relevancia de los resultados de la búsqueda en una tabla.

El número que precede al enlace y que indica el ranking, si va en una columna confunde a los usuarios de lectores de pantalla y a los de magnificadores de pantalla, pues no lo contextualizan. Si los resultados se dan en orden, el número es redundante y no es necesario.

Comercio electrónico

63. Describa minuciosamente las imágenes de los productos que el sitio vende como si no hubiera imágenes.

En la compra de ropa, objetos, etc. la imagen es muy importante, por eso las personas que usan lectores de pantalla necesitan una descripción detallada para decidirse a comprar.

64. Ayude a los usuarios a seguir comprando después de haber añadido algo al carrito, dándoles una forma de llegar de nuevo a donde estaban.

65. Coloque los botones de "añadir a la cesta de compra" o "realizar pedido" cerca de los elementos a comprar.

Si se colocan en la parte superior o inferior de la pantalla pueden pasar desapercibidos.

También debería ser evidente para el usuario cuando se ha añadido algo a la cesta.

66. Tenga en cuenta a los clientes internacionales seleccionando cuidadosamente los términos que utiliza.

Por ejemplo es más fácil de comprender "Buy" que "Checkout".

Aconseja usar el atributo "lang" cuando se utilicen frases o palabras en otro idioma, de este modo se advierte a los usuarios de lectores de pantalla que la palabra que van a oír está en otro idioma.

Tablas y frames

67. Evite el uso de tablas para maquetar un sitio.

Las tablas se esperan para organizar la información, cuando se utilizan para fijar el tamaño de la página crean confusión a los usuarios que utilizan lectores de pantalla y dispositivos Braille.

68. Evite el uso de tablas muy grandes sin motivo. Si debe usarlas, considere proporcionar la información también en formato texto.

Con tanta información en una tabla es difícil que los usuarios de lectores de pantalla, de sistemas Braille o de magnificadores de pantalla den sentido a todo y lo recuerden.

69. En especial en las tablas, no use gráficos para indicar un dato como por ejemplo el estado, es mejor usar texto.

Es difícil recordar la leyenda o recordar que la presencia o ausencia de una imagen significa algo en particular.

70. Asegúrese de que las listas alfabéticas visuales siguen estando en orden alfabético cuando son leídas por un lector de pantalla.

Si la lista está dispuesta en una tabla puede ser que el orden no coincida.

71. Incluya un resumen ("summary") en todas las tablas

El usuario con un lector de pantalla no puede echar un vistazo a la tabla para hacerse una idea de lo que contiene, el resumen de la tabla cumple esta función.

72. Antes de usar columnas en el diseño considere cómo se le mostrarán a un usuario con un magnificador de pantalla.

Las páginas organizadas en columnas se prestan a confusión cuando no se tiene el contexto de toda la pantalla, como les ocurre a los usuarios con magnificadores de pantalla.

73. Describa todos los frames.

Los frames son una de las causas más comunes de problemas de accesibilidad, especialmente con lectores de pantalla y dispositivos Braille.

Pero si los usas, al menos indica cuántos frames hay en una página y proporciona un resumen de cada uno en el "longdesc", de este modo los usuarios son conscientes de los contenidos generales antes de decidirse a escuchar un frame entero.

Acerca de los marcos comenta que si se usa el aumento de fuente del navegador, este sólo se aplica al marco seleccionado, y es muy tedioso ir seleccionando cada marco para subir el tamaño de fuente.

Confianza, estrategia e imagen de la compañía

Cuando los usuarios se encuentran con sitios de difícil acceso es poco probable que vuelvan y están menos satisfechos con esa empresa u organización. Por el contrario, las empresas y organizaciones con sitios accesibles generan más confianza.

74. Proporcione en su sitio un servicio de atención al cliente cuyas personas tengan unos básicos conocimientos de los problemas de accesibilidad.

75. Do not refer to people in wheelchairs as wheelchairs or screen reader users as screen readers.

NOTAS:

(1) La parálisis cerebral es la incapacidad de controlar completamente la función motora, en especial el control muscular y de la coordinación. Esta discapacidad motora supera en número de afectados a cualquier otra discapacidad de desarrollo incluida la epilepsia, el autismo o el síndrome de Down. Se manifiesta mediante:

Opresión o espasmo muscular

Movimiento involuntario

Perturbación en el andar o la movilidad

Percepción y sensación anormales

Alteración visual, auditiva o del habla

(Volver al texto)

Imprescindibles... (4)

2008-01-30T11:57:00.001+01:00

Artículos muy recomendables sobre Usabilidad

Cómo diseñar una web según Eye-Tracking de Estándares y accesibilidad

10 Malentendidos sobre Interacción y Usabilidad de Estándares y accesibilidad

Columnas, anchos de línea y legibilidad de Juan Carlos García en Úsalo

La diagramación en la arquitectura de información de Rodrigo Ronda León en NSU

Best Practices for Web Form Design de Luke Wroblewski

Principios del Diseño Universal o Diseño para Todos en SIDAR

Los usos de Nielsen. Para una crítica de la ideología de la usabilidad de Carlos A. Scolari en Medialab

Una recopilación de buenos textos sobre diseño de interacción en 2007 de Torres Burriel

XHTML: Elementos, etiquetas y atributos

9 principios para un buen diseño web

Cajeros más usables

2007-12-10T09:20:00.001+01:00

Ayer, por fin, el sol no me molestó al sacar dinero del cajero automático.

Disciplinas relacionadas con la usabilidad

2007-11-15T14:58:00.009+01:00

[D]

Pulsa en la imagen para verla a tamaño real (580 Kb) o descárgatela en formato PDF (600 Kb)

Notas:

(1) Era imposible incluir en el esquema todas las técnicas y herramientas o todos los métodos de evaluación, por ello nombro los que me parecen más relevantes. Se puede ampliar información sobre estos puntos en las referencias.

(2) Son bien recibidos todos los comentarios que realicen puntualizaciones o propongan mejoras en el esquema, aunque creo que es muy dificil que todos estemos de acuerdo en un mismo esquema.

Me parecen muy interesantes las siguientes propuestas:

Astrolabio:

Kicker Studio:

Neospot:

The Difference (and Relationship) Between Usability and User Experience

Referencias

"Rueda de la Experiencia de Usuario" de Francisco Tosete Herranz
"The Elements of User Experience" de Jesse James Garrett
"Usabilidad para principiantes" de Juan Carlos García
"¿Qué es la experiencia de usuario?" de Daniel González Vilalta
"La experiencia del usuario" de Yusef Hassan y Francisco J. Martín
"Diseño de Experiencias de Usuario" de Peter Morville
"Diseño de Interfaces y Usabilidad" de Eduardo Mercovich
"Arquitectura de la información y usabilidad en la web" de Ricardo Baeza-Yates, C. Rivera y Javier Velasco
"Lecturas introductorias sobre usabilidad y IHC" de la Universidad Rafael Landívar
"Pensar primero" de Daniel Mordecki
"Recopilación de Métodos de Usabilidad" de Sidar
"Sumario de Técnicas para la Evaluación y Testing de la Usabilidad" de Webusable
"La usabilidad como metodología para el desarrollo de una aplicación" de Olga Carreras
"Representing Data in Wireframes" de Dan Brown
"Wireframes" de Nelson Rodríguez-Peña
"Un vocabulario visual para describir arquitectura de información y diseño de interacción" de Jesse James Garrett
"Glosario: Terminología relacionada con la usabilidad y la accesibilidad" de Olga Carreras

Usable y accesible

Modificación de la Ley 34/2002 que obliga al consentimiento expreso del usuario para el uso de cookies

Web Usability Guidelines–Directrices de usabilidad web

Índice

HHS Guidelines

247 directrices de usabilidad web de Userfocus

Nielsen Norman Group Guidelines

Swedish National Guidelines for Public Sector Websites

Sirius

Australia Government Usability Checklist

Guía para el Desarrollo de Sitios Web del Gobierno de Chile

Usability Guidelines del MIT (Massachusetts Institute of Technology)

Directrices de usabilidad para sitios web del Estado colombiano

Otros enlaces de interés

Estándares formales de usabilidad y su aplicación práctica en una evaluación heurística

Índice

Qué es un estándar

Tipos de estándares

Estándares formales de usabilidad

Orientados al proceso: ISO 9241 e ISO 13407

ISO 9241 Ergonomics of Human System Interaction

ISO 13407:1999. Human centred design processes for interactive systems

Orientados al producto: ISO 9126 e ISO 14598

ISO 9126 Software engineering — Product quality

ISO 14598 Information technology — Software product evaluation

Ventajas y desventajas de la definición de usabilidad como proceso y como producto

ISO 25000 (SQUARE): unificación y revisión de los estándares ISO/IEC 9126 e ISO/IEC 14598

Aplicación práctica de los estándares formales en la evaluación heurística de la web

WUEP (Web Usability Evaluation Process)

Otras propuestas

Mplu+a

WebQEM

WQM (Web Quality Model)

QUIM (Quality in Use Integrated Measurement)

Referencias

Arquitectura de información. Fundamentos

¿Qué es la arquitectura de información?

Tipos de necesidad de información

Componentes o anatomía de la arquitectura de información

Sistemas de organización

Sistemas de etiquetado

Consejos y recomendaciones

Orientaciones metodológicas

Sistemas de navegación

Tipos de sistemas de navegación

Recomendaciones

Sistemas de búsqueda

Recomendaciones

Vocabularios o lenguajes documentales

Tipos de lenguajes documentales

Bibliografía

Artículos relacionados

Últimos anteriores

Servicios relacionados

Cuando los problemas de usabilidad afectan a la vida real de las personas

Documentos que recomiendo conocer(7)

Usabilidad

Libros

Recursos

Móvil

Estudios

Accesibilidad

Libros

Recursos

Accesibilidad en documentos de Office

Navegadores

SEO y marca

Enlaces en los que perderse (5)

User Experience

Information Architecture

Maquetación

Documentos que recomiendo conocer(6)

Guías e informes

Cursos, revistas y libros online

Otros

Imprescindibles (14)

Usabilidad

Diseño y maquetación

Accesibilidad

Varios