La Ingeniería de la Usabilidad y de la Accesibilidad aplicada al diseño y

desarrollo de sitios web

Jesús Lorés, Toni Granollers

Departament Informàtica

Universitat de Lleida

Campus de Cappont

25001 Lleida

correo-e: jesus@eup.udl.es; tonig@diei.udl.es

Tabla de Contenidos

1. INTRODUCCIÓN __________________________________________________ 1 1.1. ALGUNAS CARACTERÍSTICAS DE LOS SITIOS WEB_______________________ 2 1.2. USABILIDAD DE LOS SISTEMAS INTERACTIVOS_________________________ 3 1.3. ACCESIBILIDAD DE LOS SISTEMAS INTERACTIVOS ______________________ 5

2. MODELO DE PROCESO DE LA INGENIERÍA DE LA USABILIDAD Y LA ACCESIBILIDAD ______________________________________________________ 17

2.1. INTRODUCCIÓN _______________________________________________ 17 2.2. LA INGENIERÍA DEL SOFTWARE ___________________________________ 17 2.3. DISEÑO CENTRADO EN EL USUARIO _______________________________ 19 2.4. LA INGENIERÍA DE LA USABILIDAD ________________________________ 21 2.5. BUSCANDO UN MODELO DE PROCESO_______________________________ 22 2.6. MODELO DE PROCESO DE INGENIERÍA DE LA USABILIDAD Y DE LA

ACCESIBILIDAD________________________________________________________ 23 2.7. APLICACIÓN DEL MODELO DE PROCESO A LA WEB _____________________ 24 2.8. ESQUEMA DEL MPIU+A_________________________________________ 24

3. ANÁLISIS DE REQUISITOS ________________________________________ 35 3.1. ESTUDIO DE LA AUDIENCIA Y DE LA PLATAFORMA ____________________ 35 3.2. DISEÑO PARA LA DIVERSIDAD ____________________________________ 40 3.3. NECESIDADES DE LOS USUARIOS __________________________________ 42 3.4. PROTOTIPADO EN LOS REQUISITOS_________________________________ 45 3.5. EVALUACIÓN EN LA FASE DE REQUISITOS ___________________________ 47

4. DISEÑO __________________________________________________________ 49 4.1. ANÁLISIS DE TAREAS JERÁRQUICO (HTA)___________________________ 49 4.2. ARQUITECTURA DE LA INFORMACIÓN (AI) __________________________ 51 4.3. ORGANIZACIÓN DE LA PÁGINA____________________________________ 62 4.4. DISPOSICIÓN _________________________________________________ 64 4.5. ESCRIBIR PARA LA WEB _________________________________________ 66 4.6. PROTOTIPADO EN EL DISEÑO _____________________________________ 72

5. IMPLEMENTACIÓN ______________________________________________ 79

6. LANZAMIENTO __________________________________________________ 81 6.1. PRELANZAMIENTO_____________________________________________ 81 6.2. LANZAMIENTO________________________________________________ 82

7. MÉTODOS DE EVALUACIÓN GENERALES _________________________ 93 7.1. GRUPO DE DISCUSIÓN DIRIGIDO (FOCUS GROUP)______________________ 93 7.2. EVALUACIÓN HEURÍSTICA _______________________________________ 94 7.3. RECORRIDO DE LA USABILIDAD PLURAL ____________________________ 96 7.4. ANÁLISIS DE LOGS _____________________________________________ 97

8. REFERENCIAS __________________________________________________ 101

1

1. Introducción

El Modelo de Proceso de la Ingeniería de la Usabilidad y de la Accesibilidad (MPIu+a) [1][2] que presentamos en este libro especifica una metodología que guía al equipo de desarrollo de aplicaciones interactivas con altos niveles de usabilidad y accesibilidad.

El mero hecho de conseguir aplicaciones que cumplan con los objetivos funcio-nales para las que han sido propuestas y desarrolladas no es una tarea fácil. Conse-guir, además, que estas aplicaciones cumplan con todos los principios que permiten calificar a las mismas como “usables” y/o “accesibles” para todas las personas es aún un proceso más laborioso que sin duda fracasará si no se realiza siguiendo un disciplinado y riguroso procedimiento.

El MPIu+a, que veremos en el punto 2, tiene sus cimientos, por una parte, en la Ingeniería del Software (IS) y, por otra, en la disciplina de la Interacción Persona-Ordenador (IPO), que contribuye –entre otras– con toda una sólida base de cono-cimiento y un conjunto de técnicas y experiencias conocidas para el diseño de in-terfaces centradas en sus usuarios. Pretende ser una herramienta de trabajo para ayudar metodológicamente a los equipos de desarrollo. No especifica ni el uso de un determinado lenguaje de programación, ni ninguna tecnología específica, ni ningún factor que pueda determinar la aplicación, sino todo lo contrario, está pen-sado para todo tipo de aplicaciones y tecnologías –actuales y futuras–. En definiti-va, es independiente de los dispositivos y la tecnología.

El modelo además se adapta a la multidisciplinariedad de los equipos de desa-rrollo de entornos interactivos que utilizan aproximaciones del Diseño Centrado en los Usuarios (DCU) [36]. En un estudio publicado en Ainda.info [3], web española especializada en usabilidad, se describe que sólo un 18% de los especialistas en usabilidad y Arquitectura de la Información son ingenieros, el resto son, por orden, periodistas, diseñadores, sociólogos, humanistas y psicólogos, hecho que restringe el uso excesivo de métodos formales informáticos que impedirían su uso tanto en miembros no informáticos como de los propios usuarios que deben implicarse en el proceso.

Gran parte de este documento centra los esfuerzos en explicar la aplicación del MPIu+a durante el desarrollo de aplicaciones o sitios web, entornos para los que

2

deben tenerse en cuenta ciertas características que les hacen diferentes de cualquier otro tipo de aplicaciones.

La validación basada en proyectos reales es la base del trabajo de nuestro grupo de investigación GRIHO1. El mencionado modelo de proceso ha sido aplicado para desarrollar los siguientes sitios web (algunos de ellos en desarrollo):

Web de la entidad y del centenario del Centro Excursionista de Lleida (http://www.lleida.org/cel, http://www.lleida.org/cel100), web dinámica en JSP de la Asociación Interacción Persona-Ordenador (http://www.aipo.es), web dinámica en ASP y Macromedia Flash de la infancia del ayuntamiento de Lleida (http://www.paeria.org/infancia), web del congreso de Interacción 2004 (http://griho.udl.es/i2004), web en XML del programa de doctorado en Interacción Persona-Ordenador (http://griho.udl.es/ipo/doct), web de la estantería virtual de la Universidad de Lleida y web del área de servicios sociales del ayuntamiento de Lleida (http://www.paeria.org/serveispersonals), que cubren un amplio espectro de tecnologías y temáticas.

1.1. Algunas características de los sitios web

El perfil de los usuarios de las aplicaciones informáticas ha cambiado mucho desde la aparición de Internet; el abanico de posibilidades se ha ampliado enorme-mente. La inmediatez y globalización hacen que el perfil genérico del usuario de un sitio web sea diferente: existe una gran diversidad de conocimientos, necesidades y formas de acceder a los servicios.

Con la aparición y enorme explosión de los sistemas web apareció un nuevo conjunto de conceptos, como los enlaces (links), las páginas (web), los navegadores (browsers), la inmediatez, la audiencia, la arquitectura de la información, la nave-gación, etc., que se han ido añadiendo a nuestro vocabulario diario. Las concepcio-nes tradicionales de distancia y tiempo de repente desaparecen para generar un espacio dónde no existe ni la separación espacial y ni la temporal.

Los sitios web constituyen hoy día la mejor interfaz de integración de servicios, a la vez que conecta a las personas u organizaciones formando las denominadas redes sociales [4].

Hay que tener en cuenta que más del 50% del código se dedica a la interfaz [5], aunque en el paradigma web este factor se incrementa enormemente (hay un gran número de sitios web en el que el 90% de los mismos no son más que elementos visuales puramente estéticos, o sea, elementos de la interfaz).

1 GRIHO es el nombre del grupo de investigación en Interacción Persona-Ordenador de la Universi-dad de Lleida. http://www.griho.net.

3

1.2. Usabilidad de los sistemas interactivos

El concepto usabilidad de un sistema software, introducido por J. Nielsen [6], tiene dos componentes principales, una hace referencia al aspecto funcional del sistema –las acciones u operaciones que el sistema realiza– y otra a cómo los usua-rios pueden usar dicha funcionalidad, siendo esta segunda la que principalmente-nos interesará en documento.

Los factores principales que deben considerarse al hablar de usabilidad son la facilidad de aprendizaje, la efectividad de uso y la satisfacción con que las perso-nas son capaces de realizar sus tareas gracias al uso del producto con el que está trabajando, factores los cuales descansan en las bases del Diseño Centrado en el Usuario [36][37].

El grado de usabilidad de un sistema interactivo es un aspecto relacionado con la interfaz de usuario2 que es inversamente proporcional al tiempo que malgastan los usuarios de dicho sistema intentando averiguar el alcance de qué hace o dónde esta una determinada funcionalidad.

Y la definición “formal” del término usabilidad que el estándar ISO 9241-11 nos propone es:

La medida en la que un producto se puede usar por determinados usuarios para conseguir objetivos específicos con efectividad, eficiencia y satisfacción en un contexto de uso especificado.

1.2.1. ¿Por qué es importante la usabilidad de los sitios web?

Todos somos conscientes de que la web se está convirtiendo en un elemento clave, tanto en el desarrollo de las empresas como de las instituciones, ofreciendo información y una amplia gama de servicios a través de la misma.

A pesar de ello, la web (o Internet) sigue sin ser indispensable para un extensa parte de la población y conseguir que se conviertan en internautas y/o futuros clien-tes on-line dependerá directamente de su facilidad de uso, es decir, de su usabili-dad.

Dicha usabilidad aporta el enfoque imprescindible para que las páginas de una empresa o entidad tengan el suficiente atractivo para que el visitante no sólo se quede y las visite, sino que regrese en el futuro. Para ello el diseño de las páginas, sus funciones, mensajes y contenidos deben estar diseñados e implantados para que lo pueda usar cualquier persona.

2 La interfaz de usuario de un sistema consiste de aquellos aspectos del sistema con los que el usuario entra en contacto, físicamente, perceptivamente o conceptualmente. Los aspectos del sistema que están escondidos para el usuario se denominan la implementación [38].

4

1.2.2. Problemas de usabilidad en la web

Aunque la web está basada en principios de interfaces relativamente simples –enlaces, botones, texto, menús, cajas de texto y gráficos–, los problemas de usabi-lidad serios son bastante frecuentes [5]:

• Problemas de percepción humana: Aparecen cuando, por ejemplo, un con-junto de páginas está diseñado de acorde como la información está físicamente almacenada en lugar de cómo ésta debe ser presentada para su comprensión.

• Frustrantes problemas de navegación: Desorientan al navegante motivando preguntas como ¿dónde estoy ahora?, ¿cómo he llegado aquí? o ¿qué debo hacer para...? son demasiado frecuentes. Todo ello se agrava cuando hay ambigüedad en la comprensión de los enlaces o no se siguen los estándares de los elementos de navegación.

• Deben tenerse en cuenta aspectos importantes acerca de la memoria huma-na. Si los usuarios tienen que recordar un elevado número de ítems seguro que alguno de ellos se perderá, agravándose si además deben recordar ciertos ítems de una página a otra.

• Gran parte de la información que las webs muestran provienen, cada vez más, de información almacenada en bases de datos, conllevando inconvenientes de usabilidad para el usuario final derivados de la no concordancia de la información mostrada con los datos reales que la base de datos asociada dispone —problema derivado de la sincronización de las páginas.

• Contenidos pobres, la lentitud en las descargas, los enlaces rotos, las op-ciones y menús confusos, el abuso de ventanas emergentes, la “moda de la letra muy pequeña”, etc.

1.2.3. Beneficios que aporta la usabilidad a un sitio web

Los beneficios que la usabilidad puede aportar a la implementación de sitios web deben mirarse desde varias ópticas distintas:

Desarrollo:

- Reducción de los costes de producción, mantenimiento y soporte.

- Disminución de los costes de uso.

- También produce menores costes de desarrollo al establecerse pautas generalizadas de diseño, reutilizables en diferentes aplicaciones depar-tamentales (uso interno) y incremento de ventas.

Usuario:

- Permiten una mayor productividad y una reducción del esfuerzo.

5

- La confianza que produce la facilidad de uso facilitará su “fideliza-ción” (el visitante volverá y posiblemente recomendará nuestro sitio a sus conocidos y amistades).

- Si no es usable disminuyen la salud, bienestar y motivación y pueden incrementar el absentismo.

Comercial:

- Permite un mejor marketing

- Garantiza aplicaciones más competitivas

- Menor soporte al cliente

- Facilidad en sustituciones y rotación de personal (ventas).

1.3. Accesibilidad de los sistemas interactivos

Internet ofrece acceso a todo tipo de recursos, servicios, culturas, educación, etc. Pero, ¿es realmente Internet una herramienta para todos?. La respuesta, evidentemente, es negativa. Su desarrollo está manifestando que una vez más esta-mos tropezando de nuevo con la misma piedra al haber trasladado al mundo virtual problemas ya detectados en el mundo real.

Tenemos la obligación de evitar que se repitan los errores que suponen las ba-rreras arquitectónicas habituales en las calles de nuestros pueblos y ciudades tan-to en Internet como en cualquier otro sistema interactivo.

Accesibilidad significa proporcionar flexibilidad para acomodarse a las necesi-dades de cada usuario y a sus preferencias y/o limitaciones.

Los seres humanos son diferentes entre sí y en un mundo ideal todas las interfa-ces de usuario deberían acomodarse a esas diferencias de tal modo que cualquier persona fuera capaz de utilizarlas sin problemas, sin que nadie se vea limitado en el uso de algo por causa de esas diferencias personales. Es necesario evitar diseñar solamente atendiendo a características de grupos de población específicos, impo-niendo barreras innecesarias que podrían ser evitadas prestando más atención a las limitaciones de estos [39].

Las capacidades y aptitudes de todas las personas difieren de unas a otras. Exis-ten grupos de población que tienen alguna limitación funcional que les impide ac-ceder a facilidades que desearían, deberían o tienen el derecho de acceder. Por poner algún ejemplo ilustrativo, pertenecen a los grupos mencionados personas con baja o nula visión y/o audición, con discapacidades motrices que les impiden el libre movimiento de sus manos o reducidos niveles de comprensión.

6

El poder de la Web está en su universalidad. Un aspecto esencial es el acceso para todo el mundo sin importar la discapacidad (Tim Berners-Lee, W3C Director and inventor of the World Wide Web).

Figura 1_1: Personas con distintos niveles de discapacidad que también tienen el derecho de acceder a los servicios de los sistemas interactivos.

El uso de Internet, por poner el ejemplo actual más paradigmático, permite el acceso a todo tipo de recursos, servicios, cultura, educación, etc. pero, es Internet una herramienta para todos, la respuesta, evidentemente, es no. Su desarrollo está manifestando el hecho de que las barreras arquitectónicas habituales en nuestras calles se manifiestan también en este medio. No podemos quedarnos con una acti-tud pasiva ante este desagravio hacia una parte importante de la población.

Un estúdio realizado por el O.C.A.E.S. (Observatorio Complutense de Accesibi-lidad a la Educación Superior – Universidad Complutense de Madrid) realizado a finales del año 2002 [40] pone de manifiesto la baja (o nula) adaptación a las dis-capacidades de las páginas web tanto de las universidades (solo el 18% son accesi-bles) y de las administraciones locales españolas (0%) [41]:

7

Figura 1_2: Niveles de accesibilidad de los sitios web de las universidades y las administraciones locales españolas a finales del año 2002.

El factor de la accesibilidad a los sistemas interactivos por parte de los humanos es tan importante que recientemente el estándar ISO ha publicado una especifica-ción técnica enmarcada en las especificaciones ergonómicas para que sirva de guía para el diseño de interfaces de ordenador para las personas [42]

Esta Especificación Técnica insiste en la necesidad de considerar los aspectos sociales y legislativos para eliminar aquellas barreras que impiden que personas con necesidades especiales puedan participar en las actividades de la vida diaria incluyendo cualquier tipo de servicio, producto o información.

Es importante destacar que la accesibilidad se proporcionada por una combina-ción de hardware y software: el primero proporciona los mecanismos físicos que permiten salvar ciertas discapacidades y el segundo proporciona la manera eficaz de acceder a las funcionalidades e informaciones para estos dispositivos y a otros programas (por ejemplo un navegador web). La Especificación Técnica menciona-da hace referencia solo a los aspectos de la componente software.

Existen mecanismos y herramientas que se adaptan al ordenador a la vez que existen estudios y guías para desarrollar aplicaciones (preferentemente enfocadas a la Web) que permiten facilitar el uso a las personas con discapacidades.

1.3.1. Accesibilidad de las interfaces

Las barreras que los usuarios discapacitados y personas de edad avanzada en-cuentran para interactuar con sistemas interactivos están relacionadas principal-mente con la interfaz de usuario e incluyen las dificultades físicas para manipular los dispositivos y las barreras cognitivas para entender los procedimientos y la navegación. Los estudios realizados con usuarios evidencian la necesidad de inter-faces adaptables que permitan el control de dispositivos y servicios a través de sistemas ínteroperables integrados en un entorno inteligente [43].

8

Accesibilidad física

Las interfaces estándar se basan en el uso de dispositivos de interacción más comunes: el teclado y el ratón para la entrada de datos y la pantalla (y ocasional-mente los altavoces para señales audibles) para la salida. El uso de estos dispositi-vos requiere determinadas capacidades físicas. La entrada demanda precisión y coordinación motora, además de coordinación visual-motora para el manejo del dispositivo apuntador. La salida requiere capacidad visual y ocasionalmente auditi-va.

Los seres humanos presentan gran diversidad de discapacidades posibles, de manera que una fracción importante de la población no alcanza los mínimos nece-sarios para manejar estos dispositivos de manera adecuada. Esto puede ocurrir por diversas causas tales como el envejecimiento, discapacidad o por estar realizando simultáneamente otra tarea (como conducir o trabajar). Este último caso se ha in-troducido recientemente al conjunto de necesidades especiales debido a la enorme expansión de los dispositivos ubicuos, que pueden ser utilizados mientras el usua-rio se desplaza o realiza actividades diversas.

Accesibilidad cognitiva

Las interfaces regulan el diálogo usuario-aplicación mediante una serie de pro-cedimientos que incluyen las órdenes disponibles, los procedimientos de navega-ción, etc. Estos elementos se encuadran en un modelo de la tarea a realizar que suele ser explicitado como una metáfora de la misma actividad realizada sin la ayuda del ordenador. Para conseguir un uso adecuado la persona debe comprender los procedimientos, las metáforas, la navegación, etc., lo que en definitiva depende del ajuste entre la “visión del mundo” que tiene el usuario y la que tiene la aplica-ción.

También las capacidades cognitivas de los usuarios son muy diversas. Además del envejecimiento y las discapacidades cognitivas, aspectos tales como el uso de un idioma diferente de la lengua materna o la disminución de la atención al realizar otra tarea simultáneamente pueden influir en la capacidad cognitiva, por lo que también es necesario tener en cuenta esta diversidad a la hora de diseñar métodos de interacción.

Diseño Universal o Diseño para Todos

Usualmente las interfaces se diseñan pensando en una persona estándar con to-das las capacidades físicas y cognitivas, lo que frecuentemente deja fuera a los colectivos de personas con “necesidades especiales”. El diseño universal, conocido también cómo diseño para todos, tiene como objetivo diseñar interfaces que no presenten barreras de accesibilidad. Para ello es necesario que la interfaz admita el uso de dispositivos de interacción alternativos, adecuados a las capacidades físicas de cada usuario.

9

Respecto de la necesidad de tener en cuenta la diversidad de capacidades cog-nitivas, es necesario, por ejemplo, limitar la necesidad de memorizar datos, utili-zar diversas metáforas adecuadas a las diversas culturas y experiencias previas de los usuarios y producir sistemas de navegación coherentes e intuitivos (podemos observar que diseñar de acuerdo a estándares favorece el diseño para todos).

No sólo se trata pues de accesibilidad para personas con discapacidad, se trata del 'Diseño para Todos'. Realizando los cambios requeridos por las personas con discapacidad se beneficia a todos.

Los ejemplos incluyen a personas con módems lentos que desactivan las imáge-nes, personas que navegan por la Web mientras conducen un automóvil e incluso médicos que acceden a la Web mientras sus manos están ocupadas con una ciru-gía.

El diseño universal es una estrategia el objetivo de la cual es la realización y la composición de los diferentes entornos y productos accesibles y comprensibles, a la vez que usables, en todo el mundo, en la mayor o menor medida y de la forma más independiente y natural posible, sin la necesidad de adaptaciones ni soluciones especializadas de diseño.

Existen unos principios de diseño universal (ver recuadro a la derecha) redacta-dos por un grupo de expertos que sirve de guía para evaluar la incorporación de la accesibilidad en el diseño de los sistemas interactivos. Estos criterios que definen el diseño utilizable para todos no tienen en cuenta aspectos cómo la estética, el coste, la seguridad o el respeto a la diversidad, aunque deben tenerse en cuenta durante el proceso de diseño.

En el escenario Europeo existe el grupo de trabajo que forma parte de ERCIM denominado “User Interfaces for All” que sistemáticamente promueve la realiza-ción proactiva de principios de Diseño para Todos en el área de la IPO. Éste grupo trata el desarrollo de interfaces de usuario de aplicaciones interactivas y servicios telemáticos propiciando el acceso y la usabilidad universales para todos los usua-rios potenciales, incluyendo personas con diferencias culturales, educativas, de entrenamiento y de empleo, usuarios de ordenadores noveles y expertos, los muy pequeños o muy jóvenes, y personas con diferentes tipos de discapacidades, todos ellos interactuando con diferentes plataformas tecnológicas en contextos de uso distintos [44].

1.3.2. Una necesidad general

Cuando en nuestra ciudad se adaptan las infraestructuras urbanas (aceras, auto-buses, etc.) con rampas para facilitar el acceso a personas que van con sillas de ruedas no solo estas se ven favorecidas con el cambio. Las personas que llevan los cochecitos de sus hijos, los carteros con sus carros, las personas mayores que tienen dificultades para subir y bajar aceras se benefician agradablemente de estas mejo-ras.

10

Una aplicación, página o sitio Web es accesible si se han tenido en cuenta los requisitos para que pueda ser utilizada por cualquier persona.

Las personas que puedan acceder a dichas funcionalidades pueden ser desde personas con discapacidades claramente identificadas y reconocidas, aun así el colectivo humano que realmente se beneficia de dicha accesibilidad incluye:

- A las personas de edad avanzada. Cada día que pasa la población co-rrespondiente a este sector aumenta, aumentando, por tanto, el número de usuarios que carecen del 100% de sus capacidades físicas y/o men-tales.

- A las personas con dispositivos lentos o antiguos. La tecnología avan-za a un ritmo vertiginoso y no todo el mundo dispone de los medios necesarios para, o simplemente no quiere, readaptarse constantemente a los nuevos cambios. Existe además zonas de población (núcleos pe-queños, de montaña, etc.) donde la tecnología llega con bastante retar-do respecto a lo que lo hace en las grandes concentraciones humanas.

- A las personas con dispositivos muy modernos. Caso contrario al ante-rior, los dispositivos recién aparecidos encuentran multitud de dificul-tades debido a que las infraestructuras no suelen estar preparadas para dichos mecanismos.

- A personas con discapacidades temporales. Pongamos el ejemplo de una persona diestra a la que han operado del codo derecho y le han in-movilizado dicha extremidad durante unas semanas, esta persona tiene discapacidad temporal con el uso de los dispositivos habituales cómo son el teclado y el ratón.

- Y, evidentemente, a las personas con cualquier discapacidad de las re-conocidas cómo tales.

Hemos visto que en el desarrollo de aplicaciones accesibles pasa lo mismo que pasa con las infraestructuras urbanas. La mejora se realiza para favorecer el acceso a un determinado colectivo que está en clara minoría, pero el resultado es una me-jora de dicho acceso para un número mayor de personas.

Por su parte, la Tecnología de la Rehabilitación3, que ha desarrollado múlti-ples dispositivos para las personas con diversas limitaciones motoras, visuales, etc.,

3 La denominación de Tecnología de la Rehabilitación proviene de traducir la expresión anglófona Assistive Technology. En principio parece que esta traducción no es la más acertada y debería ser algo así cómo Tecnología Asistencial pero se adopta Rehabilitación porque asistiva o asistencial es un término sin ningún arraigo en castellano y porque en el ámbito que tratamos la palabra rehabilita-ción se refiere tanto a la "recuperación" de las capacidades perdidas cómo al soporte para la "habilita-ción" a las personas que no pueden recuperarlas. Ejemplos correspondientes a esta tecnología son las pantallas y lectores en sistema Braille, el software amplificador de pantalla o los dispositivos de “eye tracking”.

11

ha tenido una enorme influencia en la IPO. Muchos de los dispositivos de interac-ción no estándares que hoy en día son utilizados por un público más amplio fueron inicialmente concebidos para personas con discapacidad [45]. Sistemas de capta-ción de señales eléctricas del cerebro [46] constituyen algún ejemplo de este tipo de interfaces pensadas para personas con discapacidad que seguramente en un futuro tendrán aplicaciones más amplias.

El siguiente cuadro nos resume los tipos de discapacidades y los colectivos, re-gular o temporalmente, afectados:

TABLA 1_1: NO SOLO LAS PERSONAS CON NECESIDADES ESPECIALES NECESITAN LA AC-CESIBILIDAD. EL CUADRO MUESTRA ALGUNAS DE LAS SITUACIONES EN QUE PERSONAS SIN

NECESIDADES ESPECIALES PUEDEN NECESITAR INTERFACES ACCESIBLES.

Tipo de discapacidad

Personas afectadas Situaciones que provocan esta disca-pacidad a otras personas

Tecnologías de Rehabili-tación

Sin Visión - ciegos - Ojos ocupados (:conducción) - En la oscuridad

- Lectores de pantalla

Poca Visión - con limitaciones visuales (pérdida parcial de la visión, deficiencias en la percepción de los colores, …)

- Visor pequeño - Ambiente con humo

- Pantallas más grandes - Fuentes mayores - Aumento del contraste - Ampliadores de pantalla

Operable sin poder oír

- sordos - entornos muy ruidosos - oídos ocupados - silencio forzado (bibliotecas)

- “show sounds” (presen-tar la información auditiva en formato visual)

Oído limita-do

- “duros de oído” (dificultad para distinguir cambios de frecuencia sonora o de locali-zación de sonidos)

- entornos ruidosos (discoteca)

- “show sounds”

Impedimento físico

- con funciones motoras limitadas (problemas de coordinación, debilidad, dificultad de movimiento en extremidades)

- vestir vestidos especiales (astronau-tas) - Dentro de un vehículo que se balan-cea

- “eye tracking” - teclados en la pantalla - reconocedores de voz - dispositivos apuntadores alternativos

Impedimento cognitivo

- con discapacidades cogniti-vas (dificultad al recibir información, de procesarla y de comunicación) - hiperactivos - disléxicos

- situación de distracción - situaciones de pánico - bajo la influencia del alcohol

- texto resaltado (para problemas de lectura) - reconocedores de voz (para problemas de escri-tura)

Operable sin poder leer

- ciertas discapacidades cogni-tivas

- de visita en un país del cual se desconoce el idioma - olvido de las gafas de lectura

- internacionalización del software - texto resaltado

1.3.3. Motivos para diseñar de forma accesible

La accesibilidad es vista hoy en día cómo una dificultad añadida al diseño de aplicaciones. No obstante muchas son las razones que podemos encontrar para diseñar de forma accesible.

La accesibilidad constituye:

12

- Un beneficio social. El creciente uso de Internet en todas las áreas de la sociedad hace que la accesibilidad represente un paso adelante para la independencia de las personas con discapacidades. La accesibilidad en las páginas Web incrementa las posibilidades laborales y educativas a la vez que permite a las personas con discapacidades participar en acti-vidades cotidianas cómo leer el periódico o realizar la compra semanal.

- Un aspecto regulado por la ley. Muchos países cuentan con legislación sobre la accesibilidad de las aplicaciones informáticas que prestan ser-vicios públicos. Además, también se están desarrollando normativas y códigos éticos y de buenas prácticas para la industria y el comercio electrónicos. En España nos incumben:

o Norma UNE EX 139802

o La Iniciativa eEurope

o InfoXXI: El Plan Info XXI responde a los objetivos estableci-dos en la iniciativa e-Europe, aprobada en el Consejo Extraor-dinario de Lisboa, en marzo de 2000, y con su correspondiente Plan de Acción aprobado en Feira, en junio de ese mismo año, y ayudará a que España esté entre los países europeos más avanzados en el terreno de las Tecnologías de la Información y la Comunicación y el nuevo entorno de la Sociedad de la In-formación.

El Plan de Acción Info XXI para el desarrollo de la Sociedad de la Información se articula en tres grandes líneas:

el impulso del sector de las Telecomunicaciones y las Tecnologías de la Información, completando la libera-lización y favoreciendo la competencia

la potenciación de la Administración electrónica

el acceso de todos a la Sociedad de la Información

o Declaración de Madrid: el "Congreso Europeo sobre las Per-sonas con Discapacidad" nace con el objetivo de impulsar nuevas políticas comunitarias que permitan promover un nue-vo modelo de plena inclusión social de las personas con disca-pacidad en Europa. En este contexto se enmarca la "Declaración de Madrid"; declaración en la que se plasma la visión del Congreso con el objeto de proporcionar un marco conceptual de acción durante el Año Europeo en el ámbito de la Unión Europea a escala nacional, regional y local.

Principios: (1) La discapacidad es una cuestión de derechos huma-nos, (2) Las personas con discapacidad desean la igualdad de opor-

13

tunidades y no la caridad, (3) Las barreras sociales llevan a la dis-criminación y a la exclusión scial, etc.

o LEY 34/2002, de 11 de julio, de Servicios de la Sociedad de la Información y de Comercio Electrónico (LSSICE): publicada en el B.O.E. el 12 de julio. Entrando en vigor a los tres meses de su publicación (o sea a partir del 12 de octubre de 2002). Sobre accesibilidad la ley dice, en sus disposiciones finales:

Quinta. Accesibilidad para las personas con discapacidad y de edad avanzada a la información proporcionada por medios elec-trónicos.

Uno. Las Administraciones Públicas adoptarán las medidas nece-sarias para que la información disponible en sus respectivas pági-nas de Internet pueda ser accesible a personas con discapacidad y de edad avanzada de acuerdo con los criterios de accesibilidad al contenido generalmente reconocidos antes del 31 de diciembre de 2005. Asimismo, podrán exigir que las páginas de Internet cuyo di-seño o mantenimiento financien apliquen los criterios de accesibi-lidad antes mencionados.

Dos. Igualmente, se promoverá la adopción de normas de accesi-bilidad por los prestadores de servicios y los fabricantes de equi-pos y software, para facilitar el acceso de las personas con discapacidad o de edad avanzada a los contenidos digitales.

- Un beneficio para todos los usuarios. Cómo ya se ha comentado ante-riormente el beneficio de la accesibilidad no repercute solamente a las personas que realmente lo necesitan sino que otros colectivos también se ven favorecidos con estas adaptaciones.

- Un beneficio a nivel tecnológico. El diseño accesible fomenta el uso de diversas utilidades de los sistemas operativos y de los navegadores (no se apuesta únicamente por los dos más utilizados).

- Un beneficio económico. La accesibilidad ofrece el potencial necesario para que las organizaciones y empresas adquieran nuevos clientes y nuevos mercados.

Un par de ejemplos estadísticos reales ilustra que el número de posibles clientes no es ni mucho menos insignificante:

- El estudio “Americans With Disabilities” realizado por U.S. Census Bureau el año 1997 [11] revela que el 19.7% de los norteamericanos padece algún tipo de discapacidad y el 12.3% padece discapacidades severas.

14

- Otro estudio similar Español del año 1999 titulado “Encuesta sobre Discapacidades, Deficiencias y Estado de la Salud 1999” realizado por en Instituto Nacional de Estadística revela que el número de españoles con discapacidades asciende al 9% del total de la población. [47].

1.3.4. No es lo mismo Accesibilidad que Usabilidad

Aunque son conceptos que dada su importancia deberían ser tratados conjunta-mente y con alta prioridad en el desarrollo de aplicaciones software, los conceptos de usabilidad y de accesibilidad disponen de significado y características bien dife-renciadas.

Veamos estas diferencias a partir de los cuatro casos que pueden darse en cual-quier aplicación:

a) Ni usable ni accesible. Desafortunadamente este es el caso más habitual en todas las aplicaciones interactivas. Este caso recoge aquellas aplicaciones el diseño de las cuales no ha tenido en cuenta para nada los parámetros de accesibilidad para personas con discapacidades y podríamos decir que solo son accesibles para las personas “normales” carecen de la usabilidad necesaria para utilizarlas satisfacto-riamente.

b) Usable y no accesible. En este caso será solo usable para quienes puedan ac-ceder a sus funcionalidades, o mejor dicho será usable para la población para la cual ha estado implementada la aplicación. Este caso es aquel en que para el desa-rrollo de la aplicación se han tenido en cuenta y aplicado las técnicas de la usabili-dad.

c) Accesible sin ser usable. Este caso puede ser comparado con el primero en el que una parte de la población podía acceder a las funcionalidades y se encontraba con problemas de usabilidad. Aquí lo que cambia es que el abanico de población que notará esta falta de usabilidad será mayor puesto que al ser accesible el número de personas que podrá acceder a sus servicios y/o funcionalidades es mayor.

d) Usable y accesible. Indudablemente este es el caso ideal y, evidentemente, el más escaso. Representa la idea básica del diseño universal, donde además de favorecer el acceso a todo el mundo lo hace de manera usable.

Algunos autores consideran que la Accesibilidad es una parte de la Usabili-dad y, otras que es la Usabilidad la que forma parte de la Accesibilidad. En cualquier caso, es claro que la accesibilidad favorece la usabilidad de una aplicación y el crecimiento del negocio: Incrementando la Cuota de Mercado y la Audiencia alcanzada, Mejorando la Eficiencia del sitio, Transmitiendo una imagen de Responsabilidad Social, Cumpliendo la legislación y normati-va [Emamnuelle Gutiérrez y Restrepo (SIDAR)]

15

1.3.5. W3C, WAI.

El World Wide Web Consortium, o simplemente W3C, (Consorcio para la World Wide Web) fue creado el octubre del 1994 para conducir a la World Wide Web a su máximo potencial desarrollando protocolos de uso común que promocio-nasen su evolución y asegurasen la interoperabilidad. Constituyen un consorcio industrial internacional, alojado por el Massachusetts Institute of Technology La-boratory for Computer Science (MIT/LCS) (Laboratorio de Ciencias de la Compu-tación del Instituto de Tecnología de Massachusetts), en los E.E.U.U.; el Institut National de Recherche en Informatique et en Automatique (INRIA) (Instituto Na-cional de Investigación en Informática y Robótica) en Europa (Francia); y la Keio University Shonan Fujisawa Campus (Universidad Shonan Fujisawa de Keio) en Japón.

El consorcio está liderado por Tim Berners-Lee, Director y creador de la World Wide Web, y por Jean-François Abramatic, como Presidente. El W3C esta formado por Organizaciones Miembro, sin ánimo de lucro, que trabajan en la comunidad internacional para desarrollar especificaciones y programas informáticos de refe-rencia, que son distribuidos gratuitamente a lo largo de todo el planeta.

El compromiso del W3C de encaminar la web a su potencial máximo incluye proporcionar un alto grado de accesibilidad para las personas con discapacidades. El grupo interno de trabajo permanente conocido cómo Web Accesibility initiative (WAI), Iniciativa para la Accesibilidad de la Red, en coordinación con asociacio-nes y organizaciones de todo el mundo, persigue la accesibilidad de la web a través de cinco actividades complementarias: tecnología, normativa, herramientas (de validación y reparación), educación y formación, e investigación y desarrollo.

Normativas

Cómo se ha mencionado en el párrafo anterior la WAI ha desarrollado un con-junto de normativas con el claro objetivo de proporcionar una serie de pautas que ayuden a los diseñadores de aplicaciones web a conseguir que estas sean accesi-bles. Se redactaron guías para:

- La web: Web Content Accessibility Guidelines (WCAG): se trata de un conjunto de recomendaciones para que las páginas web sean accesibles para todos con la ayuda de la tecnología existente.

- Las herramientas de diseño: Authoring Tool Accessibility Guidelines (ATAG): recomendaciones para que las herramientas de diseño de pá-ginas web sean accesibles para todos, así como, el resultado generado por ellas.

- Los Agentes de Usuario: User Agent Accessibility Guidelines (UAAG): recomendaciones para que los navegadores y programas multimedia

16

sean accesibles para todos y para que estas herramientas puedan coope-rar mejor con los dispositivos de tecnología asistiva.

Cada punto de verificación tiene asignado uno de los tres niveles de prioridad.

- Prioridad 1: hace referencia a los puntos de verificación “obligato-rios”, aquellos que el desarrollador tiene que satisfacer; si no, algunos grupos de personas serán incapaces de acceder al contenido de un sitio web.

- Prioridad 2: el desarrollador debería satisfacerla; sin ello alguien en-contrará muchas dificultades para acceder a la información. Satisfacer este punto salvará importantes barreras para acceder al contenido web.

- Prioridad 3: el desarrollador puede satisfacerla; de lo contrario, algu-nas personas hallarán dificultades para acceder a la información. Ello mejoraría notablemente el acceso a los documentos web.

La especificación tiene tres "niveles de adecuación" con estas directrices:

- El nivel "A": se satisfacen todos los puntos de prioridad 1.

- El nivel "AA": se satisfacen todos los puntos de prioridad 1 y 2.

- El nivel "AAA": se satisfacen todos los puntos de prioridad 1, 2 y 3.

17

2. Modelo de proceso de la Ingeniería de la usabilidad y la accesibilidad

2.1. Introducción

En el capítulo anterior hemos aprendido que significan los factores usabilidad y accesibilidad en relación al desarrollo de sistemas interactivos. Hemos visto razo-nes convincentes que demuestran la necesidad de incorporar grandes dosis de usa-bilidad y de accesibilidad a todos los sistemas interactivos que desarrollemos.

No obstante si conseguir que las aplicaciones que cumplan con los objetivos funcionales para las que han sido propuestas y desarrolladas no es una tarea fácil, conseguir, además, que estas aplicaciones cumplan con todos los principios que permiten etiquetar a las mismas como “usables” y que estas sean “accesibles para todas las personas” sin discriminación es un proceso aún más laborioso que difí-cilmente podrá alcanzarse si no se realiza siguiendo un disciplinado y riguroso procedimiento de ingenieria.

En este capítulo veremos las diferentes aproximaciones existentes con las cuales se han abordado durante los últimos tiempos el desarrollo de sistemas software y una propuesta concreta de un modelo de proceso explícitamente diseñado para ser capaz de integrar equipos interdisciplinares de profesionales de diferentes áreas de conocimiento para realizar dichos desarrollos.

2.2. La Ingeniería del software

La Ingeniería del Software, IS, es una disciplina que trata todos los aspectos de la producción de software. Sus principios suelen estar basados en leyes de la física, la biología o las matemáticas, pero en el caso de la ingeniería del software estos principios están basados en la experiencia vivida por muchas personas a lo largo de los años.

La situación de la ingeniería del software en los años 80 sólo permitía una ar-quitectura física y lógica restringida a lo que ofrecían los grandes fabricantes de software y hardware (sobre todo IBM, que suministraba ambos componentes con-siguiendo así una dependencia total del cliente). Estos sistemas eran sometidos a un

18

mantenimiento estresante y, normalmente, indocumentado, que desembocaba en una degradación de la aplicación y, por ende, en un servicio deficiente para el usua-rio.

Situaciones como ésta y el modelo de desarrollo adoptado hasta entonces, el llamado code-and-fix, cuya traducción correcta al español sería ‘codifica y corrige’, donde se codifica y luego se piensa en los requisitos, diseño, pruebas y manteni-miento dieron origen a un reconocimiento de la crisis del software, que desembocó en el nacimiento de la ingeniería del software como disciplina.

Desde entonces, el desarrollo de software va unido a un ciclo de vida compuesto por una serie de etapas que comprenden todas las actividades, abarcando desde el momento en que surge la idea de crear un nuevo producto software, hasta aquel en que el producto deja definitivamente de ser utilizado por el último de sus usuarios.

Los ingenieros de software deben entonces adoptar un enfoque sistemático y organizado de su trabajo y usar herramientas y técnicas apropiadas dependiendo del problema que van a solucionar, las restricciones de desarrollo y los recursos disponibles.

2.2.1. Ciclos de vida en el desarrollo software

Uno de los modelos estructurados más básicos, y que sirve como bloque de construcción para los demás modelos de ciclo de vida, fue el modelo en cascada (véase figura 2_1). En la actualidad, el modelo en cascada es sustituido por los modelos iterativos e incrementales asociados con la tecnología más reciente orien-tada a objetos, aunque en el fondo el modelo en cascada sigue siendo la base de todos los procesos.

Figura 2_1: modelo en cascada.

19

El inconveniente del modelo en cascada es la dificultad de permitir cambios después de que el proceso haya empezado.

Los métodos actuales de la ingeniería de software, estimulan el uso de esquemas de desarrollo más flexibles de tipo espiral, que permiten ir hacia atrás y hacía ade-lante, rompiendo un poco las barreras entre cada etapa. Se estimula mucho el desa-rrollo incremental (véase figura 2_1) en el ciclo de vida: no lo hagas todo de una vez. Estos esquemas también promueven el prototipaje. Es necesario darle al cliente una idea de cómo va a funcionar su sistema, implementando en prototipos aquellos requerimientos de mayor riesgo y poder brindar al ciclo de desarrollo, flexibilidad para la modificación de los requerimientos iniciales.

Figura 2_2: modelo incremental.

Estos cambios de paradigmas en los modelos y procesos de desarrollo de soft-ware imponen también un cambio de paradigma en la interacción usuario-sistema en sus diferentes niveles, que provoca el origen de una metodología que apunta a asegurar una interacción usuario-sistema más natural (cómoda) y eficiente (produc-tiva), así como facilitar la comprensión del sistema por parte de nuevos usuarios y eliminar inconsistencias en la interacción.

Del estudio de las metodologías de la Interacción Persona-Ordenador (IPO), surge uno de los paradigmas que más ha beneficiado al desarrollo del software, el denominado Diseño Centrado en el Usuario (CDU) [36][37].

2.3. Diseño Centrado en el Usuario

Hay una larga tradición de ergonomía e ingeniería de factores humanos. Butler [61] nos recuerda que estudios sobre rendimiento humano y técnicas de diseño para el control de máquinas se convirtieron ya en campo de una intensa actividad de

20

investigación aplicada durante la Segunda Guerra Mundial, cuando la complejidad de los equipos empezó a sobrepasar los límites humanos para una operación segura. Por este camino, la aeronáutica llegó en los años sesenta a considerar a los seres humanos como un componente del sistema técnico total, hasta culminar su evolu-ción en el concepto de “diseño centrado en el piloto”.

Por su parte, el interés por la interacción de personas con sistemas de informa-ción arranca en los años cincuenta y sesenta, pero su punto de partida industrial nace con el ordenador personal, a finales de los setenta y primeros de los ochenta. La máquina Star, de Xerox, y más tarde la estación Lisa, de Apple, materializan, aunque con poco éxito comercial, la metáfora del escritorio, en forma de las prime-ras interfaces más o menos intuitivas pensadas para usuarios no informáticos. La informática personal revoluciona el mundo de la informática y pone silenciosamen-te en marcha un movimiento de cambio de métodos y sistemas centrados en la tec-nología, hacia métodos y sistemas centrados en el usuario.

La actual sofisticación alcanzada en las soluciones informáticas demanda un mejor software. Los usuarios, acostumbrados, gracias a Internet, a obtener, probar y comparar diversos sistemas y herramientas de software, se han convertido en clientes más exigentes y críticos: esperan un alto grado de elaboración en las Inter-faces Gráficas de Usuario (GUI), así como en el código y en el funcionamiento del sistema en sí mismo.

Esta reflexión histórica nos ayuda a hacer una reducción simplista de las diver-sas formas de entender el problema y plantear una solución; cada una de ellas ha marcado el tiempo y la época en la que evolucionaron.

La primera, denominada, Centrado en la Máquina, culpaba al usuario de los errores y dificultades encontradas en la interacción con el software. Esto quiere decir, la máquina estaba bien, la culpa era del usuario.

Después, los usuarios empezaron a quejarse; los desarrolladores escucharon. Entonces culparon a los diseñadores. Aunque no resolvía el problema totalmente, se sentaron las bases para el Diseño Centrado en el Usuario (DCU).

La solución no sólo requería de buenas intenciones. Se requería, además, iterar la solución una y otra vez. Se necesitaba interrelacionar, de alguna manera, al dise-ño, y el proceso del diseño, con los usuarios. Así surgió la metodología de DCU.

En el modelo básico del DCU de una aplicación de software se concibe al usua-rio como al ente que no sólo opera el sistema sino que integra sus metas de trabajo con las funciones implementadas en la aplicación. Para ello, debe emplear y com-binar sus propias funciones cognitivas, manejando diversas capas operativas. La más elevada consiste en encajar el modelo conceptual del su trabajo con la percep-ción personal de las funciones de la aplicación informática. En una capa intermedia el usuario tiene que construir los comandos correctos para controlar en cada caso las funciones necesarias de la aplicación. Por último, la capa inferior comprende las acciones específicas sobre los dispositivos de entrada al sistema. Se cierra el circui-

21

to cuando el usuario interpreta el lenguaje de presentación de la aplicación –normalmente en forma icónica sobre la pantalla–, representativa del estado en el que se encuentra el procesamiento de la aplicación.

Con DCU, se puede mejorar la utilidad y usabilidad de cualquier aplicación de software.

Del aprovechamiento de estas medidas de calidad, del DCU aplicando la Inge-niería del Software como metodología predominante y de los conocimientos de la disciplina de la IPO, la Ingeniería de la Usabilidad proporcionará un proceso for-malizado para el diseño y desarrollo de sistemas interactivos centrados en el usua-rio.

De todas formas no debemos confundir “implicar al usuario en el diseño del sistema” con “realizar el diseño del sistema pensando en el usuario”. Mientras la primera frase conlleva trabajar codo a codo con usuarios participando activamente en dicho diseño en la segunda estos usuarios no intervienen hasta el momento de la implantación definitiva del sistema. En definitiva pensar en otra persona sin cono-cer su opinión de primera mano no sirve para nada.

2.4. La Ingeniería de la Usabilidad

La complejidad de los ordenadores y de sus aplicaciones han reflejado la nece-sidad de desarrollar su usabilidad (extendida a todo el campo de la IPO) y la com-plejidad de hacerlo, que desborda de lejos lo que se entiende por técnicas informáticas. La Ingeniería de la Usabilidad es multidisciplinar; se nutre de la in-formática, de la psicología, de la lingüística, de la sociología, de la antropología y del diseño industrial.

Este término viene utilizándose desde mediados de los ochenta, para designar a una nueva disciplina (UE, en siglas inglesas), que se ocupa de proporcionar “méto-dos sistemáticos y herramientas para la compleja tarea de diseñar interfaces de usuario fácilmente comprensibles, rápidamente aprendibles y fiablemente opera-bles” [61].

La importancia a la que se dota a la interfaz de usuario de una aplicación infor-mática es primordial, ya que en cierta manera ésta es para el usuario “la aplica-ción”, “el sistema”, el medio por el que la visualiza y por el que accede a sus prestaciones y servicios. La mayor parte de la calidad técnica de la aplicación aca-ba fluyendo por este conducto. Si no lo hace, queda inédita, o es inútil. Si la inter-faz no es efectiva, la funcionalidad de la aplicación y su utilidad están limitadas; los usuarios se confunden, se frustran y se enojan; los desarrolladores pierden cre-dibilidad y la empresa tiene que soportar altos costes y baja productividad.

22

Figura 2_3: Metodología conceptual y esquemática de la Ingeniería de la Usabilidad.

El objeto de la Ingeniería de la Usabilidad es minimizar la sobrecarga cognitiva y perceptiva del usuario de una aplicación. Utiliza un método de diseño iterativo con prototipado rápido (es imprescindible contar con herramientas de ayuda), cuyo esqueleto es el ciclo "análisis-diseño-implementación-evaluación" (véase figura 2_3), que se repite varias veces con vistas a ir enriqueciendo progresivamente el sistema. La etapa de evaluación del prototipo, confrontándolo con usuarios reales a cada repetición del ciclo, se revela como trascendental para obtener resultados dig-nos de una ingeniería.

2.5. Buscando un modelo de proceso

2.5.1. El proceso de software

Es importante recordar que la calidad de un desarrollo se mide no sólo por la evaluación del producto entregado sino por la evaluación del proceso aplicado.

Hasta ahora hemos empleado el termino “proceso de software”, pero ¿qué que-remos decir con este término?: Un proceso es un conjunto de pasos definidos para lograr una tarea, mientras que un proceso definido es aquel que está escrito a tal detalle que permite que los ingenieros lo usen constantemente. Los procesos defi-nidos ayudan a la planificación y desarrollo de un trabajo. Y un grupo de activida-des cuya meta es el desarrollo o evolución de software es un proceso de software.

No existe un proceso de software universal pues las características de cada pro-yecto (equipo de desarrollo, recursos, etc.) exigen que el proceso sea configurable. Pero el proceso que establezcamos debe ser flexible y debe facilitar el cambio y la innovación, al mismo que debe poder ser aprendido.

23

2.5.2. El Lenguaje de Modelado Unificado, UML

Una de las herramientas de diseño y análisis más utilizadas en los procesos de desarrollo de software bajo una perspectiva orientada a objetos, es la notación UML [48]. El Lenguaje de Modelado Unificado (UML - Unified Modeling Lan-guage) es un lenguaje gráfico para visualizar, especificar y documentar cada una de las partes que comprende el desarrollo de software.

El ciclo de vida para UML consiste en una serie de ciclos cada uno de los cuales produce una nueva versión del producto. Cada ciclo está compuesto por fases y cada una de estas fases está compuesta por un número de iteraciones.

Como lenguaje de modelado que es, no define un proceso estándar. Sin embar-go, existen una serie de actividades genéricas para todos los procesos de software:

• Análisis. Qué es lo que se quiere hacer. • Diseño. Cómo se quiere que se haga. • Programación. Escritura del código. • Mejora, depuración, mantenimiento, soporte.

Haciendo un resumen o compendio de todos los elementos expuestos hasta aho-

ra, convendremos en buscar un (modelo de) proceso de software cuyos beneficios sean los siguientes:

• Debe apoyarse en principios bien conocidos de la Ingeniería del Software. • Su enfoque deberá ser generalista y a su vez suficientemente conciso y ro-

busto para que el equipo de desarrollo pueda aplicarlo sin dudas ni ambi-güedades.

• Cubrirá todas las fases, tareas y actividades esenciales de un proyecto de software cuyo ciclo de vida queda especificado mediante UML.

• Su paradigma fundamental será el del Diseño Centrado en el Usuario. • Deber ser aplicable a todo tipo de proyectos y adaptarse tanto a desarrollos

comerciales como a proyectos a medida más específicos y especializados. • Este proceso será proporcionado por la Ingeniería de la Usabilidad.

2.6. Modelo de Proceso de Ingeniería de la Usabilidad y de la Accesibilidad

Una de las principales causas para no incluir la Ingeniería de Factores Humanos o Ingeniería de Usabilidad en los tradicionales modelos de desarrollo software es la complejidad que existe para unir las actividades que tienen lugar en estas dos dis-ciplinas.

Habitualmente se suele otorgar poca importancia a los usuarios en los modelos de desarrollo software, ya que típicamente la figura del usuario exclusivamente aparece al principio del desarrollo (Ingeniería de Requisitos), al final del mismo o al final de cada etapa, pero no durante el proceso de desarrollo.

24

Como contribución a cambiar esto, el Modelo de Proceso de la Ingeniería de la Usabilidad (MPIu+a) que tiene sus cimientos, por una parte, en la Ingeniería del Software y, por otra, en la disciplina de la IPO, proporciona las bases y la metodo-logía que permiten conocer cómo un equipo de desarrollo debe proceder para dise-ñar aplicaciones interactivas usables y accesibles siguiendo enfoques claramente marcados de DCU.

Aunque se trata de una herramienta de trabajo que guía metodológicamente a los equipos multidisciplinares de desarrollo esta no especifica ni el uso de un de-terminado lenguaje de programación, ni ninguna tecnología específica, ni ningún factor que pueda determinar la aplicación, sino todo lo contrario, es un proceso abierto a todo tipo de aplicaciones y tecnológicamente independiente.

2.7. Aplicación del modelo de proceso a la web

En el área de desarrollo de aplicaciones web se ha introducido un gran número de iniciativas para la creación de soluciones web al diseño clásico de software. Estos métodos pueden ser clasificados a partir de dos enfoques principales: los métodos hipermediales de desarrollo y los métodos que extienden la aproximación UML. Si además, pretendemos priorizar la incorporación de la usabilidad en un sitio web desde un principio y basarnos en la Ingeniería del Software y en la disci-plina de la Interacción Persona-Ordenador, aplicaremos el Modelo de Proceso de la Ingeniería de la Usabilidad aplicado al paradigma Web.

Aunque existen otras propuestas el modelo presentado basa todo el proceso de desarrollo en una constante aplicación iterativa de las actividades de Prototipado y Evaluación aplicadas a todas las etapas considerando la usabilidad desde un princi-pio, a la vez que integra, a diferencia de aquellas, actividades propias de la Ingenie-ría del Software y del desarrollo accesible.

2.8. Esquema del MPIu+a

Hemos visto que entre las características principales de la usabilidad cabe desta-car la claridad de la información y la consistencia, características a la vez aplica-bles a la accesibilidad del sistema.

Así pues el método dispone de un esquema claro y consistente para que los dis-tintos componentes del equipo de desarrollo ubiquen en todo momento la fase del desarrollo en la que se encuentran y las posibilidades u opciones disponibles a par-tir de la ella para continuar su desarrollo.

25

Figura 2_4: MPIu+a: Modelo de Proceso de la Ingeniería de la Usabilidad y de la Accesibilidad.

La figura anterior muestra el esquema del modelo el cual, además, no es extenso ni tiene muchos nodos y ramificaciones, que podrían provocar desconcierto para el desarrollador, sino que muestra una idea lo más clara posible del significado de todo el proceso a primera vista. Estas características básicas son:

2.8.1. Organización Conceptual.

El esquema está organizado en base a una serie de módulos o etapas que deter-minan la fase de desarrollo en la que nos encontramos y ubica en un paso concreto la actividad del conocimiento existente en IPO. Esto en definitiva no hace mas que “poner cada cosa en su sitio” dotando de las pautas a seguir durante el diseño de un sistema interactivo.

2.8.2. Tres pilares básicos.

Una de las características más importantes de este Modelo de Proceso es con-seguir aunar el modelo clásico del desarrollo de la Ingeniería del Software con los principios básicos de la Ingeniería de la Usabilidad. El esquema refleja claramente, con una codificación en colores, los pilares básicos de este modelo:

26

- la Ingeniería del Software, en el formato “clásico” de ciclo de vida en cascada (columna de la izquierda1 :

Análisis/Diseño/Implementación/Instalación). - el Prototipado (columna central2), cómo metodología que engloba téc-

nicas que permitirán la posterior fase de evaluación. - la Evaluación (columna de la derecha3) que engloba y categoriza los

métodos de evaluación existentes.

2.8.3. El usuario

En los modelos de desarrollo actuales los diseñadores y/o los programadores deciden por los usuarios, escogiendo las metáforas, organizando la información y los enlaces, eligiendo las opciones de los menús, etc. Dichas personas, incluso, etiquetan sus aplicaciones como amigables al usuario (con el famoso “user friend-ly”4) a pesar de que ningún usuario real haya dado su aprobación a tal característi-ca.

Si alguien tiene la potestad de calificar algo como “user friendly” éste es úni-camente el supuesto “user” o usuario, que es la persona que interacciona con el sistema.

Un proceso de diseño centrado en el usuario debe dejar claro de que es así tan solo con mirar el esquema la primera vez. Esto es lo que queda reflejado al dispo-ner a éste en la parte central y por encima del resto de etapas todo el Modelo de Proceso.

Otro aspecto determinante en este modelo de proceso es que se da mucha im-portancia no tan solo a los usuarios sino también a los implicados5 en cuanto a que son personas que sin ser usuarios directos del sistema su actividad se ve afectada por el mismo.

Queda claro, pues, que el usuario está en el centro del desarrollo y en las facetas en las cuales interviene.

1 De color azul si se dispone de una imagen en color del esquema del Modelo de Proceso. 2 De color verde si se dispone de una imagen en color del esquema del Modelo de Proceso. 3 De color amarillo si se dispone de una imagen en color del esquema del Modelo de Proceso. 4 User Frindly se traduce directamente como amigable para el usuario y hace referencia a la facilidad de uso como característica del programa o sistema que lo lleva etiquetado. 5 Posteriormente, al tratar el Análisis de los Requisitos, se explica el concepto del implicado y el porqué de su importancia en desarrollo de un sistema interactivo.

27

2.8.4. Un método iterativo

En todo proceso de desarrollo de software existe una fase más o menos impor-tante en la cual, a base de una serie de repeticiones, se pasa de una aproximación de la solución ideal a la solución definitiva.

Este proceso de repetición en la Ingeniería clásica del software se produce en una fase más tardía que en la Ingeniería de la Usabilidad, y suele ser más costosa en cuanto a recursos y tiempo empleado.

- Las flechas del esquema especifican los sentidos posibles del flujo de avance en el desarrollo del sistema.

- Las flechas azules, más delgadas, se corresponden con el modelo clási-co de la ingeniería del software y las de color gris, más gruesas con-vierten la IS en un verdadero modelo centrado en el usuario. Éstas últimas indican, entre otras cosas, donde interviene el usuario.

Podemos observar también que el modelo no sigue un sentido lineal ni restricti-

vo. Esto se debe a que es el diseñador junto con los requisitos de desarrollo los que marcarán cuantas iteraciones son necesarias.

2.8.5. Adaptado al Modelo Mental de los Equipos Multidisciplinares

Desde la óptica de la IPO idealmente los equipos de desarrollo software, como hemos visto, son multidisciplinares lo cual conlleva una amplia diversidad de mo-delos mentales diferentes. Ello supone que surgen más dificultades de las previstas si los mecanismos de comunicación no son eficientes y las herramientas formales de modelado no son suficientemente simples.

El modelo de proceso aquí presentado está preparado para ser completamente comprendido tanto por los componentes de las diferentes disciplinas como por los usuarios e implicados, quienes se integran en los mencionados equipos de desarrollo.

2.8.6. Etapas

A continuación se enumeran cada una de las etapas o módulos del MPIu+a para tener una visión general del modelo de proceso antes de su posterior aplicación al paradigma Web.

Análisis de Requisitos

En esta fase se formula el problema de diseño: se determina la audiencia y las plataformas destino, las metas de los usuarios y los requisitos técnicos, así como las necesidades de los usuarios y los requisitos de usabilidad. Supone determinar, enumerar y clasificar todas las características, capacidades y restricciones que ha de

28

cumplir y a las que se verá sometido. Los requisitos suelen estar enfocados en qué hará el sistema y no en como ha de hacerlo.

Esta fase es tan inmensamente crítica e importante que de ella dependerá la buena continuación del proyecto. Repercute directamente en la disminución del número de iteraciones necesarias para conseguir el proceso global y, en consecuen-cia, disminuirá el coste del desarrollo tanto en tiempo como en recursos. Además, si los requisitos no se definen correctamente, el cliente puede crearse falsas expec-tativas sobre el producto y finalmente quedar insatisfecho con el resultado.

El siguiente cuadro resume las actividades a realizar en esta etapa del MPIu+a:

Análisis de Requisitos: - Análisis Etnográfico - Análisis de Implicados (stakeholders) - Clasificar los usuarios: perfil de usuario Roles - Análisis Contextual de Tareas - Objetos - Plataforma (posibilidades/restricciones) -Objetivos: funcionales de usabilidad de accesibilidad

Los métodos de evaluación más comunes en esta fase son el análisis competiti-vo, las entrevistas con los usuarios y las encuestas. De lo que se puede deducir que será imposible determinar todos estos objetivos en una primera fase o estudio del cliente, debido, en parte, a que los clientes no son capaces de apreciar sus necesi-dades completas hasta que no pueden ver o interactuar con las opciones disponi-bles.

Diseño

En la fase de diseño conceptual, debe alcanzarse una idea clara de cómo será la interfaz de usuario y las relaciones con esta para desarrollar las especificaciones funcionales que sirvan de guía al diseño posterior. La interfaz determinará en gran medida la percepción que el usuario tendrá de la aplicación.

Diseño: - Análisis de Tareas - Diagramas de Transición de Estados - Estilo. Estrategias de diseño de la información - Estándares: Generales Particulares

Metáforas Colores - Diseño detallado

29

Cada tipo de interfaz tiene sus propias particularidades de su campo de aplica-ción. Son especificaciones que hay que tener en consideración en el momento de crear e implementar los prototipos. Sin embargo, cabe tenerlos presentes en la eta-pa de diseño porque pueden afectar a las funcionalidades de la interfaz y pueden venir determinadas por los requisitos del sistema a desarrollar.

Métodos típicos de diseño incluyen los Casos de Uso, Análisis de Tareas y la Arquitectura de la Información (AI), que “se refiere al diseño, organización, etique-tado, navegación y sistemas de búsqueda que ayudan a los usuarios a encontrar y gestionar la información de manera efectiva” El caso particular de diseño concep-tual de sitios web y la aplicación en nuestro proyecto se expondrá en el

• Prototipado Los prototipos son documentos, diseños o sistemas que simulan o tienen im-

plementadas partes del sistema final a desarrollar. Los prototipos son cruciales para diseñar un buen sitio web, facilitan la planificación del proceso de creación, redu-cen el coste de las evaluaciones, aumentan su efectividad y evitan graves errores en el diseño.

Prototipado: - Bocetos (esbozos) - StoryBoards - Prototipos en Papel - Maquetas - StoryBoard Navegacional - Videos - Escenarios - Prototipo software (horizontal / vertical)

El solo 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. Entre los métodos comunes de evaluación en esta fase incluyen los test con los usuarios y los focus groups.

Evaluación

En cada fase de desarrollo, se necesita algún tipo de realimentación del sistema, puesto que queremos identificar tan rápidamente como sea posible cuando el pro-ceso de diseño se desvía hacia un mal camino.

30

• Inspección El término inspección aplicado a la usabilidad aglutina un conjunto de métodos

para evaluar la usabilidad en los que hay unos expertos conocidos como evaluado-res que explican el grado de usabilidad de un sistema basándose en la inspección o examen de la interfaz del mismo.

Existen varios métodos que se enmarcan en la clasificación de evaluación por inspección. Los más importantes son:

• Heurística. Método desarrollado por Nielsen y Molich que consiste en analizar la conformidad de la interfaz con unos principios reconocidos de usabilidad (la “heurística”) mediante la inspección de varios evaluadores expertos. La aplica-ción del método se basa en validar las “10 reglas heurísticas de usabilidad” –conjunto revisado de reglas heurísticas de usabilidad a partir del análisis de 249 problemas de usabilidad– por dichos evaluadores.

• Recorrido de la Usabilidad Plural. Método desarrollado por Bias en los labo-ratorios IBM. Las principales características de este método son que se realiza con tres tipos de participantes que evalúan el modelo a partir básicamente de prototipos de papel y con una especie de debate final entre los participantes.

• Recorrido Cognitivo. Este método de inspección de la usabilidad se centra en evaluar la facilidad de aprendizaje del sistema. Se realiza básicamente de la forma que la mayoría de los usuarios prefieren o suelen aprender software: por exploración. Los revisores evalúan una propuesta de interfaz en el contexto de una o más tareas específicas.

• Estándares. Para evaluar este método se precisa de un evaluador que sea un experto en el o los estándares a evaluar. Dicho evaluador va pasando por la in-terfaz comprobando el cumplimiento o incumplimiento de dichos estándares.

• Indagación El proceso de indagación trata de llegar al conocimiento de una cosa discurrien-

do o por conjeturas y señales. En los métodos de evaluación realizados por indaga-ción hay un gran trabajo de hablar con los usuarios y observarlos detenidamente

31

usando el sistema en trabajo real (no para un test de usabilidad) o obteniendo res-puestas a preguntas verbalmente o por escrito.

Los principales métodos de evaluación por indagación son:

• Observación de campo. La observación de campo la describe Nielsen en base al trabajo que se realiza al visitar el lugar o lugares de trabajo donde se estén realizando las actividades objeto de nuestro estudio y donde se encuentran los usuarios representativos. El principal objetivo consiste en observarlos para en-tender cómo realizan sus tareas y qué clase de modelo mental tienen sobre ellas. Esta información será completada con preguntas y/o entrevistas persona-les. Este método se puede utilizar en las etapas de prueba y del despliegue del desarrollo del producto.

• Focus Group. El Focus Group o Grupo de Discusión Dirigido es una técnica de recolección de datos donde se reúne de 6 a 9 usuarios para discutir aspectos re-lacionados con el sistema. Un ingeniero de factores humanos hace las veces de moderador, que tiene que preparar la lista de aspectos a discutir y recoger la in-formación que necesita de la discusión. Esto permite capturar reacciones espon-táneas e ideas de los usuarios que evolucionan en el proceso dinámico del grupo [6].

• Entrevistas. Entrevistar a los usuarios respecto de su experiencia con un siste-ma interactivo resulta una manera directa y estructurada de recoger informa-ción. Además las cuestiones se pueden variar con tal de adaptarlas al contexto. Las entrevistas aportan información muy valiosa sobre aspectos que a veces no son tenidos suficientemente en cuenta por los diseñadores. Las entrevistas son realmente efectivas si el evaluador la ha preparado eficientemente de manera que conduce la misma y trata los temas que son realmente necesarios. Las en-trevistas son muy bien complementadas por los cuestionarios.

• Logging. La técnica del logging o grabación de uso se basa en “grabar” o “re-coger” todas las actividades realizadas por el usuario con el sistema para su posterior análisis. Para ello es preciso de una aplicación secundaria que realice automáticamente esta labor que pase, además, totalmente desapercibida por el usuario.

• Cuestionarios. El cuestionario es menos flexible que la entrevista, pero puede llegar a un grupo más numeroso y se puede analizar con más rigor. Se puede utilizar varias veces en el proceso de diseño. Y, como también se ha apuntado en el apartado de las entrevistas suelen complementarse muy bien. Estas, a igual que pasaba con las entrevistas, deben prepararse muy bien ya que como es un documento a cumplimentar por los usuarios debe ser muy claro y exento de ambigüedades que puedan confundirlos.

• Test En los métodos de usabilidad por test usuarios representativos trabajan en tareas

utilizando el sistema –o el prototipo– y los evaluadores utilizan los resultados para

32

ver cómo la interfaz de usuario soporta a los usuarios con sus tareas. Los principa-les métodos de evaluación por test son:

• Medida de las Prestaciones. Este método tiene como primer objetivo el mejo-rar la usabilidad del producto gracias a realizar el test con usuarios -personas o grupos- reales realizando labores habituales también reales.

• Thinking Aloud. En este método de evaluación conocido como thinking aloud (pensando en voz alta) descrito por Nielsen se les pide a los usuarios que ex-presen en voz alta sus pensamientos, sentimientos y opiniones mientras que in-teraccionan con el sistema –o un prototipo del mismo–. Es muy útil en la captura de un amplio rango de actividades cognitivas. Se realiza con usuarios únicos que expresan libremente todo lo que piensan sobre el diseño y la fun-cionalidad del sistema.

• Interacción Constructiva. Este sistema puede ser visto como una variante del anterior puesto que se trata de hacer lo mismo pero en vez de con usuarios úni-cos aquí se hace con grupos de dos usuarios hablando entre ellos. La principal ventaja es que como los usuarios tienen que hablar entre ellos salen a la luz muchas mas ideas que en el anterior –al ser uno solo podían quedar cosas en la mente del usuario–. Suele aportar más y mejor información que su antecesor.

• Test Retrospectivo. Esta técnica realmente es un complemento de las demás, ya que se trata de realizar alguno de los métodos anteriores, grabarlo en vídeo y analizar dicha grabación posteriormente. El hecho de hacerlo así permite “pa-sar” varias veces la cinta y examinar todos y cada uno de los detalles sin que pase ninguno por alto.

• Método del Conductor. En los métodos anteriores el usuario suele ir “a su aire” y el evaluador analiza los resultados a posteriori. En este método el evaluador conduce al usuario en la dirección correcta durante su uso del sistema.

Implementación

En la fase de implementación o producción, se crea el producto final. Llegados a este punto, a grandes rasgos, es cuando debe empezarse a programar, lo cual im-plica haber escogido el o los lenguajes de programación que mejor se adapten a nuestro proyecto, las bases de datos correspondientes que se precisen, la tecnología que garantice el éxito, etc. Se desarrollan los gráficos y textos definitivos y el sitio debe ser codificado.

Esta etapa corresponde exactamente a la que se describiría en la Ingeniería del Software clásica, puesto que la Ingeniería de la Usabilidad no trata de cómo pro-gramar un producto interactivo, sino de la metodología para conseguir un producto usable.

Métodos de evaluación comunes en esta fase incluyen test con los usuarios, Quality Assurance y test de campos. Los temas relacionados con la produc-ción/implementación son abordados en esta fase.

33

Lanzamiento

Finalmente, el producto se lanza y se hace disponible al público. La fase de lan-zamiento de todo proyecto, sea interactivo o de otra índole, suele ser una de las mas críticas de todo el proceso. Es el momento en que se ven concretadas en mayor o menor grado las expectativas puestas en el producto. De todas formas cabe indi-car que la percepción que el usuario final del producto tiene un peso específico enorme a la hora de indicar si el producto será aceptado o no.

Resumiendo, podemos indicar que el éxito total del producto dependerá de dos factores muy importantes:

• por un lado que el usuario se sienta cómodo con el sistema. Entendiendo cómo sentirse cómodo el que no le dé errores, que no le resulte complicado usarlo, que recuerde fácilmente donde están las diferentes opciones y sus funcionali-dades, etc., y

• por otro lado que los responsables obtengan los resultados esperados.

El ciclo de vida de la Ingeniería de la Usabilidad del MPIu+a asegura que am-bos aspectos se vean satisfechos puesto que:

• el diseño se ha hecho en base y para los usuarios, haciéndoles partícipes del mismo se consigue un efecto doble, por un lado cómo se sienten responsables en parte de dicho diseño no encontraran motivos para criticarlo, y por otro co-mo todo ha sido evaluado por ellos no les reportará una gran carga cognitiva ni de aprendizaje.

• como todo producto software, desarrollado por los métodos clásicos, la evalua-ción funcional es lo primero que se prima y no se da por bueno si no se cum-plen sus especificaciones.

Por lo indicado anteriormente podemos ver que en esta fase el factor más impor-

tante es lo que se suele conocer como User Feedback (“reacción o realimentación del usuario”).

Una vez el producto ha sido instalado y puesto en explotación durante un cierto periodo –denominado habitualmente como fase de pruebas–, se recoge lo que se llama el feedback del usuario, o sea las impresiones, pegas, mejoras, defectos, etc. que los usuarios.

A partir de dichas impresiones se hacen las mejoras y retoques que se crean oportunas, dejando el producto nuevamente en fase de testeo por parte del usuario hasta tener una satisfacción total.

Podríamos pensar que como el sistema se ha desarrollado siguiendo el modelo de proceso centrado en el usuario esta etapa debería ser innecesaria a este nivel del modelo, pero la misma autora nos describe cuatro buenas razones para que deba-mos tener en cuenta este factor:

34

• proporcionar una entrada para el mantenimiento y posibles mejoras del produc-to.

• proporcionar una entrada para la implementación de futuras revisiones del pro-ducto.

• proporcionar una entrada para el diseño y desarrollo de productos relacionados que serán utilizados por los mismos usuarios o de características similares.

• incrementar el autoaprendizaje en cuanto a la usabilidad (toda nueva experien-cia supone un incremento en cuanto a conocimientos ya sean nuevos o mejoras de los ya adquiridos).

Las actividades del pre-lanzamiento y el post-lanzamiento se cubren en esta eta-pa o fase.

35

3. Análisis de requisitos

Para que una aplicación finalice con éxito de-pende de manera crítica de esta fase [8][9] y aun-que este aspecto es ampliamente compartido por los desarrolladores de software lo cierto es que habitualmente esta fase no se realiza con el rigor que merece.

En el paradigma web los requisitos se centran en los grandes temas de estudio de la audiencia y las necesidades de los usuarios [5].

3.1. Estudio de la audiencia y de la plataforma

El objetivo del análisis de la audiencia es estudiar quienes serán nuestros usua-rios y el entorno de software y hardware que vamos a utilizar.

3.1.1. Audiencia

Cuando empezamos un nuevo proyecto de sitio web lo hacemos pensando en una audiencia determinada. Realizando el análisis de la audiencia pretendemos conocer cómo son realmente estos futuros usuarios y cuáles son sus necesidades. Para ello, podemos basarnos en información procedente de fuentes empresariales [10][11] o, si la información no está disponible, deberemos proceder a la realiza-ción de nuestros propios estudios realizando encuestas y/o entrevistas.

Para ello, organizaremos la audiencia en categorías, para cada una de las cuales estableceremos el perfil, sus necesidades y sus metas.

A la hora de entender la audiencia no sólo tendremos en cuenta los atributos personales, sino que también deberemos analizar los distintos dispositivos y plata-formas que utilizan para acceder a la información.

36

3.1.2. Análisis de la diversidad de la audiencia

Segmento de mercado —edad, género, educación, ocupación, aficiones...—, discapacidades —visuales, auditivas, motrices...— y nivel de experiencia son tipos de diferencias entre individuos que deben ser especialmente consideradas al diseñar webs accesibles.

Internacionalización: Diferencias culturales que puedan existir para cada cate-goría de audiencia, idiomas, localizaciones.

3.1.3. Escenarios

Los ordenadores son algo más que funcionalidades, inapelablemente reestructu-ran actividades humanas, creando nuevas posibilidades, al mismo tiempo que difi-cultades. Por otra parte en cada contexto en que el ser humano tiene experiencia y actúa proporciona unas restricciones para el desarrollo de sistemas de información.

En el momento que tengamos que analizar y diseñar software, necesitamos una manera de ver como estos nuevos sistemas pueden transformar los contextos actua-les de la actividad humana a la vez que pueden verse restringidos por ellos.

Los escenarios, en cuanto a una forma de reflejar las historias sobre personas y sus actividades, destacan:

- los objetivos sugeridos por la apariencia y comportamiento del sistema,

- que es lo que las personas quieren hacer con el sistema,

- que procedimientos se usan, cuáles no se usan,

- cuáles se realizan o no satisfactoriamente, y

- que interpretaciones hacen de lo que les sucede.

Esta técnica sirve tanto para contar la manera cómo se realizan las acciones ac-tualmente cómo para predecir el futuro. Lo importante en ambos casos es que el escenario contenga la mayoría (si no la totalidad) de las situaciones que directa o indirectamente intervienen durante el proceso interactivo destacando aquellos que son claves para que su consecución futura sea posible.

Peter Schwartz [49] aporta una reflexión acerca de los escenarios que merece tener en cuenta: Un escenario no es una predicción. Simplemente no es posible predecir el futuro con certeza. Un viejo proverbio árabe dice que quién predice el futuro miente, incluso si cuenta la verdad. Deberemos entender los escenarios, por tanto, cómo vehículos para ayudar a las personas a aprender.

37

Ventajas e inconvenientes de los escenarios

TABLA 3_1: VENTAJAS E INCONVENIENTES DE LOS ESCENARIOS COMO TECNICA DE PROTOTIPADO.

Ventajas [50]

- las descripciones de gente utilizando tecnología representadas en forma de escenarios son esen-ciales a la hora de discutir y analizar cómo la tecnología remodela (o puede remodelar) las activi-dades de los usuarios. - las descripciones de los escenarios pueden ser creadas antes de que el sistema sea construido y “sentir” el impacto resultante.

Inconvenientes

- Un escenario, o un conjunto de estos, no guía explícitamente al diseñador hacia el modelo correc-to del sistema a implementar. Un escenario “extremo” puede tender a razonamientos raros o excepcionales o a incidir sobre aspectos relacionados con implicados poco representativos. Esta tendencia es una reconocida “debilidad” de los escenarios [51].

Características de los escenarios:

TABLA 3_2: ELEMENTOS CARACTERISTICOS DE LOS ESCENARIOS DE LA INTERACCION DEL USUARIO1.

Elemento del escenario Definición Ejemplos Configuración (setting) - Detalles de situación que motivan o

explican objetivos, acciones y reacciones del/los actor/es. - Sitúa la acción.

- Oficina dentro de una organización de la contabilidad; estado del área de trabajo, de las herramientas, etc., al comienzo de la narración.

Actores - Persona/s interactuando con los dispo-sitivos interactivos o cualquier otro .elemento descrito en la configuración.

- Un contable utilizando una hoja de cálculo por primera vez.

Objetivos - Efectos en la situación que motivan acciones llevadas a cabo por actores.

- Necesidad de comparar las ofertas de un determinado presupuesto .

Planes - Actividad mental dirigida a convertir una meta en un comportamiento.

- Abrir el documento dará acceso a la información del presupuesto; redimensio-nando la ventana dejará espacio libre para abrir otro presupuesto.

Evaluación - Actividad mental dirigida a interpretar las características de la situación.

- Una ventana que es demasiado grande puede ocultar la que está debajo; los bordes oscuros indican que una ventana está activa.

Acciones - Describe el comportamiento observable (el diagrama de secuencias).

- Abriendo un documento; redimensionan-do y moviendo ventanas.

Eventos - Acciones externas o reacciones produ-cidas por el sistema interactivo u otras características descritas en la configura-ción; algunas pueden ser importantes para el escenario pero pueden mantener-se ocultas a los actores.

- El feedback de la selección de una ventana; el feedback auditivo del teclado y/o el ratón; apariencia actualizada de las ventanas.

1 Tabla basada en la página 18 de la referencia [52].

38

Maneras de representar los escenarios

Un escenario entendido cómo se ha explicado puede representarse de muchas maneras diferentes. Podemos incluso ver que alguna de las técnicas aquí expuestas solo son maneras de representar los escenarios. Veamos las formas más habituales de representación de escenarios:

• Lenguaje Natural:

Las descripciones en lenguaje natural se realizan, cómo su nombre indica, me-diante una narración escrita de la situación que queremos reflejar. Este tipo de na-rraciones suelen ser las que mejor sirven para producir rápidamente escenarios que pueden ser probados por usuarios. El principal problema es en la forma de describir la situación: ya vimos que el uso del lenguaje natural puede dar lugar a interpreta-ciones erróneas [53] o a descripciones demasiado largas que requieren demasiado esfuerzo por parte de los usuarios.

Figura 3_1: Ejemplo de un escenario descrito en lenguaje natural correspondiente a un proyecto para transformar la recepción de una empresa en un entorno ubicuo para sorprender a los clientes y visitantes.

39

• Mediante Storyboards:

La previamente comentada técnica del Storyboarding resulta altamente útil para describir escenarios de situaciones concretas que ayuden a entender partes del sis-tema. Con los storyboards se consigue dotar al escenario descrito en lenguaje natu-ral de la componente gráfica que facilita la comprensión y el detalle.

• Escenarios en Vídeos:

Los vídeos grabados para describir situaciones o escenarios son ninguna duda la mejor técnica que disponemos para representar las situaciones que deseamos des-cribir. Por su parte también son los que cuestan más dinero, requieren de personas más especializadas, equipos más sofisticados y más tiempo de desarrollo.

• Diagramas de Casos de Uso de UML:

Los casos de uso describen escenarios (de uso del sistema) a partir de secuen-cias de interacciones entre el sistema y uno o más actores, los cuales obtienen los resultados observables del sistema (el cual es considerado como una caja negra). En esta notación los actores representan tanto a personas como otros sistemas que interactúan con el sistema que se está describiendo [54].

Una de las características por la que muchos adeptos defienden la representa-ción de los escenarios con esta técnica es que al tratarse de una notación formal no hay lugar para las interpretaciones ambiguas.

Este tipo de diagramas son mayoritariamente aceptados por los componentes de los equipos de desarrollo que provienen de la Ingeniería del Software, quienes de-fienden que son fácilmente comprensibles por los clientes y usuarios y sirven ade-más de base para las pruebas del sistema y para la documentación de los usuarios [55].

Figura 3_2: El ejemplo muestra un escenario representado mediante la notación de Casos de Uso de UML correspondiente al desarrollo de un sistema Web para la gestión de congresos científicos.

40

De forma resumida cabe mencionar que los casos de uso tienen una representa-ción gráfica en los denominados Diagramas de Casos de Uso en los cuales los actores son representados por símbolos que esquemáticamente tienen forma huma-na y los casos de uso por elipses. Unas flechas entre el actor y el caso de uso sim-bolizan la participación de los primeros en los segundos.

Figura 3_3: Experimentalmente se demuestra que la manera más efectiva de representar los escenarios es mediante una combinación de varias formas de representarlos.

3.2. Diseño para la diversidad

Los sitios web están expuestos a gente de los más diversos orígenes y además a las personas que presentan algún tipo de discapacidad.

Cualquier persona con un ordenador conectado a internet puede visitar nuestro sitio web, independientemente de su origen geográfico, cultural, generacional o motivacional. Debemos, por tanto, diseñar nuestro sitio web teniendo siempre pre-sente esta característica.

Cualquier insinuación aparentemente inofensiva en un determinado contexto puede ser altamente ofensiva en otro. Esto es particularmente importante en sitios web diseñados para ser accedidos por varios países que compartan la misma len-gua. La lengua española, por poner un ejemplo, dispone de variaciones y transfor-maciones semánticas significativas de un país a otro (incluso entre regiones de un mismo país), por lo que el lenguaje a utilizar debe ser lo más internacional posible sin que esté sujeto a interpretaciones derivadas del contexto particular.

41

Es evidente que crear un diseño óptimo para todo el mundo es imposible y por ello es necesario identificar la audiencia destino de nuestro sitio con el fin de eva-luar sus necesidades minuciosamente.

3.2.1. Hardware y Sistemas Operativos

Sin duda, aunque Windows PC es la plataforma más común, hay que considerar que otras plataformas juegan un rol significativo en nuestra población objetivo. Si bien es cierto que las industrias pueden tener un uso muy pequeño del Mac, Mac tiene un share de mercado más alto en producción musical. En cuanto a los usua-rios de Unix y Linux, aunque son relativamente poco comunes, los consideraremos a la hora de evaluar el sitio.

3.2.2. Navegadores

La variación entre los browsers es extraordinariamente difícil de llevar al día. Si bien la inmensa mayoría usan el Internet Explorer (versión 5.0 y posterior) y no se puede descuidar al porcentaje que utiliza Netscape Navigator o similares, las varia-ciones entre versiones de estos browsers exige una evaluación prolongada.

Por otra parte, un 6 % de los usuarios de la web no tienen JavaScript habilitado. Si basamos nuestros trabajos exclusivamente con menús de esa tecnología, no po-drán navegar. Sin embargo, si es necesario su uso, podremos implementar con la versión 1.2.

Figura 3_4: Estadísticas de navegación: navegadores utilizados.

42

3.2.3. Monitores

Prácticamente la mitad de la población utilizan una resolución de 800 x 600, con lo que será conveniente probar a fondo nuestro sitio a esa definición además de evitar la aparición de scrolls horizontales. Es fundamental también darle la misma importancia a resoluciones de 1024x768. Así como evaluar minuciosamente defi-niciones de colores de 16 bits (65.000 colores).

3.2.4. Velocidad de conexión

Un tiempo largo de descarga es uno de las quejas de usabilidad más frecuentes. Las conexiones de alta velocidad más implantadas en nuestra audiencia son el ADSL y el Cable, pero tendremos especialmente presentes el uso de módems de 28.8K y 56K, para que nuestro sitio tenga un mínimo tiempo de espera.

3.3. Necesidades de los usuarios

En esta etapa, y partiendo del trabajo previo de análisis de la audiencia y de la plataforma, definiremos objetivos del negocio o entidad, los objetivos de usabili-dad, definir los implicados, analizar la competencia y fijar las metas de éxito a con-seguir.

3.3.1. Objetivos

Aunque este es uno de los puntos clave de cualquier análisis de requisitos, sea web o no, en el caso que nos ocupa son los objetivos de negocio más que los fun-cionales —aún así los objetivos funcionales son los más importantes, puesto que sin éstos normalmente la aplicación carece de sentido— los que deseamos identifi-car, ya que un parámetro que especialmente marcará el futuro de nuestro sitio será la medición del éxito en relación a dichos objetivos de negocio.

Objetivos de negocio (de la empresa)

En este apartado hemos de establecer por qué los usuarios visitarán este sitio, para entretenerse o para trabajar, para aprender o para aportar información, para conocer o para comprar. Si no sabemos establecer estas razones probablemente no visitarán el sitio.

Ejemplo: En la web de la infancia los objetivos de negocio son:

- La página debe servir de vínculo de comunicación entre la juventud y la Oficina de la Defensora de los Derechos de los Niños y Adolescen-tes.

43

- Tiene que ser un espacio educativo en el que a partir de diferentes acti-vidades los jóvenes que participen desarrollen un proceso de educación en valores y respeto hacia los demás.

- Que sea una herramienta que permita conocer la ciudad de Lleida, sus costumbres, su cultura, los lugares más emblemáticos, etc.

- Que sea, además, un elemento de interacción entre los niños/niñas y las TIC.

Objetivos de usabilidad

Sin objetivos es difícil poder decidir cómo diseñar un sitio web. Sin objetivos cuantificables de usabilidad resulta imposible medir y valorar si el sitio es usable o no lo es.

Los objetivos de usabilidad necesitan ser identificados para después ser medidos [12]. Asignar un valor (o varios) como meta para cada objetivo proporciona al di-señador una línea base de medida, comparación y análisis.

En este apartado analizaremos los objetivos que consideramos más importantes en cuanto a usabilidad del sitio [5].

En la definición de estos objetivos debemos evitar ser demasiado simplistas o irrealistas. Por ejemplo, la clásica regla de los tres clics, que indica que el diseño de la estructura de un sitio web debe permitir al usuario llegar en tres clics de ratón a la información que desea, es en muchas webs un objetivo irreal. No deben ser 3 clics, sino los justos y necesarios. Usando este objetivo como punto de partida es responsabilidad de cada equipo de diseño junto con los usuarios determinar “qué” elementos de información del sitio son “importantes” y cuántos clics son aceptables para llegar a ellos [13].

En la tabla siguiente definimos una serie posible de objetivos de usabilidad:

TABLA 3_3: POSIBLE DE OBJETIVOS DE USABILIDAD PARA UN SISTEMA INTERACTIVO.

Tiempo aprendiza-je/tiempo tarea

- Usar el sitio por primera vez sin entrenamiento. - Encontrar un tema por primera vez en menos de 2 minutos. - Usuarios expertos (5 visitas) menos de 30 segundos.

Facilidad de apren-dizaje

- Medible por el tiempo que se tarda en la consecución de las tareas habituales.

Número de errores - No visitar más de tres páginas erróneas para visitar una página. - No hacer errores fatales menos del 99% del tiempo.

Impresión subjetiva - En una escala de 1 a 10 en cuanto a que el sitio sea atractivo como mínimo de 7 (medible con una encuesta).

Tareas realizadas - Como mínimo un 75% de los usuarios serán capaces de realizar una compra (en el caso de una web de compra on line).

44

Objetivos de accesibilidad

La accesibilidad, al igual que la usabilidad, de por sí ya debe constituir un obje-tivo primordial de toda aplicación interactiva.

Cierto es que pensar en dotar de funcionalidad total para todos los tipos de dis-capacidades supone un reto difícilmente alcanzable, ya sea por el amplio abanico de estas discapacidades, o por el cada día menor conocimiento de cómo abordar el tema.

Otro aspecto a tener en cuenta son los equipos actuales, los cuales no disponen de capacidad suficiente para que poder dar soporte total para satisfacer estas nece-sidades (aunque cierto es que se está avanzando bastante en este aspecto).

Objetivos o especificaciones funcionales

Este apartado correspondería a la parte más tradicional del análisis de los requi-sitos de la IS, durante el cual se describe cada subsistema del software y todos los requisitos dentro de cada subsistema. Dado que es un tema suficientemente tratado en la IS no insistimos en él, salvo que es preciso comentar que puede darse el caso que algún objetivo de usabilidad entre en contradicción con alguna especificación funcional. Si esto sucede, el equipo de desarrollo junto a los encargados de mante-ner la calidad del sistema decidirá las acciones pertinentes.

3.3.2. Implicados

Los implicados son aquellas personas u organizaciones que se verán afectadas por el sistema a desarrollar y que tienen influencia directa o indirecta en los requi-sitos del mismo [14].

En un sitio de comercio-e los implicados pueden incluir a los vendedores, los distribuidores, la empresa de transportes, socios de negocio, publicistas, inversores, personas de otros departamentos relacionados (marketing, compras, ventas...).

Los usuarios finales del sistema, que evidentemente son los implicados en el mismo, no suelen englobarse en esta categoría porque su nivel de implicación res-pecto a los demás, por razones evidentes, es distinto. Por ello, los implicados sue-len etiquetarse también como “usuarios indirectos” [5].

Una vez identificados los implicados, debe procederse a obtener toda la influen-cia relativa al proyecto que éstos pueden aportar al mismo. Uno de los métodos más habituales de obtener esta información es realizando una serie de reuniones de implicados planificadas conocidas como “Stakeholders Meetings” [14].

3.3.3. Análisis de la competencia

Seguramente nuestra web, sobre todo si es comercial, no será única y tendrá que competir contra otras similares. Deberemos, por tanto, realizar en esta etapa del

45

desarrollo un análisis de todas las fuentes secundarias para conocer las fortalezas y debilidades de la competencia [15][16] encarado principalmente a la generación de ideas que deberán ser corroboradas por nuestros usuarios finales (que no tienen porque ser exactamente los mismos que los de dicha competencia).

Analizar la competencia sirve también para ver las buenas ideas que tienen los demás y que pueden ser aplicadas a nuestro negocio, pero debe procederse con mucho cuidado para no ultrapasar los límites de la propiedad intelectual.

Las etapas básicas a cubrir en esta actividad son:

1.- Realizar un listado de la competencia correspondiente

2.- Crear una tabla comparativa con la evaluación de cada sitio

3.- Realizar una presentación (Focus Group, etc.) para revisar los resultados.

3.3.4. Establecer medidas de éxito

Un aspecto importante a tener en cuenta en todo sitio web es establecer unos criterios que puedan determinar su éxito, o lo que es lo mismo, si cumple con los objetivos para los que fue desarrollado. En la mayor parte de casos, la medida esta-rá directamente relacionada con el objetivo del sitio, siendo el número de visitas, de solicitudes, de ficheros descargados o de ventas realizadas los parámetros habitua-les por los que se rigen.

En el caso del libro digital el éxito vendría dado por el número de descargas de los capítulos; en el de un congreso, el número de personas que finalmente se regis-trarán en el mismo; en el caso de la web de la infancia sería el número de niños de la ciudad de Lleida que la consultan y participan en sus juegos; en el caso de la estantería virtual, el número de profesores que han depositado material docente correspondiente a sus asignaturas y el número de alumnos que lo utilizan; en el centro excursionista será en el número de personas que acceden a la parte pública, y en el número de socios que consultan tanto la parte pública como la privada y la frecuencia con que lo hacen, etc.

Otra manera de considerar el éxito de un sitio es su clasificación en los buscado-res y directorios de sitios web más importantes.

3.4. Prototipado en los requisitos

- Maquetas: Las maquetas son básicamente una sola página de represen-taciones estáticas del espacio de diseño. Se usan para mejorar el diseño y facilitar la comunicación entre los diseñadores, usuarios e implica-dos. Consideraremos tres tipos:

- Boceto: Los bocetos son maquetas rápidas y pequeñas para desarrollar un amplio espectro de ideas de diseño.

46

Figura 3_5: Ejemplos de bocetos.

Se usan en la primera etapa del diseño, muchas veces antes de que se haya acabado la fase de análisis de requisitos. La clave de los bocetos es su ve-locidad. Cada boceto no puede costar más de 15 o 20 segundos, de esta manera se pueden generar una gran cantidad de bocetos en poco tiempo.

- Maqueta de papel: Son representaciones de una mayor calidad que los bocetos. Permite explorar el diseño de la página y los aspectos estéti-cos. Permite una comprensión más realista de los límites del tamaño de la página, del espacio de diseño, identificar posibles dificultades en el proceso de diseño y comenzar la evaluación con los usuarios.

- Maqueta digital: El prototipo digital constituye un paso más en la ela-boración de prototipos realizados con herramientas de diseño gráfico, siendo, por tanto, más costosos y elaborados. Permiten afinar aspectos importantes del diseño como los colores, los contrastes, las fuentes ti-pográficas, etc. que el prototipo de papel no proporciona.

Figura 3_6: Maquetas de papel y digital de la web de la Infancia de Lleida.

47

3.5. Evaluación en la fase de requisitos

Realizar encuestas es especialmente útil en las etapas más iniciales del proyecto. Esta técnica está especialmente indicada para conseguir una definición precisa de la audiencia y está siendo, además, una técnica con una buena relación coste-beneficio [13]. Éstas, además, en función de la audiencia a la que va destinada, casi siempre pueden realizarse a través del correo electrónico y tecnología basada en Internet (alcanzando así un espectro de población muy amplio y diverso).

Entrevistas y/o grupos de discusión (Focus Groups) con implicados (Stakehol-ders) [8][18] haciendo uso de maquetas o prototipos de papel nos proporcionarán reacciones subjetivas acerca de nuestras suposiciones que nos ayudaran a entender su entorno y cómo tratan de resolver sus problemas. El carácter individual de las entrevistas hace que los resultados obtenidos carezcan de influencias externas. Por el contrario, las influencias del grupo ensalzan aquellas ideas que un miembro des-tapa. Vemos, por tanto, que combinar ambas técnicas suele ser altamente beneficio-so.

Evaluaciones a partir de descripciones formales de escenarios de casos de uso [19][20] describen los requerimientos del sistema en el contexto de las especifica-ciones funcionales mostrando cómo se efectúan los procesos de negocios y qué actores o perfiles de usuario intervienen en éstos a través de las secuencias de ta-reas descritas para cada uno de los escenarios.

Evaluaciones del tipo recorrido cognitivo [21] donde los usuarios evalúan pre-ferentemente maquetas digitales son especialmente útiles cuando nos encontramos en una iteración un poco adelantada del modelo de proceso.

Figura 3_7: Focus Group con usuarios y implicados realizado para evaluar la maqueta digital la web del Centro Excursionista de Lleida.

48

49

4. Diseño

Durante la fase de análisis y especificación de los requisitos el objetivo es documentar lo que el sitio debe hacer. En la fase de diseño es importante determinar cómo será el sitio estructuralmente y gráficamente. En esta parte presentamos dos aspec-tos importantes en el diseño de un sitio web, el análisis de tareas y la arquitectura de la informa-ción. En los aspectos de prototipado y evaluación se presentan la ordenación de tarjetas, la maqueta digital y el Storyboard de navegación.

4.1. Análisis de tareas jerárquico (HTA)

El análisis de tareas constituye un apartado de la fase de diseño que modeliza los objetivos que debe realizar el usuario sobre el sistema que vamos a desarrollar.

El análisis jerárquico de tareas (HTA Hierarchical Task Analysis) desarrollado por Annett y Duncan [22] es la técnica de análisis de tareas más conocida y más antigua, que sigue siendo válida aunque hayan aparecido nuevas metodologías [23][24].

En HTA se realiza una descripción de tareas en términos de operaciones y pla-nes. Las operaciones (descomposición en subtareas) son actividades que realizan las personas para alcanzar un objetivo, y los planes son una descripción de las con-diciones que deben darse cuando se realiza cada una de las actividades. Las opera-ciones se pueden descomponer de forma jerárquica y se asigna un plan a cada una de las sub-tareas que aparecen. Se define un objetivo como un estado determinado del sistema que puede alcanzar el usuario. Aunque se habla de objetivos y tareas, la representación que se realiza describe únicamente la descomposición jerárquica en sub-tareas de las tareas que aparecen en el sistema.

50

El formato gráfico se parece a un árbol con ramas y sub-ramas en función de las necesidades. A la hora de describir la descomposición de unas tareas en sub-tareas podemos representar cuatro tipos de descomposiciones:

- Secuencia: Descomposición en un conjunto ordenado temporalmente de una secuencia de tareas.

- Selección: Conjunto de tareas de las que se tendrá que elegir una de ellas.

- Iteración: Repetición de un subconjunto de tareas.

- Tarea unitaria: Actividad indivisible (según el nivel de detalle dado).

El análisis de tarea implica tres etapas enlazadas: recogida de información, dia-gramación y análisis. Los procedimientos de recogida de información incluyen la revisión de la documentación existente (por ejemplo, manuales de funcionamiento, procedimientos, informes de seguridad, estudios de análisis de tareas previos, dise-ños, imágenes, prototipos, etc.), que permitan establecer lo que hacen las personas en circunstancias especificas (normales y anormales), entrevistas y cuestionarios (descripciones por parte de personas experimentadas de cómo hacen las cosas, qué informaciones necesitan y cómo determinan si la tarea se puede realizar satisfacto-riamente).

Algunas tareas se pueden desglosar con mayor detalle en secuencias. Un plan describe el conjunto de operaciones necesarias para llevar a cabo una actividad, o bien, muestra las circunstancias por las que una operación es realizada antes que otra. Estos planes se añaden a la tabla jerárquica.

La descripción de la información se realiza en forma de tabla o en forma de dia-grama de árbol que describa las relaciones entre tareas y sub-tareas.

Figura 4_1: Análisis de una tarea con el método HTA.

51

4.2. Arquitectura de la Información (AI)

La información es una fuente de conocimiento. Pero si no está organizada, procesada y disponible para las personas en un formato que les permita tomar decisiones, más que un beneficio es un estorbo. [William Pollard]

La Arquitectura de la Información se refiere a la estructura de la organización del sitio, especialmente en como las diferentes páginas del sitio están relacionadas entre si. Implica opciones como la planificación y el análisis de los contenidos, organización de las páginas, proporcionando indicaciones para ayudar a los usua-rios a orientarse, etiquetado, técnicas de búsqueda y diseño de la navegación [25][26].

La misma información puede tener diferentes estructuras razonables dependien-do de cómo la gente piense, hable de ella o la use.

Partiremos de la información aportada por el análisis de requisitos y el análisis de tareas. Se pueden revisar otras versiones del sitio web que estamos desarrollan-do y los de la competencia. Esto nos permitirá disponer de piezas de contenidos potenciales, etiquetas y esquemas de organización.

La AI agrupa usuarios y contenido en un determinado contexto de uso o nego-cio [25], y para implementar una AI deben confluir estos tres elementos clave para los cuales el diseñador debe poder responder las preguntas de la tabla 4_1.

TABLA 4_1: ELEMENTOS CLAVE DE LA ARQUITECTURA DE LA INFORMACION.

Para los Usuarios

- ¿Cuáles son las motivaciones que llevan a los usuarios a visitar nuestro sitio? - ¿Qué quieren los usuarios de este sitio?, y ¿qué necesitan de él? - ¿Quienes son?, y ¿Qué audiencias son más importantes? - ¿Cómo navegan1? - ¿Qué términos utilizan para navegar, buscar y clasificar la información? - ¿Cuáles son sus necesidades de información?

Para el Contenido

- ¿Cómo puedo organizar el contenido que tengo? - ¿Qué contenido tiene valor? - ¿De que contenido puedo deshacerme? - ¿Cómo pueden emerger las respuestas del contenido que tengo? - ¿Cómo debe el contenido ser organizado y etiquetado?

Y, para el Contexto

- ¿Quién, dentro de la organización, tiene poder de tomar decisiones?, y ¿qué quieren del sitio? - ¿Qué factores culturales y/o políticos pueden afectar a la arquitectura? - ¿Hay similares experiencias previas?, ¿acabaron bien? ¿porqué? - ¿Con qué recursos contamos (humanos, económicos, tiempo, tecnológicos)? - ¿Cómo la arquitectura será sostenida y mantenida? - ¿Están preparados para la AI?

1 El término navegación ha adoptado un nuevo significado con el irrupción de Internet. En este con-texto navegación está asociado con el propio significado del uso de internet, donde el usuario va “navegando” en un mar de páginas dispuestas en un océano de servidoes que están realcionados por una innumerable cantidad de enlaces.

52

4.2.1. Estructura de la información

INICIO

ARTISTAS

BIOGRAFIAS

ENTREVISTAS

DJ CHARTS

ARTISTA

ARTISTA

ARTISTA

CLUBS CLUBS

NOTICIAS NOTICIAS

ESPECIALES

DISCOS

ENLACES

FORO

BÚSQUEDA

COLABORA

CITA

AGENDA

EVENTOS

REPORTAJESARTICULOS

FOTOS FOTOS

ESPECIALES

DISCOS

ClubsArtistas

Discos

TEMAS MENSAJES

ENCUESTA

BOLETÍN

QUIENES SOMOS

CONTACTA CON NOSTROS

MAPA DEL SITIO

NORMAS DE PRIVACIDAD

Figura 4_2: Representación de la estructura de la información de la web de cultura nocturna.

53

Revisión de material previo

De la revisión de los resultados del análisis de requisitos, los sitios de los com-petidores y las tareas, surge una lista completa de los contenidos potenciales, eti-quetas candidatas y esquemas posibles de organización.

Identificación de objetos

En la elaboración de los contenidos de un sitio web primero debe procederse a la identificación de los objetos o unidades de información que contendrá la web en particular [13].

El proceso de identificación es un poco diferente si se trata de un sitio nuevo o de uno ya existente. El primero no cuenta con elementos preestablecidos y en el segundo una gran parte del esfuerzo se dedicará a mejorar la organización de la información actual.

Existen diferentes métodos para realizar esta actividad y el método a elegir de-penderá, en gran parte, del tiempo y presupuesto disponibles. Los métodos más apropiados son [13]:

- Grupos de Discusión (Focus Group).

- Encuestas estructuradas (Structured Survey).

- Encuestas de tanteo (Exploratory Survey).

Evaluación de nuestro contenido.

Crearemos un inventario del contenido, que especifica la lista completa de con-tenido para el sitio y que deber ser desarrollado.

Crear y evaluar nuestra estructura esencial

Basándonos en la estructura de la información, las tareas, los tipos de usuario y técnicas de evaluación con el usuario, crearemos una organización de nuestro con-tenido, decidiendo su agrupación y mostrando un esquema de organización.

Haremos uso de las dos aproximaciones principales para desarrollar una arqui-tectura: un diseño de abajo a arriba (bottom-up design) y un diseño de arriba abajo (top-down design).

Desde una aproximación de arriba a abajo, consideraremos que la información que podemos situar en un primer nivel podría venir relacionada con las tareas más frecuentes.

Desde una aproximación de abajo a arriba nos preguntamos por qué materiales disponemos para construir el sitio.

54

Ordenación de tarjetas (Card Sorting)

Una vez identificados los objetos nos encontramos frente al reto de organizarlos de manera que sea útil y comprensible para los usuarios del sistema.

Aunque es cierto que realizando el análisis de la información pueden revelar al-gunas pistas, difícilmente podrá determinarse qué tópicos deben agruparse entre ellos, y menos aún imaginar cómo los usuarios los agruparían.

La dificultad de organizar el contenido procede de la falta de conocimiento so-bre cómo usan los usuarios reales este contenido. Y sin este conocimiento cualquier intento de organizar dicha información no deja de ser un puro ejercicio teórico [27].

La técnica conocida como ordenación de tarjetas o Card Sorting [28] resulta al-tamente útil para conocer cómo los usuarios visualizan la organización de la infor-mación. El diseñador utiliza las aportaciones de los usuarios para decidir cómo deberá estructurarse la información en la interfaz.

Se trata de una técnica simple —fácil de entender y aplicar—, barata, rápida y que involucra a los usuarios, lo que está especialmente indicado cuando dispone-mos de una serie de ítems que precisen ser catalogados, así como para decidir la estructura organizativa de los sitios web.

Los pasos a seguir para implementar una ordenación de tarjetas son los siguien-tes:

- Determinar la lista de tópicos: Esta lista, que procede de la actividad anterior, no debería ser muy extensa (debe ser manejable), a la vez que debería ser comprensible para todos los participantes de la sesión. El evaluador no debe poner ningún tipo de indicación que pueda influen-ciar a los usuarios en su decisión, así como ningún tópico que induzca a la agrupación de términos (ejemplo: archivo, edición, FAQs).

- Crear las tarjetas: Cada tópico deberá escribirse en una tarjeta (papel, cartón) que ocasionalmente puede adjuntar algún tipo de explicación (aunque no es muy recomendable). Deberá, además, proporcionar tar-jetas en blanco a los participantes.

- Seleccionar a los participantes: Los participantes preferentemente se-rán usuarios finales (gerentes y otros implicados no son usuarios fina-les) y deberemos estar seguros que representan fielmente a grupos de usuarios potenciales del sistema.

- Proceder con la/s sesión/es de ordenación: Cada sesión debe comenzar con una explicación del método y de los objetivos animando a todos los participantes a organizar las tarjetas y a etiquetar los grupos según sus criterios personales. El organizador de la sesión debe tomar nota de todo aquello que pueda resultar relevante para la evaluación final.

55

Figura 4_3: Usuarios realizando una ordenación de tarjetas.

- Analizar las agrupaciones: Una vez han concluido todos el evaluador deberá analizar todas las agrupaciones en un ejercicio de análisis de-mocrático para identificar aquellas agrupaciones más frecuentes para poder decidir la estructura final. Existen programas informáticos espe-cíficos [29] que dan soporte a esta labor de síntesis.

Estructuras. Modelos o tipologías de organización de contenidos

El estudio de los modelos de navegación permite determinar y entender cómo navegan los usuarios para definir cómo queremos que naveguen por nuestro sitio.

Varias son las topologías, aunque casi todas, por no decir todas, parten de una página de inicio y de ahí dan acceso al resto del sitio. De todas formas, no hay que olvidar nunca que los navegantes pueden entrar en nuestro sitio a través de cual-quier otra página. La topología constituye la primera vía de definición acerca de cómo estarán enlazadas las diferentes páginas del sitio web.

Jerárquica Lineal Matriz

Malla completa Arbitraria Híbrida

Figura 4_4: Diferentes topologías o estructuras de modelos de navegación.

56

4.2.2. Navegación

Una vez definida la topología organizada a partir de la estructura aportada por la ordenación de tarjetas completaremos el trabajo añadiendo atajos aportados por el análisis de tareas, nos queda completar la arquitectura de la información diseñando como recorreremos esta topología que se conoce con el término de navegación. El objetivo de la navegación es:

- Permitir a los usuarios encontrar la trayectoria más fácil para llegar de-ntro de la topología que hemos definido a la información que busca.

- Asegurar que los usuarios saben siempre donde están.

- Asegurar que los usuarios se mueven rápida y lógicamente a través del sitio.

- Dar a los usuarios un contexto de lo que están leyendo.

- Destacar a los usuarios partes del sitio que interesa promocionar

Por tanto en esta fase desarrollaremos la barra de navegación y las señales de

orientación.

Barra de navegación

La barra de navegación constituye un elemento muy utilizado, prácticamente imprescindible en el diseño de la navegación de un sitio. Constan normalmente de un menú de opciones de las etiquetas de la AI que podemos seleccionar para nave-gar en el sitio. La posición más frecuente es en la parte izquierda y/o en la parte superior.

La barra de navegación aporta un mecanismo básico para que los usuarios pue-dan navegar por el sitio y la apariencia de esta establece un marco para que los usuarios puedan comprender como está organizado el sitio aunque no tiene que ser una vista de la estructura del sitio.

En los apartados siguientes recogemos los estilos de navegación más comunes que se encuentran actualmente en uso. Evidentemente, otros estilos de navegación pueden complementar los actuales o crearse de nuevos:

57

Navegación mínima La página de inicio puede enlazar con todas las páginas del sitio.

nicio. Mostrar los enlaces a las páginas de nivel inferior

Inicio

Productos: Conectores- electrónica- decoración

Navegación constante El término navegación constante (o global) describe el conjunto de los elemen-

tos de navegación que aparecen en todas las páginas del sitio. La siguiente figura muestra la navegación constante un determinado sitio web:

Migas Los breadcrumbs o migas de pan son un recurso que están utilizando cada vez

más webs. El término proviene del cuento Hansel y Gretel de los hermanos Grimm, Hansel dejo un rastro de migas de pan a través del bosque como una estrategia para encontrar el camino de vuelta a casa. Actualmente el usuario de internet tiene mu-chas veces la necesidad de navegar hacia atrás en el camino de un sitio web y se acuño el termino de rastro de migas de pan.

Se utilizan tres tipos diferentes de migas: Trayectoria, atributo y localización

• Trayectoria: Una página mostrará la miga basada en como el usuario ha alcanzado la página

58

La miga de trayectoria tiene dos objetivos:

- Suministra información de la localización de la página.

- Ofrece atajos para páginas vistas previamente sin utilizar el botón de volver atrás, otras barras de navegación o utilizar la búsqueda.

• Atributos La miga de atributos visualiza meta información mostrando diferentes trayec-

torias que representan diferentes posibles caminos para llegar a la página

• Localización

Es una representación textual de la estructura del sitio. Esta representación de la información permite al usuario enlazar con las categorías principales del sitio en un orden secuencial.

Categorías principales La barra de navegación presenta una lista de las categorías principales. Este sistema ayuda a definir el ámbito del sitio al usuario y permite un acceso rápido a la informa-ción primaria. Ejemplo http://www.nngroup.com:

59

Esquema expandible Visualiza una lista de opciones y permite la expansión de la opción seleccionada.

Barra de progreso Es especialmente interesante para resultados de motores de búsqueda:

Las imágenes anteriores corresponden a las barras de progreso de diversos bus-cadores genéricos como son google o yahoo

Y estas otras corresponden a buscadores “especializados” de tiendas virtuales como las de “Fnac” o “Amazon”.

60

Mapa del sitio La ventaja principal de un mapa del sitio es dar a los usuarios una descripción

de las áreas del sitio en un solo vistazo dedicando una página entera a una visuali-zación de la arquitectura de la información. Los usuarios utilizan los mapas cuando están perdidos, frustrados, o buscan detalles específicos. Si está bien diseñada, esta descripción puede incluir varios niveles de la jerarquía, pero no tan detallada que los usuarios pierdan su capacidad de comprender el mapa en su totalidad. Obligato-rio para todos los sitios, ya que refuerza un modelo mental del sitio.

Mecanismos de búsqueda Imprescindibles para sitios grandes y recomendables para cualquier sitio, ya que facili-tan el acceso a la información. Además, el uso de estas herramientas se ha convertido en un estándar de la navegación web.

Los mecanismos de búsqueda pueden ofrecerse de manera genérica como este ejem-plo de la web de IBM España:

O de forma especializada, como el ejemplo del boletín de la Unión Europea, para que los usuarios puedan precisar más en su intento de buscar la información que buscan:

61

TABLA 4_2: CONSEJOS PARA FACILITAR LAS BUSQUEDAS.

Evitar errores ortografícos

- Aunque, una ortografía correcta funcionará mejor, debemos ser conscientes que hay errores como por ejemplo los nombres escritos en otras lenguas que son de difícil escritura. Para ello es conveniente ofrecer variaciones en el silabeo de las palabras usadas en la búsqueda.

Por ejemplo, para buscar Clarence Thomas podría probar también con Clarance y Tomas.

Plurales - El motor de búsqueda debe soportar variaciones como el buscar car (auto) que es diferente de cars (autos). Puede llegar a necesitar incluir ambas palabras en la búsqueda, para conse-guir lo que busca o, de lo contrario buscar en cada uno por separado.

Palabras Similares - El desarrollador debe verificar los sinónimos de las palabras de las búsquedas con relacio-nes semánticas. Por ejemplo, en un sitio web para coches al mirar sobre automóviles podría incluir palabras como auto o monovolumen además de coche.

Lenguaje Natural - Muchos motores de búsqueda invitan al usuario a realizar las búsquedas mediante una pregunta en lugar de palabras clave. Por ejemplo ¿dónde puedo encontrar un buen restauran-te en Lleida? Con lo que el usuario probablemente encontrará lo que está buscando si utiliza solo unas pocas palabras clave: "Lleida" “restaurante”. El software "inteligente" que inter-preta su pregunta, no es lo suficientemente inteligente y se perderá el tiempo escribiendo las palabras extra para formar la oración. Debemos, por tanto, intentar evitar confundir al usua-rio.

Indicadores de orientación.

Botón de inicio (Home Button). Uno de los elementos más cruciales en la nave-gación es el botón o vinculo que nos lleva a la página principal del sitio. Tenerlo siempre a la vista tranquiliza, ya que nos permite volver a empezar otra vez si es-tamos perdidos.

Usted está aquí. Es un indicador de navegación que nos muestra donde estoy en la estructura de la información de la misma manera que cuando deambulamos por una ciudad encontramos paneles informativos con una flecha que no indica el punto del plano donde nos encontramos. En la web se resuelve realzando la posi-

62

ción donde de encuentra en la barra de navegación o otros elementos de navega-ción.

Títulos de página. Los títulos de página son un elemento importante de orien-tación y también como elemento de búsqueda. Es importante que este título se co-rresponda con el enlace que hemos marcado.

4.3. Organización de la página

Los conocidos principios de Gestalt, que describen las propiedades de configu-ración de la información visual, tienen muchas aplicaciones en el diseño de interfa-ces que expresan o transmiten información aplicable a la organización perceptual de los distintos elementos de la interfaz del usuario. De acuerdo con algunos de estos principios una de las formas más eficientes y habituales de estructurar la in-formación en las páginas web es subdividir el espacio disponible en porciones que agrupan contenidos similares o relacionados.

Veremos a continuación tres posibles variantes para la implementación de la agrupación de contenidos en formato de “columnas que agrupan contenidos simila-res”.

4.3.1. Anchura variable

El formato de achura variable es aquel que como en el ejemplo de la imagen (correspondiente a la web del consorcio para la web W3C) se ajusta a las diversas resoluciones y tamaños de las ventanas del navegador. Tiene la gran ventaja de que la estructura permanece invariante aunque como contrapartida cabe mencionar que si la reducción del tamaño de la ventana es considerable el texto se entremezcla perdiendo legibilidad y control de algunos elementos.

63

4.3.2. Anchura fija

Para este tipo de disposición el diseñador fija la resolución de la página y el po-sicionamiento de los elementos. Suelen realizarse de acuerdo a las resoluciones predominantes detectadas por aplicaciones como por ejemplo las estadísticas de los buscadores y pensando que el navegador ocupa toda la pantalla.

La principal ventaja está en que funcionan para la mayoría de usuarios y los principales inconvenientes son que se pierde parte del contenido si no se ocupa todo el espacio de pantalla y que aquellos usuarios que utilizan resoluciones mayo-res que la definida visualizan márgenes en blanco.

4.3.3. Combinación de anchura fija y variable

Este tipo de disposición es una combinación de las dos anteriores, o sea, ni es totalmente flexible ni totalmente rígida, sino que una parte de la página (habitual-mente la primera columna de la izquierda) tiene un tamaño fijo para proporcionar flexibilidad al resto.

64

Como ventajas de esta organización tenemos que se adapta a pantallas anchas y estrechas, que mantiene la legibilidad y que si la parte fija contiene el espacio dedi-cado a la navegación este nunca pierde legibilidad. Como contrapartida tenemos que resulta difícil de implementar y no puede garantizarse la consistencia.

4.4. Disposición

4.4.1. Consistencia

Se debe establecer una rejilla de la disposición y un estilo para organizar el tex-to los y gráficos, y se debe aplicar constantemente a través de las páginas de su sitio. La repetición no es pesada; da al sitio una identidad gráfica constante que crea y refuerza un sentido distinto de ubicación y hace el sitio identificable. Un acercamiento constante a la disposición y a la navegación permite que los lectores se adapten rápidamente al diseño y pueden predecir la localización de los controles de la información y de la navegación.

65

4.4.2. Dimensiones de la página

Dado que no existe forma de saber el tamaño que pueden tener las pantallas de los usuarios, hay que diseñar para todas las resoluciones de pantalla (en otras pala-bras, páginas independientes de la resolución que se adapten al tamaño de la panta-lla en la que se vayan a visualizar). El principio básico del diseño independiente de la resolución consiste en no usar nunca un ancho de píxel fijo para ninguna tabla, marco o elemento de diseño (exceptuando las barras finas en la parte lateral de la página). En vez de usar tamaños fijos, habrá que especificar diseños como porcen-tajes del espacio disponible

Las dimensiones de una página web son entidades movibles dinámicamente que se niegan a permanecer constantes. Pero existen consistencias en las que podemos confiar (véase tabla 4_2):

- La esquina superior izquierda es estática: es el único lugar en el que pode-mos confiar, todo lo demás puede cambiar.

- Las páginas se cargan de arriba abajo, de manera que la esquina superior izquierda es estática y las esquinas derechas e inferiores variarán.

- Algunos navegadores no muestran el contenido de una tabla hasta que se haya cargado todo lo que hay dentro de la tabla (por lo que no encerrare-mos toda la página en una tabla).

- El espacio blanco, aunque pueda parecer que es una perdida de espacio, puede ser efectivo en la organización y soporte de la estructura de la pági-na. Mientras que el espacio blanco vertical puede ser útil para diferenciar entre secciones de contenido, el espacio horizontal tiene un coste más alto. Los espacios en blanco pueden ayudar a los usuarios a entender el agrupa-miento de la información. Si tenemos la opción de separar dos segmentos de contenido con una línea gruesa o con espacios en blanco, normalmente será mejor utilizar la solución de los espacios en blanco, que suele descar-garse antes [56].

TABLA 4_3: CONSEJOS PARA FACILITAR LAS BUSQUEDAS.

AREAS SEGURAS DE RESOLUCIÓN (Ancho x Alto) Resoluciones de pantalla

Plataforma

Espacio de pantalla usado por los navegadores (en

Píxeles) 640 x 480 800 x 600 1.024 x 768 PC - MS Explorer 5.0 43 x 160 597 x 320 757 x 440 981 x 608 - Netscape 4.5 46 x 125 594 x 355 754 x 475 978 x 643 MacOs - MS Explorer 5.0 53 x 152 587 x 328 747 x 448 971 x 616 - Netscape 4.7 44 x 130 596 x 350 756 x 470 980 x 638

66

4.4.3. Rejillas: el diseño equilibrado

La composición de una pa´gina web debe ser equilibrada no sólo en contenidos, sino también visualmente. El orden en la disposición espacial de los elementos de la misma es uno de los factores más importantes para su éxito.

La rejilla o reticulado es un sistema de referencia formado por diferentes líneas horizontales y verticales que marcan la ubicación de elementos y zonas en una composición gráfica. Se trata de líneas que no tienen porqué tener una representa-ción real (no tienen porqué formar parte del grafismo), pero sí mental. Son las guí-as imaginarias sobre las que vamos a ir colocando los elementos, la espina dorsal de una composición gráfica.

Mediante el reticulado, el diseñador va situando con armonía los bloques de conte-nido que formarán la composición: zonas principales y secundarias, títulos y subtí-tulos, bloques de texto, fotografías, ilustraciones, gráficos, sistemas de navegación, botones, iconos, etc, dando con ello un estilo propio visualmente lógico a la misma.

Concretamente para el diseño web, el diseñador distribuirá una serie de rectángulos en pantalla que representen las zonas que va a tener la página. Y esta estructura lógica creada con el reticulado debe mantenerse luego en todas las páginas que forman el sitio web, proporcionando con ello consistencia y homogeneidad al mis-mo

4.5. Escribir para la web

4.5.1. Diferencia entre el papel y la presentación en línea

Los usuarios casi siempre ojean velozmente (scanean) las páginas web, leyendo palabras y frases sueltas en búsqueda de algo que les llame la atención. Concreta-mente el 79% de ellos actúa de esta manera. Los usuarios nunca leen detalladamen-te mientras navegan y sólo el 16% de ellos leen palabra por palabra [57].

67

La afirmación anterior no significa que los usuarios no analicen y capten deta-lladamente la información presentada en las páginas web, se refiere únicamente al estilo de captar información, no leyendo línea por línea, sino a saltos2.

Los usuarios se centran en las áreas de texto de la página, es decir en los conte-nidos, ignorando las áreas de navegación, gráficos y otros elementos de diseño global. Este dato confirma la idea de que el aspecto estético de un sitio web no tiene la importancia que generalmente se le otorga, sino que lo realmente esencial es el contenido.

En este estilo de lectura todo elemento de información presentado en un sitio web compite con el resto para captar la atención del usuario y por ello es crucial evitar presentar información superflua. Se trata de reducir la carga cognitiva para que se produzca un procesamiento de la información eficiente y rápido, exacta-mente lo contrario que pretenden la mayoría de los libros impresos.

Para ello, la estructura de la información de un sitio web debe tener las siguien-tes características:

1. Los contenidos se deben estructurar mediante resúmenes y tablas de con-tenidos.

2. Se favorece el ojeo rápido (escaneo) mediante [57]:

a. El texto debe organizarse resaltando las palabras importantes. Los propios enlaces son una forma de resaltar ciertos contenidos; variaciones tipográficas o de color son otras.

b. Utilizando subtítulos significativos, listas numeradas o no nume-radas, líneas separadoras, etc.

c. Los párrafos deben contener una idea única y cuanto más al principio de este mejor.

d. Utilizar estilo de redacción de pirámide invertida, comenzando por la conclusión y finalizando con los detalles. Así, opcionalmen-te la persona que desee profundizar puede seguir leyendo sin per-juicio del usuario que busca rápidamente la información.

e. Se deben omitir las palabras innecesarias: utilizar la mitad de palabras que se usarían en la redacción de un texto común impreso.

3. Se debe utilizar lenguaje objetivo, sin exceso de adjetivos, palabras re-dundantes o afirmaciones no basadas en evidencias, es decir, lo contrario del lenguaje promocional.

2 Los estudios de movimientos oculares muestran que incluso cuando los usuarios creen leer total-mente un texto on-line, en realidad sólo leen aproximadamente el 75%.

68

4. Utilización de una combinación de colores de texto y fondo con suficiente contraste (texto claro sobre fondo oscuro o viceversa).

5. El lenguaje simple e informal es más adecuado que el elegante o formal, ya que la lectura es más rápida en el primero.

6. No se deben utilizar textos parpadeantes o deslizantes, pues dificultan la tarea de leer y hacen difícil prestar atención a otro punto de la página.

4.5.2. Escribir para ser leído

El escribir a ser parte leída del diseño del Web page incluye el uso constante de elementos textuales. Estas pautas mejorarán legibilidad [58]:

• Cabeceras Haga la cabecera de la página con un formato H1, redactado de modo que el

usuario sepa porqué la página es importante.

Cerciórese de que las cabeceras indiquen claramente el contenido de las sec-ciones. Evite el carácter en línea que ajusta a formato a las cabezas -- los resulta-dos son imprevisibles, variando de navegador a navegador.

Organice su texto de modo que la jerarquía no sea más profunda de cuatro niveles. Las cabezas de nivel inferior son duras de distinguir y desorientan a los lectores en línea.

• Listas: Puede incluir un mayor número de listas en una página web que en una pági-

na de papel impresa. Utilice las listas numeradas cuando el número de entradas sea importante.

Utilice las listas no numeradas siempre que la secuencia de las entradas no sea importante.

Limite el número de elementos en una sola lista no más a de nueve. General-mente, el límite enumera a no más de dos niveles: primario y secundario.

• Subtítulos: Cerciórese de que el subtítulo identifique únicamente la ilustración o la tabla.

Por ejemplo, no dé el mismo nombre al subtítulo que usted ha dado a una cabeza en la misma página u otra página.

Subtitule las ilustraciones a menos que cuando el contexto está tan claro que los subtítulos serían redundantes.

No numere las ilustraciones secuencialmente por capítulo, la sección, o los similares. Si una captura de pantalla tiene más de una ilustración a la cual usted deba referirse, utilice un esquema simple de enumeración (cuadro 1, cuadro 2).

69

No incluya la figura subtítulos a menos que los necesite o tenga muchos de material conceptual o de referencia.

• Hyperenlaces: No utilice un acoplamiento de hypertexto si la información se puede presen-

tar sucinto en la página actual.

No mencione que está proporcionando enlace en todos.

Utilice una descripción de la información que se encontrará en el enlace, o quizás la dirección de enlace.

Utilice los hyperenlaces para proporcionar la información suplementaria co-mo definiciones de términos y de abreviaturas, de la información de referencia, y de la lectura de base.

Las referencias recíprocas debajo del "consideran también" (o) el título simi-lar cuando sea apropiado.

Generalmente, tales listas de referencias recíprocas son las más fáciles leer si incluyen solamente títulos o títulos con algunas palabras de la explicación.

4.5.3. Escribir para ser encontrado

Más de la mitad de los usuarios de la web confía en los motores de búsqueda para navegar las páginas.

Cuando los usuarios acceden a una página desde un motor de búsqueda, deben saber inmediatamente la relación exacta que tiene la página respecto a su pregunta. Para ello se recomienda destacar las palabras clave, comenzar la página con un resumen y seguir las pautas enumeradas para la escritura en la web.

Otros aspectos que favorecen “ser encontrado” son:

- Incluya en cada página todos los términos posibles de la pregunta que se puedan utilizar para buscar para el asunto de la página.

- Enumere los términos más importantes de una meta-etiqueta de las pala-bras clave junto con todos los sinónimos comunes (incluso unos no in-cluidos en el texto del cuerpo).

- Incluya los términos genéricos por usados los clientes o las compañías competentes de describir el asunto de la página; no incluya las marcas re-gistradas de los competidores en la meta-etiqueta. Sintaxis: <META name="keywords" content="Solaris 2.6, upgrade requirements, operat-ing system versions">

- Use un vocabulario controlado de agregar palabras claves a las meta-etiquetas para sus páginas: cree una lista de los términos comunes para su

70

tema y cerciórese de que cada uno de estos términos está agregado a la me-ta-etiqueta de las palabras claves para esas páginas relacionadas.

- No agregue una palabra clave si la página relacionada tiene una relación superficial o periférica con el término. Utilice solamente las palabras cla-ve que describen el asunto principal de una página.

• Cada página debe tener un título marcado con la etiqueta <TITLE>: - Cree el texto del título de una sola línea (unos 60 caracteres como máxi-

mo). Asegúrese de que los primeros 40 caracteres del título describen el asunto de la página (los títulos a menudo son cortados en menús de la na-vegación y por los motores de búsqueda).

- La primera palabra del título debe ser la más importante de la página: los usuarios a menudo exploran largas listas de títulos para elegir las pági-nas. No comience un título con términos genéricos ("Bienvenido a ") o ar-tículos ("El…").

- El título debe tener sentido cuando está visto totalmente fuera de contex-to, como parte de una lista larga de otros títulos de la página.

- De títulos distintos a páginas distintas: si el asunto de las páginas es casi igual el título puede comenzar con las mismas palabras pero debe terminar con las palabras que explican la diferencia entre ellas.

- Haga uso de MAYUSCULAS solo para palabras clave que quieran desta-carse (no lo utilice para la primera palabra: estar en primera posición del tí-tulo ya aporta es suficiente énfasis).

• Cada página debería tener un pequeño resumen en una descripción meta-tag: este resumen suele mostrarse bajo cada búsqueda en algunos buscadores. - El resumen no superará los 150 caracteres.

- El resumen debe tener sentido cuando es leído fuera del contexto y puede asumirse que se leerá conjuntamente con el título.

Sintaxis: name="description" content="How to upgrade from Solaris 2.5 to Solaris 2.6: system requirements, where to buy, link to online download.">

4.5.4. La página de inicio

A diferencia de las páginas de menor nivel, la página principal tiene que atraer a cualquiera que visite el sitio, sin importar sus distintos intereses. La pequeña canti-dad del espacio visible por encima del pliegue (término heredado de los periódicos,

71

que significa la parte de la página que puede verse sin desplazarse) en la página principal es la zona favorita.

El campo de la usabilidad web ha madurado lo suficiente como para desarrollar directrices especiales que codifiquen las mejores prácticas de diseño para los com-ponentes específicos de un sitio web. Además primaremos la incorporación de convenciones estándar de diseño de la interfaz de usuario, ya que los usuarios no dedicarán tiempo a aprender nada nuevo, sino a extraer el valor del objetivo y con-tenidos [60].

La funciones más importantes de la página de inicio con respecto a los símiles a los que puede aludir son:

- Definir el contenido y el estilo;

- No ser demasiado superficial e invertir en el diseño de la interacción del si-tio;

- Estar bien señalizada, como primera página de un periódico pero aportando más servicios y,

- Tiene que alentar a la gente a que siga leyendo.

A menudo, la página de inicio es la primera oportunidad (y posiblemente la úl-tima) de atraer y retener a cada cliente, haciendo las veces de la primera página de un periódico. Uno de los valores más grandes de la primera página de un periódico es la prioridad que se da a los titulares de las noticias más importantes. Todas las páginas de inicio se verían beneficiadas si fueran tratadas como la primera página de un periódico importante, con editores que determinaran el contenido de mayor interés y que aseguraran la continuidad y coherencia del estilo.

El reto consiste en diseñar una página web que permita el acceso a todas las op-ciones importantes sin crear desorden en la página web. La claridad es vital, porque así se atienden las necesidades de los usuarios.

Si bien muchas de estas directrices se pueden aplicar al diseño web en general, son especialmente importantes a la hora de diseñar la página de inicio. Mejorare-mos la usabilidad siguiendo estas directrices implicando a los propios usuarios en el proceso y probar la usabilidad e incorporar información iterativa en el ciclo de desarrollo.

4.5.5. La página de error

No seamos ilusos… la página de error existe!! Veamos algunos de los errores más frecuentes que los usuarios encontramos mientras navegamos en internet [59]:

- Enlaces rotos.

72

- Páginas que han caducado o han cambiado de ubicación debido a reestruc-turaciones.

- Errores a la hora de escribir o copiar una URL.

- Los errores en la entrada de datos de los formularios son muy habituales.

- Búsquedas que no ofrecen resultados.

- Expiración de sesiones cuando la página pedida se encuentra bajo un ser-vidor seguro o dentro de la sesión de un usuario.

Y como evidentemente estos errores no siempre están bajo nuestro control es aconsejable crear una página de error genérica para aquellos errores que no poda-mos controlar que aparece en caso de que este se produzca con una breve explica-ción del posible motivo del error junto al logo de la página y enlaces a la página principal, el mapa de navegación y la ayuda (por ejemplo).

Para los errores que tenemos identificados crearemos páginas específicas que ayuden al usuario a continuar su navegación y indicarle como salir del atolladero.

4.5.6. Anotaciones importantes

- 79% de los usuarios exploran; solo el 16% leen palabra por palabra.

- La lectura de pantallas de ordenador es un 25% más lenta que en papel.

- El contenido escrito de una web debe ser 50% el tamaño de su equivalente en papel.

4.6. Prototipado en el diseño

El prototipado es una parte muy importante de la fase de diseño. Utilizaremos por una parte todo el material preparado en la fase de requisitos, esbozos, papel, escenarios y realizaremos unos prototipos mas detallados de la AI, la página, etc…

4.6.1. Maquetas

Usaremos representaciones estáticas del espacio de diseño para centrarnos en su look & feel y tratar de abordar los problemas de distribución del contenido más. Además, las maquetas nos servirán como método de evaluación con los usuarios.

Selección de las páginas que requieren maqueta

Elegiremos que páginas vamos a maquetar dependiendo del objetivo del borra-dor: si básicamente se usarán para desarrollo interno y evaluación con el usuario, o si su principal objetivo es la revisión con la audiencia y el acabado del look & feel.

73

Realizaremos las maquetas de páginas que incluyen grandes cantidades de da-tos, están generadas dinámicamente y/o se desvían significativamente del resto de páginas, como por ejemplo, la página principal o de inicio, algunas páginas de ad-ministración, la agenda de eventos y la página de error. Estas maquetas en papel formarán la base de posteriores prototipos, tanto maquetas digitales, como prototi-pos HTML.

(a) (b)

(c) (d)

(e)

Figura 4_5: Diversas miniaturas y maquetas en papel de las páginas de inicio (a, b y c), esquemas (d) y la página de agenda (e) desarrollados para un determinado sitio web.

En refinamientos posteriores y etapas más avanzadas usaremos las maquetas pa-ra la aprobación del look & feel por la audiencia. En este caso, escogeremos la pá-

74

gina de inicio. Vamos a ejemplificar paso a paso la creación de una de las versiones de ésta página, en la que posteriormente basaremos el diseño definitivo.

Página de inicio

• Miniaturas (thumbnails). Empezaremos desarrollando una serie de thumbnails basados en los requisitos básicos de la página (véase fig 5). Con los thumbnails exploraremos el espacio de diseño de una forma extremadamente rápida, ya que son pequeños y no están muy detallados.

Figura 4_6: Conjunto de miniaturas (thumbnails) de la página de inicio.

• Crearemos un bosquejo más refinado del thumbnail escogido. Una vez escogi-do el thumbnail del cual realizaremos la maqueta, bosquejaremos un borrador en grande y más refinado.

• Crearemos la maqueta dibujando los límites de la página, los elementos básicos y la estructura: áreas de navegación, cabeceras, pies de página, área de conteni-do... Añadiremos logotipos, gráficos clave, etiquetas principales y títulos y acabaremos añadiendo texto de contenido y la situación de las fotos.

• Chequeo de la maqueta y evaluación. Nos aseguraremos que hemos seguido todos los criterios de creación evaluando la maqueta con unos principios heu-rísticos como por ejemplo los de la evaluación heurística.

75

Figura 4_7: Maqueta en papel de la página de inicio.

Maquetas Digitales

Una vez hemos conseguido un diseño de una manera rápida y poco costosa avanzaremos un paso más y desarrollaremos maquetas digitales, las cuales son representaciones de calidad en formato digital que permiten visualizar de una ma-nera muy aproximada a la versión final el diseño de la página, colores, forma de la estructura de navegación, botones. Las maquetas de papel se perciben como menos pulidas y más conceptuales, mientras que los usuarios e implicados ven las maque-tas digitales como versiones finales que no se pueden cambiar y, por tanto, es más adecuado utilizarlas en las fases finales del diseño.

Se realizarán maquetas digitales básicamente para evaluarlas con los usuarios. En este punto, nos interesará que los usuarios se centren en detalles de la distribu-ción de la página y en cuestiones como la elección de la fuente, los espaciados, los nombres de las etiquetas o los colores.

En la figura 4_8 pueden verse dos versiones diferentes de la página de inicio. La intención buscada no es compararlas, sino extraer conclusiones de las pruebas con los usuarios y optar por una versión en la que centrarnos para alcanzar un diseño único.

La comparación como método para obtener conclusiones tiene su fortaleza cuando los sitios comparados son idénticos y solo difieren en una sola característi-ca, es decir, la característica que estamos comparando. El único uso adecuado de la comparación como herramienta de la usabilidad es durante la fase de creación de prototipos de bajo coste. Es posible crear dos prototipos idénticos que solo varíen en una característica y realizar test de usuarios sobre ellos.

76

Figura 4_8: Dos Maquetas digitales distintas para el diseño de una página de inicio.

Y en la figura siguiente podemos ver la evolución del prototipado de un deter-minado sitio web:

Figura 4_9: Visión de la evolución del diseño a base de diferentes técnicas de prototipado de la página de inicio de un determinado sitio web.

77

4.6.2. Storyboard Navegacional

Un storyboard navegacional es una técnica diferente del storyboard visto ante-riormente que consiste en desarrollar una serie de dibujos o imágenes que represen-tan el espacio de navegación, bien sea de todo el sistema, de una parte de él o de una tarea concreta.

Con esta técnica se representan en un espacio bidireccional (con papel, en una pizarra, con impresiones de pantalla y flechas con rotulador, etc.) todos los estados de las interfaces (pantallas,…) de la parte del sistema que se examinará y todas las posibilidades a nivel interactivo desde cada uno de estos estados para visualizar las posibles acciones o movimientos que el usuario puede realizar mientras interaccio-na con la interfaz.

Son secuencias de pantallas que se centran en las posibles acciones o movimien-tos que el usuario puede realizar en el sitio.

Figura 4_10: Visión de la evolución del diseño a base de diferentes técnicas de prototipado de la página de inicio de un determinado sitio web.

Esta técnica permite comprender el flujo del trabajo de los usuarios así cómo el soporte que la interfaz ofrece al usuario en cada paso de la interacción durante la consecución de las diferentes tareas.

Los Storyboards Navegacionales pueden implementarse tanto a partir de se-cuencias realizadas con prototipos de papel cómo si estas son maquetas digitales. Lo que cambiará será la definición y el nivel de detalle así cómo el tiempo necesa-rio para su materialización, repercutiendo principalmente en la percepción que el usuario observará.

79

5. Implementación

Dos aspectos primordiales deben considerarse: el puramente tecnológico y el de los contenidos.

El primero incluye los lenguajes de programa-ción a utilizar, las hojas de estilos e incluso el se-guimiento de las normas WAI para disponer de páginas accesibles a personas con discapacidades. En este aspecto, el MPIu+a, como ya se ha men-cionado, deja libertad al equipo de desarrollo, pues-to que debemos recordar que el MPIu+a lo que hace es guiar en el proceso de desarrollo para la consecución de productos usables, sin entrar en la tecnología que hay que utilizar, puesto que ello

dependerá de cada proyecto concreto.

En cuanto a los contenidos, debe tenerse en cuenta que escribir para la web es totalmente distinto a hacerlo para otro medio, puesto que el texto tiene que redac-tarse de manera que soporte las tareas y los objetivos del usuario y deberá adaptar-se a la audiencia prevista. El proceso de escritura deberá, por tanto, estar orientado en función de los parámetros de lectura fácil, legibilidad, facilidad de exploración (los navegantes no leen sino que exploran la información en busca de un conteni-do), la paginación, los enlaces y los principales hitos de cada página. Esta conducta a la hora de leer condicionara la manera en la que deberemos escribir para la web. Utilizaremos el modelo de escritura en pirámide invertida, que consiste en empezar cada página por la conclusión [30]. El usuario debe poder discernir al primer vista-zo si lo que hay dentro le interesa lo suficiente para continuar leyendo.

81

6. Lanzamiento

Todo lo realizado anteriormente entra en escena definitivamente en esta fase. Es el momento en el que todo el trabajo se ha desarrollado y se pondrá a disposición del usuario final.

Cuando se trata de una aplicación web esta fase consta de tres partes bien diferenciadas: Prelanza-miento, lanzamiento y postlanzamiento:

6.1. Prelanzamiento

Fase en la que el registro del dominio, el alojamiento y los tests de tareas, de código y de carga del sistema deben realizarse.

En el diseño web se dice que es más probable encontrar el Santo Grial que una web que cumpla con la fecha de lanzamiento. Por esa razón, entre otras, se incluye en la planificación del desarrollo del proyecto un tiempo añadido (10%) para tratar con situaciones inesperadas que seguramente acontecerán.

6.1.1. Registro del nombre de dominio

Uno de los pasos cruciales en la planificación es asegurarse que hemos selec-cionado y registrado el nombre de dominio antes del lanzamiento. Elegiremos el nombre de domino .com, ya que los navegadores por defecto se dirigen al .com cuando se omite la extensión. Además, considerando posibles alternativas, registra-remos los siguientes nombres con dominios .net, .org, .es, ….

82

6.2. Lanzamiento

6.2.1. Publicación de una página

El propósito que tenemos al confeccionar una página del Web es, por supuesto, el de publicarla y ponerla a disposición de todo el mundo.

No podemos colocarla directamente en la red, pues necesitaríamos disponer pa-ra nosotros solos de un servidor, es decir, un ordenador conectado permanentemen-te con Internet y dotado de un programa específico, lo que supone una gran inversión económica y unos elevados conocimientos técnicos.

La solución es instalarla en un servidor conectado a la WWW (World Wide Web: la telaraña mundial), la red de servidores interconectados entre sí que nos permite acceder a cualquier página en cualquier parte del mundo, y navegar a tra-vés de ellas.

Los distintos canales para colocar una página en la red son:

- Los servidores de las instituciones oficiales y académicas a sus miembros, para la difusión de información relacionada con esos organismos.

- Los proveedores comerciales de acceso a Internet, o ISPs (Internet Service Providers) que ceden frecuentemente a sus usuarios un espacio determina-do en sus servidores, para que puedan colocar sus páginas personales, bien sea gratuitamente o por una tarifa determinada.

- Las empresas comerciales que, sin ser proveedores de acceso a Internet, se dedican a alquilar espacio para la colocación de páginas, de carácter perso-nal o comercial.

- Ciertos servidores que conceden de una manera gratuita espacio para la co-locación de páginas personales. Uno de los más populares es Geocities, que concede un espacio de 2 megas. Sus páginas explicativas está en inglés, pe-ro se pueden consultar las instrucciones en castellano en la FAQ de WEB-ES, de Alonso Alvarez.

6.2.2. ¿Cómo se envían las páginas al servidor?

Una vez de haber confeccionado en nuestro disco duro la página Web, y estan-do ya lista para ser colocada en el servidor, surge la cuestión de cómo proceder para enviarla.

No se pueden dar aquí unas instrucciones precisas, pues depende de la manera establecida para ello por cada servidor. Generalmente se hace utilizando un pro-grama de FTP (programa de envío y recepción de ficheros). Pero antes habrá que consultar en las páginas del servidor si existen las instrucciones pertinentes para el envío, o en su defecto realizar la consulta por correo-e o por teléfono.

83

6.2.3. Promoción del sitio web

No basta con colocar nuestra página en la red. Por muy interesante que sea su contenido, y por bien diseñada que esté, para que los demás puedan acceder a ella tienen que tener conocimiento de su existencia. Es una labor nuestra la de promo-cionar la página, es decir, darla a conocer por todos los medios posibles.

Figura 6_1: El sitio Open directory. http://www.dmoz.org.

El paso más eficaz es dar de alta a nuestra página en sitios Web especializados en almacenar y organizar direcciones. Estos sitios sirven como bases de datos a donde acude la gente en búsqueda de información sobre dónde encontrar las pági-nas del Web deseadas. Además, dar de alta una página en los buscadores es total-mente gratuito.

Es conveniente incluir la dirección (o URL) de la página en la firma de nuestro programa de corre-e, así como también en el de lectura de newsgroups, y mejor aún si además se incluye su título, o una frase que indique el contenido de la página. De esta manera se incita a visitarla al que esté interesado en ese tema.

En líneas generales, se pueden distinguir dos tipos de estos sitios:

- Los que están organizados como directorios, es decir, que catalogan las pá-ginas por su contenido en categorías y sub-categorías. Para darse de alta en ellos, es necesario situarse primero en la categoría apropiada al contenido de nuestra página. Estos sitios sólo contienen las páginas de quienes se hayan dado de alta en ellos de manera voluntaria.

- Otros sitios, los llamados motores de búsqueda (search engines) actúan de una forma completamente distinta. Utilizan unos programas (llamados co-múnmente robots o arañas) que tienen la misión de rastrear continuamente el Web en búsqueda de páginas nuevas o renovadas. Para ello, van nave-gando de URL en URL a través de los enlaces que encuentran en las pági-nas, con la intención de catalogar el número máximo de ellas.

Si uno de estos robots visita nuestra página del Web, grabará el texto completo de cada una de las páginas (la principal y las sub-páginas). De es-ta manera, todas las palabras de todas las páginas de nuestro sitio son in-corporadas a su base de datos. Cuando luego alguien haga una consulta en estos motores de búsqueda introduciendo una palabra que coincida con al-

84

guna de ellas, presentará nuestra página del Web como un resultado de la búsqueda.

Aparte de esto, también se dedicará a visitar todos los enlaces que vaya encon-trado por las distintas páginas. Es de esta manera cómo catalogan páginas que no han sido dado de alta de manera voluntaria en ellos. Sin embargo, es conveniente que registremos nosotros mismos nuestra página en estos motores de búsqueda para acelerar el proceso, y no tener que esperar a que la encuentren ellos por medio de enlaces de otras páginas a la nuestra.

Además, una vez que los robots han localizado un sitio del Web, lo visitarán pe-riódicamente para renovar la información grabada.

¿Qué es la popularidad?

La popularidad es un termino que se mide por el número de enlaces que apuntan a una determinada página, cuántos links de otros webs tengo apuntando hacia mi sitio web.

El índice de popularidad en internet se mide por el número de enlaces desde otro sitio.

Muchos buscadores analizan la popularidad y en función de ella incrementan el ranking. Uno de los principales buscadores que tiene en cuenta la popularidad para el posicionamiento es Google. Para conseguir popularidad uno de los métodos em-pleados es negociar links de calidad con otras páginas web que estén relacionadas con el tema de tu sitio web y que contengan palabras clave semejantes, es decir, puedes incrementar la popularidad de tu página web mediante la colocación de links en otras paginas y si son del mismo tema mayor influencia tienen éstas.

Quiere decir que cuántas más web tengan un link hacia tu web, aparecerás más arriba en los buscadores. No sólo tienen en cuenta la cantidad de links, sino la calidad de los mismos, o sea de dónde vienen esos links.

Puedes medir la popularidad de tu página y la de tu competencia de forma gra-tuita en, http://www.linkpopularity.com buscando los sitios que tienen enlaces al tuyo en Altavista, Google y Hotbot.

85

El la interfaz del buscador Google se puede determinar directamente desde la caja de búsqueda tecleando link:tudominio.com, como puede verse en el ejemplo siguiente:

Nota: Se puede emplear este método para determinar también donde están los enlaces de tu competencia y revisar si puedes incluir el tuyo en uno de ellos.

Estructura adecuada.

Una buena estructura del sitio web y una correcta utilización de las etiquetas que nos ofrece HTML, conseguirá que nuestro web, sea indexado correctamente por los buscadores.

¿Por qué la correcta utilización de las etiquetas en HTML es algo primordial pa-ra el posicionamiento en buscadores? Porque el buscador sigue el código HTML generado por nuestra web, y para hacerlo (y posteriormente indexar nuestra web) tiene que poder seguirlo correctamente. Por lo tanto, la ordenación del sitio web usando las etiquetas H1, H2, H3,.. (por ejemplo) conseguirá que el buscador clasi-fique lo que son títulos de lo que es párrafo, y así asignarle más importancia a lo que debe tenerlo, en este caso, el titulo. Otra etiqueta olvidada es la etiqueta ALT,

86

poco usada y realmente importante pues google (por ejemplo) ignora las imágenes (también el javascript,...), y solo las toma en cuenta cuando le asociamos un texto descriptivo, en este caso, asocia el texto a la imagen. Básicamente, una imagen con un ALT asociado, prácticamente es ignorada por Google, por lo que asociar a esta imagen un enlace, será ya definitivo para que Google le preste atención.

En resumen, utiliza adecuadamente las etiquetas HTML. Asocia enlaces a las imágenes y no intentes abusar de las etiquetas H1, H2,.. úsalas correctamente, su abuso esta penalizado por los buscadores.

El PageRank, ¿qué es?, ¿para qué vale?

Muchas veces determinar la popularidad de una página web para ser mostrada en las búsquedas es difícil, Google usa para ello el PageRank, un sistema de "pun-tuación" de webs, en función de su popularidad, otros buscadores usan parámetros parecidos.

PageRank se basa en la naturaleza democrática de la web y usa su extensa es-tructura de vínculos como un indicador del valor de una página individual. Google interpreta un vínculo desde la página A hacia la página B como un voto de la pági-na A por la página B. Pero Google revisa otras cosas aparte del número de votos o de vínculos que una página recibe, puesto que también analiza la página que emite el voto. Los votos emitidos por páginas que son en sí mismas "importantes" pesan más y ayudan a convertir a otras páginas también en "importantes".

Los sitios importantes y de alta calidad reciben un PageRank más alto, que Google recuerda cada vez que realiza una búsqueda. Por supuesto, las páginas im-portantes no significan nada para usted si no coinciden con su búsqueda. Por eso, Google combina PageRank con sofisticadas técnicas de búsqueda de texto para encontrar páginas que sean importantes y a la vez relevantes para su consulta. Google va más allá de la cantidad de veces que un término aparece en una página y examina todos los aspectos del contenido de la página (y el contenido de las pági-nas vinculadas) para determinar si es una buena coincidencia para su consulta.

Por lo que conseguir un buen posicionamiento en Google, no solo será necesa-rio tener un sitio web interesante, sino tener un sitio web referido desde otros sitios web, y si es posible con PageRank mayor que el de tu web, consiguiendo que Goo-gle piense que tu web es más importante.

¿Como medir el PageRank de una pagina? para ello Google ha facilitado una barra de herramientas que instalas en tu navegador y te va informando de las carac-terísticas de cada web, incluido el PageRank. La puedes encontrar gratuitamente en la siguiente url: http://toolbar.google.com/intl/es/install.

87

Mejora del PR: creación de un sistema de enlaces.

Hemos visto que el PageRank es el índice de importancia que otorga Google a una página web y cuanto mas importante sea una pagina, mejor posicionada estará en su base de datos, por lo que tendremos que conseguir que webs importantes nos enlacen para disponer de un mejor PR.

Para la creación de un buen sistema de enlaces, que nos proporcionen Page-Rank, tendremos diversas opciones:

- Conseguir una web con contenidos interesantes, actualizados, exclusi-vos,.. en definitiva lo que busca el navegante. Así, otros webmasters nos tomaran como referencia y apuntaran hacia nuestra web, aportando a sus visitantes nuestros contenidos.

- Promocionar nuestra web en directorios de enlace directo. ¿Qué es es-to? Son directorios, no buscadores, que ejercen de enormes bases de datos, y que nos enlazan directamente, es decir, que no camuflan nuestra url entre variables y redirecciones.

- Apuntarse a foros sobre temas relacionados con nuestro web, y firmar nuestros mensajes con nuestra url. No basta con que nos enlacen, si que-remos obtener también un buen posicionamiento de las palabras clave las temáticas de las webs que nos enlazan deben ser similares.

- Publicar artículos o pequeños tutoriales en revistas online, portales,.. firmándolos con nuestra URL.

- Enviar un correo-e de presentación a webmasters con temáticas pareci-das a las nuestras, ofreciéndoles un intercambio. Este es un aspecto delica-do, porque no queremos caer en el spam, por lo que tendremos que ser correctos, educados e intentar que el intercambio sea eso, una propuesta se-ria y apetecible para cualquier webmaster.

Consejos para facilitar la labor a los motores de búsqueda

Hay ciertas cosas que podemos hacer para conseguir que nuestra página sea ca-talogada de la manera más adecuada en estos motores de búsqueda:

1. Utilizar palabras clave dentro de la etiqueta <TITLE>, haciendo que sea lo más descriptivo posible, porque cuando un motor de búsqueda presenta una página concreta como resultado de una búsqueda, lo hará reproducien-do las palabras que ha encontrado dentro de la etiqueta <TITLE> de esa página.

Por ejemplo, en vez de titular una página como <TITLE> Interacción 2004 </TITLE>, es más eficaz hacerlo como <TITLE> Interacción 2004. V Congreso Interacción Persona-Ordenador </TITLE>.

88

2. Utilizar etiquetas <META>. Etiquetas html que se colocan en la cabecera de la página (en la zona entre <HEAD> y </HEAD>), que sirven para su-ministrar una información detallada del contenido de una página, con lo que se obtiene un control mayor de cómo será catalogada la página. No to-dos los motores de búsqueda hacen uso de estas etiquetas, pero si las po-nemos, las haremos mucho más accesibles a los motores de búsqueda que sí las utilizan.

Hay diferentes tipos de esta etiqueta, pero las que nos interesan ahora son la que hace referencia a la descripción (description) de la página y la que presenta las palabras clave (keywords) con las que la gente buscará una página como la nuestra en los motores de búsqueda.

Veamos por ejemplo las utilizadas para este manual: <meta name="description" content="V Congreso Internacional Interac-

ci&oacute;n Persona-Ordenador"> ">

En este caso, lo que está incluido en el atributo CONTENT (contenido) es lo que presentará el motor de búsqueda, además del título de la página.

<meta name="keywords" content="HCI Congreso Conference Human-Computer Interaction IPO Interacci&oacute;n Persona-Ordenador CHI Usabilidad Accesibilidad">

En este otro caso, se incluyen en el atributo CONTENT las palabras claves para la búsqueda de nuestra página. Se pueden poner tantas como se crea oportuno, incluso sus plurales. La utilización de estas etiquetas META es especialmente conveniente para las páginas que hacen uso de frames (ya que la página inicial es la de definición de los frames, que no tiene ninguna indicación del contenido de las otras páginas). También es muy convenien-te para los que utilizan Javascript en el comienzo de sus páginas, ya que el código emp leado puede tener cientos de palabras, y los robots están pro-gramados para dar mayor énfasis a las palabras que encuentran al principio que las situadas al final.

3. Poner un resumen del contenido de la página en el comienzo del texto. Hay motores de búsqueda que utilizan las primeras 25 palabras del texto de una página a modo de presentación de su contenido. Conviene, por tanto, hacer un breve resumen al inicio de la página, lo que por otra parte es siempre una práctica muy aconsejable.

4. Utilizar el atributo ALT en las imágenes iniciales. Dentro de la etiqueta de las imágenes se puede añadir el atributo ALT que sirve para poner un texto a la imagen, que será visto únicamente por quienes utilizan los navegado-res en forma de sólo texto.

89

Hay motores de búsqueda que toman en cuenta el texto que encuentran de esta manera en las imágenes (sobre todo las iniciales) para hacer una descripción del sitio o para suministrar las palabras clave

Google.

La información de este apartado está basada en el material del sitio web http://www.webpromocion.net

Hoy por hoy, aparecer en Google, es tener presencia en Internet. Este buscador americano, se ha convertido en el referente único de Internet, consiguiendo que la competencia casi no disponga de cuota de mercado. Si miramos las estadísticas de nuestro web, comprobaríamos que más del 80% de las visitas que recibe nuestro web, desde buscadores, provienen de Google, lo que deja en muy mal lugar al resto de buscadores.

La tecnología de Google le permite visitar las webs casi a diario, ofreciendo re-sultados muy actualizados. Otro aspecto importante es el PageRank, por el que Google "puntua" las paginas webs, ofreciéndoles valores de 0 a 10, y considerando según este valor su importancia.

Otra peculiaridad de Google, es el ignorar casi totalmente las Meta-Tag de las paginas webs, teniendo en cuenta solamente el titulo, y centrándose en el texto que encuentra en la web.

Herramientas de Google: • Google-dance: Herramienta de Google que te permitirá consultar sus data-

centers.

• Google Toolbar: Barra de herramientas con la que podrás ver el PR de las webs.

• Google adwords: Alta de pago de google, que podremos utilizar para otros fines.

• Google Stats: Estadísticas detalladas sobre las visitas de Google a tu web.

Google Dance. Herramienta de Google para consultar en línea los nueve datacenters que Goo-

gle tiene repartidos por el mundo. Con esta herramienta podrás comprobar las ac-tualizaciones de los datacenters, observando cuales se han actualizado y cuales no.

Este "fenómeno" de resultados distintos en diferentes datacenters, es denomina-do "dance", periodo en el que google actualiza su base de datos, y empezara a mos-trar resultados actualizados.

90

En el momento en que todos los data centers muestren los mismos resultados, significara que el "dance" ha concluido.

• Google-dance: http://www.google-dance.com

Google Toolbar. Todos sabemos que la popularidad por enlaces es importante, sobre todo para

goggle. Muchos websmasters tratan de mejorar su popularidad uniéndose a pro-gramas de intercambio de enlaces (links). Pero Google presta mayor atención al tipo de página que enlaza que al volumen de enlaces. O sea una página que enlaza a la suya y es de la misma temática representa para Google un mayor peso.

Google te brinda una herramienta para conocer cuales páginas enlazan a simila-res a la suya y le dan buen ranking. El primer paso consiste en bajarse la barra en http://toolbar.google.com/ Con esta herramienta instalada, se muestra un icono que representa el ranking de la página (de 1 a 10) para cada página que se visita. Signi-fica esto que si se realiza una búsqueda en Google por su palabra o frase destino, entonces debe concentrarse en estudiar las páginas a las que Google le da una bue-na popularidad, revisando en su barra los vínculos de referencia anteriores, es decir las páginas que refencian a la que se examina y que precisamente son las que le imprimen popularidad en Google. Entonces deberá tratar de conseguir que se in-cluya su página objetivo en ellas, bien haciendo su inclusión directa si tienen la opción de "añadir página" o convenciendo a los Webmasters de las mismas para que la incorporen.

Con esta aplicación de Google podrás consultar online el PageRank de todas las paginas webs que visites. También ofrece muchos más servicios como:

- Comprobar los backlinks de una web

- Comprobar la caché de una web

- Paginas similares

Tantas ventajas tienen un inconveniente, Google observará que paginas visitas, aunque se compromete a no identificar al usuario, sino, solo almacenar las paginas webs con fines estadísticos.

- Google-Toolbar: http://toolbar.google.com

Google Adwords. Google define su sistema de enlaces patrocinados de la siguiente forma: El pro-

grama publicitario de AdWords de Google ofrece ventajas inéditas con respecto a otros sistemas de publicidad en línea. AdWords le permite manejar su propia cuen-ta, controlar sus gastos y establecer el presupuesto diario que desea gastar al día.

91

Así mismo, con el sistema de Coste por clic (CPC), usted paga únicamente cuando los usuarios hacen clic en su anuncio. Al fin y al cabo, lo que importa son los re-sultados.

En definitiva un sistema de pago por click, con el que promocionar nuestra pa-gina web. ¿Pero podemos utilizar esta herramienta de forma gratuita? Esta herra-mienta en si no, pero podemos utilizar sus recursos para nuestro propio uso de forma gratuita. Es decir, google adwords incorpora un buscador de palabras más buscadas en internet, lo que nos permitirá encontrar las palabras clave que mas buscan los internautas y que tengan que ver con la temática de nuestro web.

En la práctica, un servicio que otras empresas proporcionan pagando, google lo ofrece de forma gratuita.

- Buscador de palabras clave de Google: https://adwords.google.com/

- https://adwords.google.com/select/main?cmd=KeywordSandbox

Google Stats. No es un programa ofrecido por Google, es ni más ni menos, que un interprete

de estadísticas, que se centra en las visitas de los robots de indexación. Hace una especial mención a Google, pero en su base de datos están los robots de los busca-dores más importantes.

Este programa desarrollado en PHP, nos permitirá saber que robots nos han vi-sitado, a que hora, que paginas han visto, y todo ello, ordenado por buscadores, permitiéndonos generar un grafico mensual de visitas, etc...

Una herramienta fundamental para controlar a los buscadores.

- Google-Stats: http://www.googlestats.com

92

6.2.4. Post-lanzamiento

No debemos confundir esta etapa con el mantenimiento pues su misión es muy distinta. Esta etapa en el paradigma web es muy determinante, ya que el objetivo principal es analizar el uso real de nuestro sitio por parte de los usuarios. Nos inte-resará saber si acceden a él, qué páginas son las más accedidas, que caminos son los más recorridos, desde dónde acceden nuestros usuarios, que motivaciones tie-nen, etc. Una técnica muy adecuada para evaluar esta información es la conocida con el nombre de Logging que, partiendo de la información que los usuarios van dejando en nuestro servidor, podemos encontrar respuesta a muchas de las pregun-tas anteriormente formuladas y con ello mejorar la usabilidad del sitio.

93

7. Métodos de evaluación generales

7.1. Grupo de discusión dirigido (Focus Group)

El focus group [6] o grupo de discusión dirigido es una técnica de recogida de datos donde se reúnen de 6 a 9 usuarios para discutir aspectos relacionados con el sistema. Un evaluador experto en usabilidad y/o accesibilidad (dependiendo de lo que deseemos evaluar) hace las veces de moderador. Éste preparará previamente la lista de aspectos a discutir y recoger la información que necesita de la discusión.

Esto puede permitir capturar reacciones espontáneas del usuario e ideas que evolucionan en el proceso dinámico del grupo.

El método puede ser aplicado en cualquiera de las fases de ciclo de vida del proceso de software, aun así en las que más se ha aplicado (y por tanto de la que se tiene mayor experiencia) es en la fase de lanzamiento.

7.1.1. Procedimiento

Los procedimientos generales para dirigir un focus group son:

- Localizar usuarios representativos (típicamente 6 a 9 por focus group) que quieran participar.

- Seleccionar un moderador.

- Preparar una lista de temas a ser discutidos y objetivos a asumir por los temas propuestos.

- Controlar la discusión sin inhibir el flujo libre de ideas y comentarios.

- Asegurar que todos los participantes contribuyen a la discusión.

- Procurar que no haya un participante que domine la discusión.

- Conservar la discusión que discurra libremente y no estructurada, pero procura que siga un esquema planeado.

- Escribir un resumen de las opiniones que han prevalecido y comentarios críticos de la sesión incluyendo cuotas representativas.

94

Figura 7_1: La imagen nos muestra a una evaluadora experta en usabilidad y un grupo de usuarios representativos realizando un Focus Group de un sitio web para una web de atenciones personales del ayuntamiento de Lleida.

7.1.2. Aspectos a considerar

Al dirigir un focus group hay una serie de aspectos importantes a tener en cuenta:

- Tener más de un grupo principal, puesto que el resultado de una sola se-sión puede no ser representativo y una sola discusión pudo haberse centra-do en un subconjunto de las ediciones o de los aspectos de menor importancia del sistema.

- Es preferible que el moderador tenga dotes dinamizadores y comunica-tivos. No es tan simple como preparar las preguntas, porque el moderador necesita facilitar y dirigir la discusión en tiempo real.

- Debe dudarse siempre de los datos recogidos porque debido a su naturale-za desestructurada y de flujo libre tienden a tener una validez cuestionable y son muy difíciles de analizar.

7.2. Evaluación heurística

La evaluación heurística fue desarrollada por Nielsen y Molich [31]. La evalua-ción heurística consiste en analizar la conformidad de la interfaz con unos princi-pios reconocidos de usabilidad (heurística) mediante la inspección de varios evaluadores expertos. Se recomienda normalmente utilizar de tres a cinco evalua-dores, ya que se consideran suficientes y la inclusión de un mayor número de los mismos no garantiza una mejora en el resultado.

95

La evaluación heurística se lleva a cabo realizando por parte de cada evaluador una revisión de la interfaz. Cuando se han terminado todas las evaluaciones se permite a los evaluadores comunicar los resultados y sintetizarlos. Este procedi-miento es importante para asegurar evaluaciones independientes e imparciales de cada evaluador. Los resultados de la evaluación se pueden registrar como informes escritos de cada evaluador o haciendo que los evaluadores comuniquen verbalmen-te sus comentarios a un observador mientras inspeccionan la interfaz.

Figura 7_2: Experta en usabilidad realizando la evaluación heurística de la web del CEL

Típicamente, una sesión de evaluación heurística debe durar de 1 a 2 horas, en caso de que se realice el test de una interfaz muy compleja se puede dividir en va-rias sesiones que aborden diferentes aspectos de la interfaz.

El resultado de una evaluación heurística es una lista de problemas de usabili-dad que han sido encontrados en el diseño en opinión de cada evaluador.

10 reglas heurísticas de usabilidad de Nielsen

El conjunto revisado de reglas heurísticas de usabilidad a partir del análisis de 249 problemas de usabilidad es el siguiente [6]:

1. Visibilidad del estado del sistema. El sistema debe siempre mantener a los usuarios informados del estado del sistema, con una realimentación apro-piada y en un tiempo razonable.

2. Utilizar el lenguaje de los usuarios. El sistema debe hablar el lenguaje de los usuarios, con las palabras, las frases y los conceptos familiares, en lu-gar de que los términos estén orientados al sistema. Utilizar convenciones del mundo real, haciendo que la información aparezca en un orden natural y lógico.

3. Control y libertad para el usuario. Los usuarios eligen a veces funciones del sistema por error y necesitan a menudo una salida de emergencia cla-

96

ramente marcada, esto es, salir del estado indeseado sin tener que pasar por un diálogo extendido. Es importante disponer de deshacer y rehacer.

4. Consistencia y estándares. Los usuarios no deben tener que preguntarse si las diversas palabras, situaciones, o acciones significan la misma cosa. En general siga las normas y convenciones de la plataforma sobre la que se está implementando el sistema.

5. Prevención de errores. Es importante prevenir la aparición de errores que mejor que generar buenos mensajes de error.

6. Minimizar la carga de la memoria del usuario. El usuario no debería te-ner que recordar la información de una parte de diálogo a la otra Es mejor mantener objetos, acciones, y las opciones visibles que memorizar.

7. Flexibilidad y eficiencia de uso. Las instrucciones para el uso del sistema deben ser visibles o fácilmente accesibles siempre que se necesiten. Los aceleradores no vistos por el usuario principiante, mejoran la interacción para el usuario experto de tal manera que el sistema puede servir para usuarios inexpertos y experimentados. Es importante que el sistema per-mita personalizar acciones frecuentes.

8. Los diálogos estéticos y diseño minimalista. No deben contener la infor-mación que sea inaplicable o se necesite raramente. Cada unidad adicio-nal de la información en un diálogo compite con las unidades relevantes de la información y disminuye su visibilidad relativa.

9. Ayudar a los usuarios a reconocer, diagnosticar y recuperarse de los errores. Que los mensajes de error se deben expresar en un lenguaje claro (no haya códigos extraños), se debe indicar exactamente el problema, y deben ser constructivos.

10. Ayuda y documentación. Aunque es mejor si el sistema se pueda usar sin documentación, puede ser necesario disponer de ayuda y documentación. Ésta ha de ser fácil de buscar, centrada en las tareas del usuario, tener in-formación de las etapas a realizar y que no sea muy extensa.

7.3. Recorrido de la usabilidad plural

Este método es debido a Bias [31] y fue desarrollado en los laboratorios IBM. Comparte algunas características con los recorridos tradicionales, pero tiene algu-nas características propias que lo definen. Estas características son las siguientes:

1.- Participantes: Este método se realiza con tres tipos de participantes, usuarios representativos, desarrolladores y expertos en usabilidad, que conforman todos los actores implicados en el producto.

97

2.- Las pruebas se realizan con prototipos de papel u otros materiales utilizados en escenarios. Cada participante dispone de una copia del escenario de la tarea con datos que se puedan manipular.

3.- Todos los participantes han de asumir el papel de los usuarios, por tanto, aparte de los usuarios representativos que ya lo son, los desarrolladores y los exper-tos en usabilidad también lo deben asumir.

4-. Los participantes deben escribir en cada panel del prototipo la acción que tomarán para seguir la tarea que están realizando, escribiendo las respuestas lo más detalladas posibles.

5-. Una vez que todos los participantes han escrito las acciones que tomarían cuando interactuaban con cada panel, comienza el debate. En primer lugar deben hablar los usuarios representativos y una vez estos han expuesto completamente sus opiniones, hablan los desarrolladores y después los expertos en usabilidad.

7.4. Análisis de logs

7.4.1. ¿Qué son los logs?

Cada visitante que accede a nuestro sitio web deja un rastro físico de su visita. Estos "rastros" quedan almacenados en el servidor para poder ser consultado, ser filtrado y ser recopilado con la intención de obtener información sobre la cual está lo que está sucediendo.

El formato típico de un log es el de una cadena de texto que almacena la infor-mación sobre las peticiones que efectúa el usuario en el servidor. Por lo tanto, cuando un navegante accede en nuestra página de inicio, se escribirá una línea por cada documento que solicite, es decir, escribirá una línea al solicitar home.html otra para imatge.gif. etc. y así sucesivamente para cada elemento de la página solicitada.

Por lo tanto, efectuando un correcto análisis de los logs, dispondremos de una información muy valiosa que nos permitirá desde detectar problemas de usabilidad hasta determinar perfiles de usuario o fidelitzar clientes.

7.4.2. Características del análisis de logs

- Más económico que realizar un método de evaluación.

- No se necesita la presencia física de los usuarios o un espacio especial para la tarea. Los datos se extraen en un formato estándar. Podemos comparar los datos entre meses, días, semanas, países, etc.

- Los resultados se obtienen de manera instantánea. No hay que esperar a uno análisis especial de expertos para entender el que ha pasado o no se necesitan transcripciones, ver cintas de vídeo, etc.

98

- Permite tener al usuario en su entorno habitual de uso (el log se recoge con el usuario en su ordenador sin estar siendo observado, lo que ofrece datos más reales sobre el uso).

- Muestras amplias (normalmente estaremos hablando de miles de usuarios).

- Muestreo de usuarios a lo largo de amplios plazos en el tiempo.

- El usuario necesita un poco de experiencia en Internet, ya sea por que ne-cesitara, o descargar software especial y/o manejar formularios.

- Se detecta fácilmente el verdadero uso del lugar. (Páginas más vistas, pa-labras más buscadas, etc.)

7.4.3. Información del logs

La información que nos proporciona un log es la siguiente: 196.40.43.218 - - [31/May/2002:00:11:52 +0200] "GET /faq.php HTTP/1.0" 200

25258 "http://www.google.com/search?q=comercio+electronico Mozilla/4.77 [en] (Win98; U)"

TABLA 7_1: INFORMACIÓN DE UN ARCHIVO DE LOG.

196.40.43.218 IP1. o dirección física del visitante - Nombre del Usuario - Contraseña [31/May/2002:00:11:52 +0200] Fecha y hora de visita GET /faq.php HTTP/1.0" Archivo solicitado 200 ID de respuesta. Nos permite conocer errores y posibles debilidades dentro de

la arquitectura (2xx - éxito, 3xx - redirección, 4xx - error, 5xx - fallo del servidor). Estos errores se pueden producir en una entrada de datos, cuando la información no se ha encontrado pero se está disponible, cuándo la informa-ción se ha solicitado pero no está disponible, por errores del sistema o enlaces perdidos

25258 Volumen de transferencia (25258) - número de bytes enviados - que tiene que tenerse presente en el momento de medir el tiempo de permanencia y número de páginas vistas. Cuando más peso tenga que bajar un usuario menos tiempo estará observando el contenido y más reticencia a continuar navegando

"http://www.google.com/search? q=comercio+electronico"

“referrer”2 que es la página de la cual proviene el navegante

"Mozilla/4.77 [en] (Win98; U)" El navegador (Mozilla/4.77) y el sistema operativo (Win 98) utilizados para visualizar la página solicitada

7.4.4. ¿Para qué puede servir el análisis de logs?

No es fácil extraer conclusiones de un inmenso conjunto de líneas de texto (re-cordamos que se escribe una línea por cada objeto - documento, imagen, etc. - soli-

1 Internet Protocolo 2 Página desde la que se pide el archivo.

99

citado), a pesar de la ayuda que ofrecen paquetes de software especializados en esta tarea. Es necesario un amplio conocimiento de Internet y de comportamientos de usuario para poder extraer conclusiones válidas que aporten veracidad en el estu-dio.

El análisis de un conjunto de logs continuado en el tiempo proporciona infor-mación REAL y CONCISA sobre lo que está ocurriendo en nuestro sitio web. Sa-biendo extraer la información de manera adecuada, podremos conocer:

- Cuáles son los servicios que nuestros visitantes consideran más atractivos.

- Qué secciones no están siendo visitadas.

- La efectividad de nuestras acciones comunicativas/promocionales, al saber de donde proceden las visitas.

- Posibles errores de programación, tan difíciles de localizar a veces en luga-res con mucha profundidad.

- La efectividad de nuestras campañas de posicionamiento en buscadores, identificando las palabras por las cuales somos encontrados en cada uno de los motores de investigación.

7.4.5. ¿Que necesito para hacer un análisis de logs?

Para hacer un análisis de logs hay que disponer, por una parte del fichero que contiene los logs y por otra la aplicación que analice este fichero.

El fichero de logs es un fichero que está almacenado en el servidor donde está nuestro sitio web y que no es fácil de conseguir, debido a que no siempre tenemos acceso a éste para conseguirlo.

Una vez disponemos del fichero de logs, necesitemos una aplicación que nos es-tudie este fichero y podamos extraer aquello más importante y que nos pueda inte-resar. Algunas aplicaciones, entre otros, por hacer uno análisis de logs son Analog [32], WebTrends Log Analyzer [33], etc.

Para hacer un análisis hace falta tener claros algunos conceptos utilizados a las estadísticas y que su mal uso puede generar conflictos. Algunos de estos conceptos los definimos a continuación [17]:

- Accesos: Un acceso es cualquier solicitud hecha al servidor en el cual está conectado. La solicitud puede incluir cualquier elemento: páginas HTML, imágenes, ficheros de audio, etc. Cada línea válida en el log del servidor es considerada un acceso. Esta cifra representa el total de solicitudes realiza-das en el servidor durante un periodo de tiempo determinado.

- Archivos: Algunas solicitudes hechas al servidor requieren que éste envíe "alguna cosa" como respuesta al cliente, por ejemplo, una página HTML o imagen gráfica. Cuando eso pasa, esta respuesta es considerada un archivo.

100

- Página: Es considera una página cualquier documento HTML o cualquier salida que se muestre como documento HTML. No incluye otros documen-tos ubicados dentro del documento, como imágenes gráficas, clips de au-dio, etc. Lo que actualmente constituye una página puede variar de un servidor a otro, aunque está más o menos establecido como página cual-quier extensión .HTM. HTML, etc.

- Cliente: Cada solicitud realizada en el servidor procede de un cliente único en el cual se identifica para su dirección IP. El número de clientes muestra el número de direcciones IP que hacen solicitudes al servidor durante el pe-riodo de tiempo analizado. No es el número exacto de usuarios individua-les que visitaron el servidor, el cual es imposible de determinar utilizando únicamente los logs y el protocolo HTTP.

- Visitas: Se calcula en base al tiempo que interviene entre una solicitud y otra realizada desde una dirección IP determinada.

101

8. Referencias

1. Lorés, J. (editor) [cdrom] (2002). Introducción a la interacción persona-ordenador. Editado por Asocia-ción Interacción Persona-Ordenador, AIPO. ISBN: 84-607-2255-4

2. Granollers, T.; Lorés, J.; Perdrix, F. (2003). Usability Engineering Process Model. Integration with Soft-ware Engineering: Procs. of HCI-Intl’03, Creta (Grecia).

3. Manchón, E. (2002, 11 febrero). Resultados encuesta perfil profesional AI y usabilidad iberoamericanos: España, Portugal y Latinoamérica. [en línea]. [Consultado: 25 marzo 2004]. Disponible a Internet: http://www.ainda.info

4. Garton, L.; Haythornthwaite, C.; Wellman, B. (1997, junio). Studying on line Socialnetworks. [en li-nea]. Journal of Computer Mediated Communication. [Conslutado: 25 marzo 2004]. Revisado en Abril 2002. Disponible en Internet: http://ascusc.org/jcmc/vol3/issue1/garton.html

5. Brink, T.; Gergle D.; Wood, S.D. (2002). Design Web Sites that Work: Usability for the Web. Mor-gan-Kaufmann.

6. Nielsen, J. (1993). Usability Engineering. AP Professional. Boston, MA.

7. Mayhew, D.J. (1999). The Usability Engineering Lifecycle: A practitioner’s Handbook for User Interface Design. Morgan Kaufman.

8. Kotonya, G.; Sommerville I. (1997). Requirements Engineering. Processes and Techniques. JohnWiley.

9. Duran, T. (2002). Un entorno metodológico de ingeniería de requisitos para sistemas de información. Tesis Doctoral. Universidad de Sevilla (España).

10. Asociación para la Investigación de los Medios de Comunicación (2003, noviembre). Audiencia de Internet. [en línea]. [Consultado: 15 diciembre 2003]. Disponible en Internet: http://download.aimc.es/aimc/03internet/internet303.pdf

11. U.S. Census Bureau [en línea]. [Consultado el 23 enero 2003]. Disponible en Internet: http://www.census.gov

12. Hix, D.; Harston; H. Rex. (1993). Developing User Interfaces: Ensuring Usability Through Product & Process. John Wiley and Sons.

13. Fuccella, J. (1997). Using user centered design methods to create and design usable Web sites. Proceedings of the 15th annual ACM international conference on Computer documentation.

14. Bevan, N. (2000, 19 noviembre). Stakeholder meeting. [en línea]. Serco Usability Services Re-search. [Consultado: 25 marxo 2004]. Disponible en Internet: http://www.usability.serco.com/trump/methods/recommended/stakeholder.htm

102

15. Wilson, R. F. (2001). Planning Your Internet Marketing Strategy: A Doctor Ebiz Guide. John Wiley & Sons.

16. Sterne, J. (2002). Web Metrics: Proven Methods for Measuring Web Site Success, John Wiley & Sons.

17. Coutin, A. (2002). Arquitectura de la Información para sitios Web. Anaya Multimedia.

18. Pouloudi, A. (1999). Stakeholder Analysis as a Front-End to Knowledge Elicitation. At & Society, XI, pág. 122-137.

19. Schneider, G.; Winters, J.P. (1998). Applying Use Cases: A Practical Guide: Reading. MA: Addison-Wesley.

20. Constantine, L.L. (1995). Essential Modeling: Use Cases for user Interfaces.:ACM Interactions.

21. Wharton, C. et al. (1994). The Cognitive Walkthrough Method: a Practitioner's Guide. En Nielsen, J. (1994) Usability Inspection Methods. John Wiley & Sons, Nueva York, 105-140.

22. Annet, J.; Duncan, K. (1967). Task analysis and training in design. Occupational Psychology, p. 41.

23. Paternó, F. (2000). Model–based design and evaluation of interactive application. Springer–Verlag. Tam-bién disponible en: http://giove.cnuce.cnr.it/ConcurTaskTrees.html

24. Gerrit, C. Van der Veer; Stary, C. (1999). Task analysis meets prototyping: seeking seamless UI-development. Tutorial Session of Conference on Human Factors and Computing Systems, CHI99.

25. Rosenfeld, L.; Morville, P. (2002). Information Architecture for the World Wide Web. O’Reilly (2nd Ed.).

26. Rosenfeld, L. (2002). The Emergence of Information Architecture, Yggdrasil, Sandefjord, Norge.

27. Roberston, J. (2001). Intranet Design Series: Information design using card sorting. Information & De-sign.

28. McDonald, J.; Dearholt, D.; Paap, K.; Schvaneveldt, R. (1986). A Formal Interface Design Method-ology Based on User Knowledge. Procs. of CHI’86, pág. 285-290.

29. Toro, J.A. (2002). CardZort: computer application that runs card sorting exercises. [en línea]. [Consulta-do: 25 marzo 2004]. Disonible en Internet: http://condor.depaul.edu/~jtoro/cardzort/cardzort.htm

30. Nielsen, J. (1996, junio). Inverted Pyramids in Cyberspace. [en línea] Jakob Nielsen’s Alertbox for June 1996. [Consultado: 25 marzo 2004]. Actualizado en el 2003. Disponible en Internet: www.useit.com/alertbox/9606.html

31. Nielsen, J.; Molich, R. (1990). Heuristic evaluation of user interfaces. Proc. ACM CHI'90 Conf. (Seat-tle, WA, 1-5 April), 249-256.Bias, R.; Rietmeyer, P.B. 1995. Usability Support Inside and Out. Inte-ractions ACM Press.

32. Analog (2004, 22 febrero). Analog: The most popular logfile analyser in the world. [en línea]. Herramienta software disponible en Internet: http://www.analog.cx

33. WebTrends Log Analyzer [en línea]. [Consultado: 25 marzo 2004]. Disponible en Internet: http://www.netiq.com/products/log/default.asp.

34. Pressman, R. (2001). Software Engineering: A Practitioner’s Approach, 5ª edición. Mc Graw-Hill.

35. International Standard (1999). ISO 13407. Human-centred design processes for interactive systems.

103

36. Bevan, N. (2003). UsabilityNet Methods for User Centred Design. Human-Computer Interaction: theory and Practice (volume 1). Lawrence Erlbaum Associates. También está disponible [en línea]. Dis-ponible en Intener: http://www.usabilitynet.org/tools/13407stds.htm

37. Moran, T. P. (1981). The command language grammar: a representation for the user interface of interactive systems. International Journal of man-machine studies, núm. 15, pág. 3-50.

38. Lorés, J. (editor) [cdrom] (2002). Introducción a la Interacción Persona-Ordenador. Abascal, J. Capítulo 7 dedicado a la Accesibilidad. Editado por Asociación Interacción Persona-Ordenador, AIPO. ISBN: 84-607-2255-4

39. Zubillaga, A. (2002). Estudio sobre la accesibilidad de las páginas web de inicio de las universidades españo-las y de las páginas web de la administración local. Jornada sobre accesibilidad: el poder de la web está en su universalidad. [en línea]. Disponible en Internet: http://www.paeria.es/acces/presentacions/jornada_accessibilitat/index_cas.htm

40. Alba, C.; Zubillaga, A.; Ruiz, N. (2003). Educación Superior y discapacidad: Accesibilidad de las páginas web de las universidades estatales. Comunicación y Pedagogía, 188, pág. 25-30.

41. International Standard –Technical Specification– (2003) ISO/TS 16071. Ergonomics of human-system interaction—Guidance on accessibility for human-computer interfaces. Primera Edición 1-02-2003.

42. Abascal, J. (2003). Accesibilidad a Interfaces Móviles para Computación Ubicua Relativa al Contexto. Tendencias actuales en la IPO: accesibilidad, adaptabilidad y nuevos paradigmas. XIII Escuela de Verano Univ. Castilla-La Mancha.

43. Stephanidis, C. (2001). Artículo Human Computer Interaction en el número especial de la revista ERCIM News. Nº 46, julio del 2001, pág. 8-9.

44. Abascal, J. (2002). Interacción Persona-Computador y Discapacidad, Revista Minusval, número espe-cial dedicado a la “Discapacidad y las Nuevas Tecnologías” (junio, 2002 – pags. 18-21). Minis-terio de Trabajo y Asuntos Sociales.

45. Wickelgren, I. (2003). Tapping the mind. Revista internacional SCIENCE VOL 299. 24 January 2003.

46. Instituto Nacional de Estadística (1999). Encuesta sobre Discapacidades, Deficiencias y Estado de la Sa-lud 1999. [en línea]. [Consultado: 25 marzo 2004]. Disponible en Internet: http://www.ine.es/discapa/discapamenu.htm

47. Booch,, G.; Rumbaugh, J.; Jacobson, I. (1999). The Unified Modeling Language User Guide. Addi-son-Wesley.

48. Schwartz, P. (1996). The Art of the Long View: Planning for the Future in an Uncertain World. Dou-bleday.

49. Carroll, J. (2000). Making use: Scenario-based design of human-computer interactions. MIT Press.

50. Sutcliffe, A. (2003). Scenarios, Models and the Design Process in Software Engineering and Interactive Sys-tems Design. Human-Computer Interaction: theory and Practice (volume 1). Lawrence Erlbaum Associates.

51. Rosson, M.B.; Carroll, J.M. (2002). Usability Engineering: scenario-based developement of HCI. Morgan Kaufmann.

52. Sutcliffe, A. (2002) User-Centred Requirements Engineering. Theory and Practice. Springer-Verlag.

53. Scheneider, G.; Winters, J.P. (1998). Applying Use Cases: a Practical Guide. Addison-Wesley.

104

54. Durán, A. (2002). Metodología para la Elicitación de Requisitos de Sistemas Software (v2.3). Informe Técnico LSI-2000-10 basado en la tesis doctoral del mismo autor. Universidad de Sevilla.

55. Nielsen, J. (1999). Designing Web Usability: The Practice of Simplicity. New Riders Publishing, USA.

56. Nielsen, J. (1997, 1 octubre). How Users Read on the Web. [en línea]. [Consultado: 25 marzo 2004]. Disponible en Internet: http://www.useit.com/alertbox/9710a.html

57. Nielsen, J.; Schemenaur, PJ; Fox, J. [en línea]. [Consultado: 25 marzo 2004]. Disponible en In-ternet: http://www.sun.com/980713/webwriting

58. Martin, C. (2003, 10 febrero). La página de error 404. [en línea]. [Consultado: 25 marzo 2004]. Disponible en Internet: http://www.alzado.org/articulo.php?id_art=104

59. Nielsen, J.; Tahir, M. (2002). Usabilidad de páginas de inicio: análisis de 50 sitios web. Prentice Hall, Pearson educación, SA.

60. Butler, K.A. (1996). Usability Engineering turns 10. ACM Interactions, June 1996.