Professional Documents
Culture Documents
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
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
1
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
GRIHO es el nombre del grupo de investigación en Interacción Persona-Ordenador de la Universi-
dad de Lleida. http://www.griho.net.
2
1.2. Usabilidad de los sistemas interactivos
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].
3
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.
4
- 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).
5
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.
6
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.
7
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.
8
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].
9
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”.
10
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 Personas afectadas Situaciones que provocan esta disca- Tecnologías de Rehabili-
discapacidad pacidad a otras personas tación
Sin Visión - ciegos - Ojos ocupados (:conducción) - Lectores de pantalla
- En la oscuridad
Poca Visión - con limitaciones visuales - Visor pequeño - Pantallas más grandes
(pérdida parcial de la visión, - Ambiente con humo - Fuentes mayores
deficiencias en la percepción - Aumento del contraste
de los colores, …) - Ampliadores de pantalla
Operable sin - sordos - entornos muy ruidosos - “show sounds” (presen-
poder oír - oídos ocupados tar la información auditiva
- silencio forzado (bibliotecas) en formato visual)
Oído limita- - “duros de oído” (dificultad - entornos ruidosos (discoteca) - “show sounds”
do para distinguir cambios de
frecuencia sonora o de locali-
zación de sonidos)
Impedimento - con funciones motoras - vestir vestidos especiales (astronau- - “eye tracking”
físico limitadas (problemas de tas) - teclados en la pantalla
coordinación, debilidad, - Dentro de un vehículo que se balan- - reconocedores de voz
dificultad de movimiento en cea - dispositivos apuntadores
extremidades) alternativos
Impedimento - con discapacidades cogniti- - situación de distracción - texto resaltado (para
cognitivo vas (dificultad al recibir - situaciones de pánico problemas de lectura)
información, de procesarla y - bajo la influencia del alcohol - reconocedores de voz
de comunicación) (para problemas de escri-
- hiperactivos tura)
- disléxicos
Operable sin - ciertas discapacidades cogni- - de visita en un país del cual se - internacionalización del
poder leer tivas desconoce el idioma software
- olvido de las gafas de lectura - texto resaltado
11
- 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-
12
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.
13
- 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].
14
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
15
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.
16
2. Modelo de proceso de la Ingeniería de la usabilidad
y la accesibilidad
2.1. Introducción
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
17
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.
18
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.
19
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-
20
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.
21
Figura 2_3: Metodología conceptual y esquemática de la Ingeniería de la Usabilidad.
22
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.
23
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.
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.
24
Figura 2_4: MPIu+a: Modelo de Proceso de la Ingeniería de la Usabilidad y de la
Accesibilidad.
25
- 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.
26
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.
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
27
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:
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.
28
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.
• 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.
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.
29
• 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
30
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
31
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.
32
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.
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:
33
• 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).
34
3. Análisis de requisitos
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.
35
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.
36
Ventajas e inconvenientes de los escenarios
- 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-
Ventajas [50] dades de los usuarios.
- las descripciones de los escenarios pueden ser creadas antes de que el sistema sea construido y
“sentir” el impacto resultante.
- 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
Inconvenientes
excepcionales o a incidir sobre aspectos relacionados con implicados poco representativos. Esta
tendencia es una reconocida “debilidad” de los escenarios [51].
1
Tabla basada en la página 18 de la referencia [52].
37
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.
38
• 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].
39
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.
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.
40
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.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.
41
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.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.
42
- 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:
43
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).
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].
44
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.
45
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.
46
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.
47
48
4. Diseño
49
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.
50
4.2. Arquitectura de la Información (AI)
Para los - ¿Cuáles son las motivaciones que llevan a los usuarios a visitar nuestro sitio?
Usuarios - ¿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 - ¿Cómo puedo organizar el contenido que tengo?
Contenido - ¿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 - ¿Quién, dentro de la organización, tiene poder de tomar decisiones?, y ¿qué quieren del sitio?
Contexto - ¿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.
51
4.2.1. Estructura de la información
AGENDA
EVENTOS
BIOGRAFIAS ARTISTA
DJ CHARTS ARTISTA
CLUBS CLUBS
NOTICIAS NOTICIAS
ARTICULOS
REPORTAJES
FOTOS FOTOS
ESPECIALES ESPECIALES
INICIO
DISCOS DISCOS
CITA
ENCUESTA Artistas
ENLACES Clubs
Discos
BÚSQUEDA
BOLETÍN
COLABORA
QUIENES SOMOS
NORMAS DE PRIVACIDAD
52
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).
53
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.
54
Figura 4_3: Usuarios realizando una ordenación de tarjetas.
55
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
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:
56
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
57
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:
58
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:
59
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:
60
TABLA 4_2: CONSEJOS PARA FACILITAR LAS BUSQUEDAS.
Evitar errores - Aunque, una ortografía correcta funcionará mejor, debemos ser conscientes que hay errores
ortografícos 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-
61
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.
62
4.3.2. Anchura fija
63
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
64
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].
65
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.
66
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%.
67
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.
68
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.
69
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.
70
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.
71
- 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.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.
72
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.
73
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.
• 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.
74
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.
75
Figura 4_8: Dos Maquetas digitales distintas para el diseño de una página de inicio.
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.
76
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á.
77
5. Implementación
79
6. Lanzamiento
6.1. Prelanzamiento
81
6.2. Lanzamiento
82
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.
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-
83
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.
84
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,
85
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.
86
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.
87
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ó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ón Persona-Ordenador CHI
Usabilidad Accesibilidad">
88
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.
89
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.
90
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.
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
91
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.
92
7. Métodos de evaluación generales
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.
93
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.
94
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
95
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.
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.
96
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.
97
- 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.)
1 Internet Protocolo
98
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.
99
- 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.
100
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
101
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.
102
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.
103
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.
104