TESIS

ANALISIS

DE

METODOS

DE

EVALUACION

DE

SITIOS

WEB

SU

INTEGRACION EN UNA APLICACIN ON-LINE

Resumen
Por Vernica

2.1.1. OBJETIVO GENERAL Analizar los diferentes mtodos de evaluacin de sitios Web e integrarlos en una aplicacin on-line, que permita evaluar y obtener resultados apegados a la realidad sobre determinado Sitio Web. 2.1.2. OBJETIVO ESPECIFICO Estudiar los Est ndares W!", WA# y fundamentos de usabilidad. Analizar los diferentes mtodos autom ticos y manuales de evaluacin de sitios Web. $esarrollar una aplicacin on-line que integre los mtodos seleccionados% manuales y autom ticos, de evaluacin de sitios Web. &ealizar pruebas de la aplicacin on-line, con dos sitios Web. 2.4. HIPOTESIS

La integracin de mtodos manuales y automticos de evaluacin de sitios Web lograra validar de manera completa la eficacia, accesibilidad y usabilidad de sitios Web.

'

INTRODUCCION Al evaluar un sitio Web es de gran importancia asegurar la calidad

principalmente en cuanto a usabilidad y accesible para darnos una idea clara veamos el siguiente e(emplo% Se trata de una tienda de novedades con grandes afic)es gr ficos, coloridos y letreros vistosos que informan lo que se puede encontrar dentro de la tienda, )asta all* todo estar*a bien, pero +importancia de la accesibilidad , e-iste un .nico camino para llegar a la tienda el cual permite el acceso solo a ve)*culos peque/os o a personas que presenten una licencia especial y adem s el camino es muy peligroso0 finalmente logran llegar a la tienda un numero especifico de clientes y al estar all* +importancia de la usabilidad, aunque la tienda disponga de los productos mas modernos pero las personas que atienden se demoran demasiado, la tienda no esta bien organizada y se tarda )oras en encontrar lo que se busca, no e-plican las caracter*sticas de los productos y nos )ablan con trminos sofisticados, no se podr*a salir satisfec)o de )aber visitado esa tienda, y a lo me(or no se puede comprar lo que se tenia en mente.

Q ! !"#$ #% !& '()(*' +!,$e acuerdo a la 1iptesis de tesis, la evaluacin se centrara en los siguientes aspectos%

Eficacia accesibilidad usabilidad C#$(.#. '()(*' W!,

"alidad del producto "alida en uso

En base a% 3odelo de "alidad #S4 &ecomendaciones 5!c &o(o6 repetido M/)*.*' .! !"#$ #0(1& .! '()(*' W!, 7esting I&.#2#0(1& )!') #nspeccin "onsulta +#nquiry, 7rac8ing 3odelado Anal*tico Simulacin M/)*.*' # )*34)(0*' 5 3#& #$!' 9ara realizar una reclasificacin de los mtodos autom ticos o manuales el presente proyecto de tesis se basara e-clusivamente en la manera de obtener los datos y calcularlos

T/0&(0#' .! !"#$ #0(1& .! '()(*' W!, Evaluacin )eur*stica 7est de usuario Estudios v*a Web &evisin de gu*as "omparaciones Entrevista An lisis de :og ;iles Evaluacin de "aracter*sticas y Atributos

 1ablar en <oz Alta

C*&0$ '(*&!' #nspeccin Est ndares Evaluacin 1eur*stica 3todo 7esting +evacuacin formativa, ca(a negra 4 indagacin "uestionarios ca(a >lanca?
3anual A@743A7#"4

I&'6!00(1& Inspeccin El trmino inspeccin aplicado a la usabilidad aglutina un conjunto de mtodos para evaluar la usabilidad en los que hay unos expertos conocidos como evaluadores que explican el grado de usabilidad de un sistema basndose en la inspeccin o examen de la interfaz del mismo. Existen varios mtodos que se enmarcan en la clasificacin de evaluacin por inspeccin siendo los que veremos a continuacin los ms importantes. Evaluacin !eur"stica El mtodo fue desarrollado por #IE$%E# &#IE'(a) y *+$I,! &*+$'-) y consiste en analizar la conformidad de la interfaz con unos principios reconocidos de usabilidad .la /heur"stica/0 mediante la inspeccin de varios evaluadores expertos. 1ara aplicar este mtodo &#IEheu) un conjunto de evaluadores 23 expertos en usabilidad contrasta y valida individualmente las /4- reglas heur"sticas de usabilidad/ 5conjunto revisado de reglas heur"sticas de usabilidad a partir del anlisis de 6(' problemas de usabilidad &#IE'(a)5 con la interfaz del sistema. 7ras las revisiones individuales los resultados son puestos en com8n y debatidos en una reunin entre los evaluadores y el responsable de la evaluacin .denominado observador0 quienes generan el informe final de la evaluacin.

'

Este mtodo es sin ninguna duda el ms conocido y utilizado. 7al es as" que incluso muchas personas confunden el concepto global de evaluacin de la usabilidad con la evaluacin heur"stica y se refieren 8nicamente al uso de esta tcnica cuando indican que eval8an la usabilidad del sistema concreto.

9portes concretos de nuestra investigacin al mtodo. 7ras probar esta tcnica en la mayor"a de los proyectos presentados en el *1Iu:a hemos definido una plantilla para los evaluadores basada en las 4reglas de #IE$%E# a la que le hemos introducido unas ligeras variaciones;
o

%e introduce una parte introductoria destinada a detallar los objetivos del sistema interactivo a probar. Esta parte es com8n para todos los evaluadores y es redactada por el observador. <elacionado con el punto anterior hemos introducido una nueva regla destinada a valorar el grado de transmisin de los objetivos por parte de la interfaz. ,ada heur"stica dispone de una serie de sub5reglas .o sub5heur"sticas0 que ayudan notablemente a los evaluadores mejorando los resultados de la prueba. El evaluador seg8n su criterio valora para cada aspecto encontrado su; Impacto que mide en el subheur"stico actual la dificultad que le puede suponer al usuario superar el problema detectado en la interfaz. =recuencia que indica con qu frecuencia se produce el problema. 1ersistencia del mismo como indicador de que una vez resuelto el problema en la parte de la interfaz en la que se ha detectado ste continuar producindose en otras partes de la misma.

*uestra de la evaluacin de la cuarta regla heur"stica .control y libertad para el usuario0 2

>ariantes interesantes de la evaluacin heur"stica. Evaluar la usabilidad de una aplicacin interactiva utilizando la tcnica de la evaluacin heur"stica tiene un carcter claramente definido hacia aplicaciones genricas en el que no interviene ning8n tipo de usuario .consecuencia de tratarse de un mtodo de inspeccin0. #o obstante en el contexto del proyecto europeo ,!9<9?E22 se present una aproximacin centrada en las tareas para el dise@o y la evaluacin .formativa0 de sistemas interactivos donde una de las principales novedades fue experimentar la respuesta de las evaluaciones heur"sticas tras incorporar usuarios &$I#'(). 1ara ello se combin la evaluacin heur"stica con la observacin del usuario. 9 cada usuario representativo se le facilitaron varios escenarios de tareas para que fuese capaz de evaluar cada tarea y completar el informe de la evaluacin. Estos usuarios fueron observados durante la ejecucin de cada tarea para ver cmo utilizaban la interfaz durante su realizacin qu errores comet"an cunto tiempo tardaban etc. 9mbas tcnicas produjeron datos cualitativos y cuantitativos a la vez que destacaron dificultades con algunos usuarios &?A*'B). $os datos recopilados durante la evaluacin fueron procesados mediante anlisis estad"stico para reflejar aspectos relacionados con la usabilidad. $o que no se especifica en las conclusiones de ,!9<9?E es acerca del verdadero beneficio o perjuicio que aporta la introduccin de usuarios en esta tcnica.

Inconvenientes generales de los procedimientos heur"sticos. $os inconvenientes atribuidos al procedimiento heur"stico en s" mismo son que los heur"sticos suelen ser espec"ficos del problema a tratar y pocas veces sirven para dar una respuesta concreta al problema. En el fondo lo que buscan los heur"sticos es reducir el dominio de las posibles soluciones o aspectos de su aplicacin para facilitar el proceso de descubrir soluciones o errores.

En el terreno espec"fico de evaluacin de la interfaz de usuario o del sistema interactivo en general el principal problema es que no hay participacin de usuarios representativos. !erramientas para la Evaluacin !eur"stica .en recursos CC softDare0. <ecomendacin; Excelente cap"tulo del libro /$a Interaccin 1ersona5 +rdenador/ dedicado a la evaluacin heur"sitica . !euristic Evaluation Inicio de la ventana <ecorridos Asability Eody of FnoDledge.

En el marco de la evaluacin de sistemas interactivos por inspeccin los mtodos denominados /recorridos/ constituyen una aproximacin alternativa a la evaluacin heur"stica con los que se intentan predecir problemas de usabilidad sin realizar tests con usuarios. En general en todos los recorridos se realiza una revisin detallada de todas las acciones asociadas a la consecucin de una o ms tareas que el usuario debe poder satisfacer con el uso del sistema. Inicialmente fueron pensados para ser realizados por expertos evaluadores con la ayuda de dise@adores pero como veremos tambin se ha investigado su validez incorporando usuarios. Ana de estas variantes a la cual hemos denominado recorrido cognitivo con usuarios &G<9-(b) es fruto de las investigaciones colaterales del trabajo presentado en esta tesis.

<ecorrido cognitivo El recorrido cognitivo .,ognitive HalFthrough0 es un mtodo de inspeccin de la usabilidad que se centra en evaluar en un dise@o su facilidad de aprendizaje bsicamente por exploracin y est motivado por la observacin que muchos usuarios prefieren aprender softDare a base de explorar sus posibilidades &H!9'6). $os pasos necesarios para la realizacin del mtodo se estructuran en el documento de la evaluacin y son los siguientes; 4. ?efinicin de los datos necesarios para el recorrido; a. %e identifican y documentan las caracter"sticas de los usuarios IJuines sern los usuarios del sistemaK $a descripcin de los usuarios incluir la experiencia espec"fica acumulada y el conocimiento adquirido como factores determinantes para la comprobacin del factor /cognitivo/ durante el recorrido. b. %e describe tambin el prototipo a utilizar para la evaluacin que no es preciso que sea ni completo ni detallado. c. %e enumeran las tareas concretas a desarrollar. d. 1ara cada tarea se implementa por escrito la lista "ntegra de las acciones necesarias para completar la tarea con el prototipo descrito. Esta lista consta de una serie repetitiva de pares de acciones .del usuario0 y respuestas .del sistema0.

6. <ecorrer las acciones; $os evaluadores realizan cada una de las tareas determinadas anteriormente siguiendo los pasos especificados y utilizando el prototipo detallado. En este proceso el evaluador utilizar la informacin del factor cognitivo .experiencia y conocimiento adquirido0 de los usuarios para comprobar si la interfaz es adecuada para el mismo. Esta revisin ha de ser minuciosa para todas las acciones especificadas para la consecucin de la tarea.

1ara ello el evaluador en cada accin criticar el sistema respondiendo a las siguientes preguntas &?IL'M); 4. I%on adecuadas las acciones disponibles de acuerdo a la experiencia y al conocimiento del usuarioK 6. I1ercibirn los usuarios que est disponible la accin correctaK Esto se relaciona con la visibilidad y la comprensibilidad de las acciones en la interfaz. 9qu" no se discutir sobre si la accin se encuentra en el sitio adecuado o no sino que se incidir en si sta est presente y si es visible. B. Ana vez encontrada la accin en la interfaz Iasociarn estos usuarios la accin correcta al efecto que se alcanzarK (. Ana vez realizada la accin Ientendern los usuarios la realimentacin del sistemaK. 7anto si la accin se ha realizado con xito como en el caso contrario. 6. ?ocumentar los resultados 4. El evaluador anotar para cada accin las respuestas del sistema y sus anotaciones. 2. El documento incluir un anexo especial conocido como Asability 1roblem <eport %heet &?IL'M) detallando los aspectos negativos de la evaluacin relacionndolos con un grado de severidad que permita distinguir aquellos errores ms perjudiciales de los que no lo son tanto. 9lgunos autores slo consideran importante esta parte de la documentacin pues contiene los problemas a solucionar. 9 pesar de que esta tcnica es idnea en la etapa de dise@o del sistema puede tambin ser aplicada durante el resto de etapas. Ejemplo 4 Ejemplo 6 Ejemplo B Inicio de la ventana

<ecorrido de la Asabilidad 1lural *todo desarrollado en los laboratorios IE* &EI9'(b) que comparte algunas caracter"sticas con los recorridos tradicionales pero tiene algunas particularidades que lo diferencian entre las que cabe destacar la intervencin de usuarios finales. Estas caracter"sticas son las siguientes; a. Este mtodo se realiza con tres tipos de participantes usuarios representativos desarrolladores y expertos en usabilidad que conforman todos los actores implicados en el producto. b. $as pruebas se realizan con prototipos de papel u otros materiales utilizados en escenarios. ,ada participante dispone de una copia del escenario de la tarea con datos que se puedan manipular.

c. 7odos 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 expertos en usabilidad tambin lo han de asumir. d. $os participantes han de escribir en cada panel del prototipo la accin que tomarn para seguir la tarea que estn realizando escribiendo las respuestas lo ms detalladamente posibles. e. Ana 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 stos han expuesto completamente sus opiniones hablan los desarrolladores y despus los expertos en usabilidad. El principal beneficio de esta tcnica radica en el fuerte enfoque hacia las tareas de los usuarios &1<E-6). %iendo otra importante caracter"stica .constatada en los desarrollos del grupo de investigacin G<I!+0 la gran aceptacin del mtodo por los equipos multidisciplinares. En cuanto a las desventajas la principal de ellas es lo dif"cil que suele resultar agrupar tanta gente en una sola sesin. Inicio de la ventana

<ecorrido cognitivo con usuarios. Este mtodo constituye una nueva aportacin surgida a partir del estudio realizado con motivo de esta tesis que supone la primera aproximacin conocida de implicar usuarios a los tradicionales recorridos cognitivos &G<9-(b). ,onocedores de las ventajas de los recorridos cognitivos pero conscientes a la vez de sus principales problemas decidimos comprobar cmo ser"a de eficiente extender la mencionada tcnica incorporando usuarios. Estos problemas de los recorridos cognitivos a los que nos referimos son; o $a ausencia de usuarios en las sesiones de evaluacin es una carencia com8n en todos los mtodos que solamente se basan en los criterios de unos expertos para decidir sobre aspectos concernientes a terceras personas .los usuarios0. Este factor es muy importante pues por muy expertos que sean los evaluadores siempre habr aspectos que slo pondrn de manifiesto los verdaderos interesados. 1or tanto al ser el recorrido cognitivo un mtodo donde no intervienen usuarios tiene esta carencia. 1or otra parte el evaluador para recorrer las acciones constantemente deber ser capaz de responder preguntas del tipo Isern capaces los usuarios de esta aplicacin de entender determinado icono o metforaK o Idispondrn del conocimiento necesario cundo accedan a determinada funcinK. <espuestas que deber contestar basndose en la descripcin de las caracter"sticas de los usuarios en trminos de su conocimiento adquirido y de su experiencia acumulada realizada en la primera fase del mtodo. B

El evaluador por tanto tiene que fiarse en esta descripcin para interpretar si las tareas son adecuadas o no lo que introduce un primer nivel de posible incertidumbre o de error. Es ms aunque las descripciones fuesen del todo correctas siempre queda de la mano del evaluador la 8ltima interpretacin a@adiendo por tanto un segundo nivel de error. o N un tercer problema derivado tambin de la ausencia de usuarios .y por tanto aplicable al resto de mtodos por inspeccin0 es que no favorece el dise@o participativo &G9='') tan importante desde la perspectiva de la disciplina de la Interaccin 1ersona5+rdenador. ?e todas formas tal incorporacin no puede realizarse livianamente. ,omo resultado de conocer los factores humanos sabemos que cada persona tiene puntos de vista particulares e ideas propias realizando cada uno ciertas acciones de manera espontnea rutinaria o inconsciente mientras que otras se ejecutan voluntariamente en la privacidadO este hecho hace que paradjicamente /en muchas ocasiones uno mismo no sea el ms apropiado para reflejar los propios pensamientos/ &%A7-6). 9s" que en determinadas ocasiones las respuestas que un usuario puede dar sern menos buenas que las de los expertos. El experto en evaluar interfaces de usuario puede conocer lo que los usuarios estn pensando mejor que ellos mismos &?IL-B). 9dicionalmente tendremos presente que no ser habitual disponer en las evaluaciones de personas que encajen con todos los posibles perfiles de usuario definidos lo que influir en la orientacin de los tipos de tareas que en cada sesin se plantearn. 7odo ello nos hace plantear la nueva forma de realizar la evaluacin por recorrido cognitivo con usuarios partiendo de la propia metodolog"a del recorrido cognitivo y proceder a incorporar cautelosamente usuarios de tal manera que el hecho de solucionar unas carencias no facilite la aparicin de otras. El proceso planteado es el siguienteO a. <ealizar el recorrido cognitivo de la manera tradicional. b. Ana vez concluido el punto anterior se incorporarn los usuarios de la siguiente manera; 4. <eclutar usuarios representativos del perfil que se desea evaluar. 2. 7ras una introduccin explicando la prueba el mtodo los objetivos y el prototipo se pide a cada usuario que realice de manera individual el grupo de tareas definidas en el recorrido correspondientes a su perfil de usuario. %e pide a los usuarios que expresen libremente en voz alta sus pensamientos sentimientos y opiniones sobre cualquier aspecto .interactividad dise@;o funcionalidad...0 mientras interaccionan con el sistema o el prototipoO caracter"stica adoptada del mtodo de evaluacin thinFing aloud &#IE'B) que ms tarde veremos en este mismo cap"tulo. ,ada usuario realizar todas las tareas sin recibir ms explicaciones que las anteriores y al finalizarlas deber complementar la informacin anotando los principales defectos detectados. B. 9dicionalmente una vez el usuario ha finalizado las tareas pueden comentarse los problemas potenciales identificados en el punto .a0 para C

conocer su punto de vista ms detalladamente. Este punto aunque adicional es altamente recomendable. c. Pl o los expertos revisarn a posteriori las cuestiones formadas en la etapa .b0 para documentar los resultados finales. El razonamiento seguido para proceder de la forma explicada es el siguiente; 1odr"a pensarse que tras la incorporacin de los usuarios el recorrido tradicional realizado en primer lugar .punto a0 dejar"a de ser necesarioO no obstante las razones de mantener dicha actividad son las siguientes;

El recorrido realizado por un experto aporta la /imparcialidad/ necesaria que los usuarios no pueden aportar. ?ebemos asegurarnos la posibilidad de que el experto descubra problemas diferentes de aquellos que descubrir"a una vez ya han intervenido usuarios. 9 su vez proporciona el /punto de entrada/ para la etapa .b0 permitiendo que el evaluador observe cmo responde el usuario en aquellos puntos que le resultaron ms confusos o errneos.

1or otra parte en el punto .b0 las razones de poner .a0 antes de .c0 parecen evidentes; por una parte .iii0 es opcional y por otra si se invierte el orden quien no realizar"a un recorrido de manera imparcial ser"a el usuario. Esta variante del mtodo se ha probado en dos sesiones de evaluacin correspondientes a dos casos reales de los proyectos realizados en nuestro grupo de investigacin. $os resultados de estos casos y las mejoras del mtodo respecto a su predecesor estn explicados en &G<9-(b) y concretamente uno de ellos la Deb del ,ongreso i6--( corresponde a uno de los casos utilizados como ejemplos en esta tesis. 9dems de aumentar considerablemente el n8mero de errores detectados de la incorporacin de usuarios al recorrido cognitivo se han observado las siguientes mejoras;

%i estamos de acuerdo en que un verdadero ?,A debe incorporar usuarios &EE>'M) estaremos entonces de acuerdo que los mtodos que no incorporan usuarios necesitan complementar sus resultados con resultados obtenidos mediante otras tcnicas en las que haya intervencin de usuarios finales representativos. ,on la presencia de usuarios se fomenta el dise@o participativo &G9='') y con ello la formacin de equipos multidisciplinares tan importantes en la disciplina de la Interaccin 1ersona5+rdenador. ,on el material previamente preparado para el recorrido cognitivo y gracias a la tcnica de pensar en voz alta .thinFing aloud0 la participacin del usuario es ms fluida que ubicndole en un laboratorio en el que le coh"ba el sentirse observado. $as dudas o errores que pueden haber surgido en la primera fase de la evaluacin pueden ser contrastadas rpidamente con usuarios finales y evitar as" que se creen indecisiones nocivas para el proyecto. En muchas ocasiones el evaluador no es capaz de detectar los errores correctamente debido a que las especificaciones de la experiencia y del D

conocimiento de los usuarios son inexactas o incompletas. ,omplementar la evaluacin con los usuarios ayudar adems a corroborar a completar o simplemente a mejorar estas descripciones. ,omo contrapartida puede indicarse que el mtodo requiere ms recursos para su realizacin; El evaluador necesita invertir mucho ms tiempo y es necesario reclutar usuarios y dedicarles el tiempo necesario. #o obstante tras las experiencias realizadas estamos convencidos que la considerable mejora obtenida justifica dicho incremento. Inicio de la ventana

Inspeccin de estndares.

1ara evaluar este mtodo se precisa de un evaluador que sea un experto en el o en los estndares a evaluar. El experto realiza una inspeccin minuciosa a la interfaz para comprobar que cumple en todo momento y globalmente todos los puntos definidos en el estndar establecido. IJu es un estndarK An estndar es un requisito regla o recomendacin basada en principios probados y en la prctica. <epresenta un acuerdo de un grupo de profesionales oficialmente autorizados a nivel local nacional o internacional &%*I'3). N tal como indica ?. #+<*9# /los estndares son para siempre porque una vez establecidos simplifican y dominan las vidas de millones incluso billones de personas/ &#+<'Q). El teclado qDerty parece una cosa que siempre ha estado con nosotros al igual que el sistema mtrico decimal. I,ul es el lado correcto para conducir en la carreteraK IEl derecho o el izquierdoK +bviamente no importa mientras todos hagamos lo mismo aunque Ino ser"a mejor para los fabricantes de automviles y los conductores si se hubiese convenido un estndar 8nico para todo el mundoK. El impacto de acordar y sobre todo cambiar la conduccin de todo el mundo por el mismo lado es enorme y por ello .entre otras razones0 parece un problema inabordable a pesar de que los costes derivados de mantener este estndar son mucho mayores. N #orman contin8a diciendo que / ...con el tiempo los costes descienden mientras que los estndares permanecen/ &#+<'Q). ?e aqu" que decidir un estndar no es una tarea que pueda tomarse a la ligera pues de esta decisin depender el futuro y si sta no es la mejor ser un lastre perpetuo. 7ipos de estndares. a. $os estndares de iure son generados por un comit con estatus legal y estn avalados por el apoyo de un gobierno o institucin para producir estndares.

En informtica existen una serie de comits que han participado en la creacin de muchos estndares de iure los ms destacados son; $a +rganizacin Internacional para Estndares .International +rganization for %tandardization I%+0 la ,omisin Electrotcnica Internacional .International Electrotechnical ,ommission IE,0 el Instituto #acional 9mericano para Estndares .9merican #ational %tandards Institute 9#%I0 la seccin %tandards 9ssociation del Instituto de Ingenieros Elctricos y Electrnicos 9mericano .Institute of Electrical and Electronics Engineers IEEE0 el ,omit Europeo para la Estandarizacin .,omit Europen de #ormalisation ,E#0 y el ,onsorcio para Horld Hide Heb .Horld Hide Heb ,onsortium HB,0. El proceso para generar un estndar de iure es bastante complejo. ?e forma resumida los pasos a seguir son; 1rimero se confecciona un documento preliminar que debe hacerse p8blico para que despus cualquier persona o empresa interesada pueda presentar enmiendas de los borradores del documento. Estas enmiendas han de ser comentadas y resueltas. 7ras un cierto tiempo a veces a@os se consigue un consenso y se acepta el nuevo estndar. b. $os estndares de facto que nacen a partir de productos de la industria que tienen un gran xito en el mercado o bien a partir de desarrollos hechos por grupos de investigacin de universidades y que tienen una gran difusin. Estos productos o proyectos de investigacin llegan a tener un uso muy generalizado convirtindose por tanto en estndares de facto .por ejemplo el sistema de ventanas con la metfora del escritorio de fondo0. %u definicin se encuentra en los manuales libros o art"culos. %on tcnicamente muy valiosos y muy utilizados. <ealizacin del mtodo. %i bien este mtodo podr"a realizarse partiendo de prototipos de baja fidelidad lo ms efectivo es realizarlo a partir de prototipos softDare o incluso mejor con una primera versin del sistema final donde estn implementadas las partes que deben confrontarse con el estndar .que normalmente sern aspectos ms relacionados con la interfaz que con las funcionalidades0. En fase de anlisis de requisitos se define el estndar que el sistema seguir .ya sea porque es una especificacin del proyecto o uno escogido por sus caracter"sticas0 y el experto 5en dicho estndar5 realiza una inspeccin minuciosa a la totalidad de la interfaz para comprobar que cumple en todo momento y globalmente todos los puntos definidos en el estndar &HIL'(). ?urante esta exploracin al experto no le importa la funcionalidad de las acciones que va realizando. Inicio de

'F

Inspeccin es un nombre genrico para un conjunto de mtodos cuya principal caracter"stica com8n es que hay unos expertos conocidos como evaluadores que examinan .inspeccionan0 aspectos de la interfaz del sistema relacionados con la usabilidad y la accesibilidad que la misma ofrece a sus usuarios. $os diferentes mtodos por inspeccin tienen objetivos ligeramente diferentes pero en todos ellos se tienen en cuenta las opiniones juicios informes de los inspectores sobre elementos espec"ficos de la interfaz como factor fundamental de la evaluacin 5normalmente de la usabilidad5 &#IE'(a). :os mtodos de evaluacin por inspeccin empiezan a ser populares en el mbito de las empresas de produccin de servicios soft5are,

pues permiten identificar, clasificar y contabilizar un gran n.mero de errores potenciales de usabilidad a precio relativamente ba(o G>#AE=aHGI#EE=aH, siendo el )ec)o de no utilizar usuarios uno de los factores que m s contribuyen a dic)a reduccin econmica. Evaluacin )eur*stica Un
especialista o grupo de especialistas verifica si

el dise/o propuesto +elementos estructurales esquema de colores tipolog*a componentes interactivos y operativos, esta en consonancia con los principios de usabilidad establecidos. 9ara ello se utiliza el conocimiento de los especialistas sobre la cognicin )umana y un con(unto de gu*as basadas en los principios. Se utilizan e-pertos para validar la interfaz por que es dif*cil que un evaluador pueda encontrar todos ciertos criterios definidos los problemas de usabilidad en una interfaz a partir de

:ista de 1eur*sticos de @sabilidad para Web sites

<isin de la situacin en el sistema%

(Jakob Nielsen)

J$nde estoy dentro de la estructura del Web siteK

J$nde puedo irK Web orientado al usuario, no a la tecnolog*a ni al sector de actividad. ;undamentalmente%

''

:engua(e mane(ado.

"onceptos utilizados. "ontrol del usuario y libertad de movimientos% Salidas de Emergencia de aplicaciones o procesos. 7ecnolog*as limitativas. "onsistencia y est ndares% 7*tulos, cabeceras y etiquetas de lin8s. Seguimiento de est ndares Web. 9revencin de errores, sobre todo en la captura de datos con formularios% Aportar informacin Lad )ocL precisa para evitar errores. +Evitar la reiterada devolucin de formularios para reintroduccin de datos por incorrecto ? falta de campos,. "uidar muc)o los mensa(es de error devueltos, aportando v*as de solucin. &econocer me(or que recordar% evitar que el usuario tenga que recordar nada% Significados de iconos e im genes. Situacin en el Web y trayectoria.

;undamental buenas etiquetas y enlaces descriptivos. ;le-ibilidad y eficiencia de uso% 9ermitir a los usuarios acceder directamente a cualquier p gina sin pasar por la 1ome 9age% facilidad de boo8mar8 +evitar tramas,. Evitar @&:s de p ginas temporales o de vida ef*mera. @sar mtodo ME7 me(or que 94S7 en ;4&3S% permite a los

usuarios boo8mar8 el resultado de una b.squeda. Esttica y $ise/o 3inimalista% no utilizar en los di logos informacin irrelevante o innecesaria% distrae de lo verdaderamente importante% Estructurar la informacin en niveles de detalle progresivos. Io escribir como en papel. $ar mensa(es de error claros, auto e-plicativos y que den la solucin para resolver el problema% Io utilizar cdigos. Io utilizar descripciones largas ni demasiado tcnicas. Ayuda y documentacin% la ayuda en tareas debe ser f cil de acceder y de contesto a la tarea en curso. 3e(or si se puede disponer en la propia p gina en la que se traba(a.

&ecorrido cognitivo
Evaluadores e-pertos construyen escenarios de tareas a partir de las especificaciones de una maqueta de Web site y asumen el rol de un usuario que tuviera que realizar dic)as tareas recorriendo el interfaz de usuario propuesto. $urante la realizacin de cada tarea se recoge cada paso que un usuario )ar*a. Aquellos pasos en los que el usuario se bloquea y no consigue terminar una tarea implican que el interfaz adolece de alg.n aspecto, o bien falta alguna funcin que simplifique la e(ecucin de la tarea.

'2

Se evalan las especificaciones de un sistema en trminos de qu tareas reali arn los usuarios en el mismo. Suele ayudar muc!o establecer los "ob#etivos del usuario" al reali ar cada tarea.

$ada ob#etivo de usuario al reali ar una tarea implica%

@na accin cognoscitiva. @na accin f*sica.

&urante el recorrido se identifican los problemas para alcan ar cada ob#etivo. 'n ob#etivo se puede dividir en subob#etivos, y cada uno de estos llevar asiociada una tarea a reali ar. 'n ob#etivo se puede dividir en subob#etivos, y cada uno de estos llevar asiociada una tarea a reali ar. (dems cada ob#etivo implicar prerequisitos o tareas que !abr sido necesario reali ar previamente. &e esta forma se va construyendo el rbol de funciones )y sus dependencias* que debe proporcionar el sistema para que los usuarios realicen todas las tareas previstas.

Est ndares Es la verificacin del cumplimiento del site con los est
oficiales como Lde factoL que rigen en WWW.

ndares, tanto

@n e-perto en usabilidad con un conocimiento e-a)ustivo de la &ed analiza el interfaz de usuario del site c)equeando el cumplimiento. +7est de E-perto,.

#nspeccin de "aracter*sticas Se analizan slo las caracter*sticas que debe

cumplir un Web site en funcin de las especificaciones establecidas inicialmente. Se eval.a el cumplimiento mediante tests de usuario final operando en un escenario funcional de pruebas y se comprueba si los resultados tras la operativa de este son los esperados. Se establece una lista de caracter+sticas del site que deber+an cumplirse para la reali acin de las diferentes tareas que reali ar+a un usuario. Se comprueba )inspeccin* la dificultad o imposibilidad del usuario final de alcan ar dic!as caracter+sticas durante la reali acin de las tareas. Se elabora un documento descriptivo anali ando los niveles de dificultad del usuario en alcan ar las caracter+sticas del site en cada momento.

#nspeccin ;ormal

'!

Se establece un equipo de = a D inspectores, cada uno con un papel determinado en el mbito de la inspeccin global e instrucciones precisas de qu aspectos debe evaluar y qu conclusiones debe recoger. "ada inspector traba(ar por su cuenta y se intercambian las e-periencias en reuniones de traba(o formales de las que saldr n los aspectos a modificar por los distintos equipos de dise/o. :a metodolog*a de traba(o establecer realizarse. los ciclos en los que estas inspecciones deber n

Se forma el equipo de traba#o con diferentes perfiles, bsicamente con profesionales que traba#en en el proyecto tanto en el dise,o, como en el desarrollo, documentacin, supervisin, calidad, etc. $ada inspector, adems de su funcin de evaluar deficiencias de usabilidad, debe asumir un rol durante las reuniones formales de traba#o% M*.!%#.*%7 $istribuye y recoge los materiales requeridos. 9rograma las reuniones de traba(o. Asigna tareas de correccin de deficiencias. P%*6(!)#%(*7 Autor ? $ise/ador del site ba(o an lisis% se le asignan las correcciones de los defectos encontrados. S!0%!)#%(*7 &ecoge en un documento formal los defectos de usabilidad encontrados durante las reuniones de traba(o. I&'6!0)*%!'7 El resto del equipo +se puede asumir m s de un rol,% #nspeccionan el dise/o y realizan los informes de deficiencias presentados. Se distribuyen los documentos de traba#o entre los inspectores $escripciones del site. 9antallas con sus correspondientes distribuciones de ob(etos. 9erfiles de usuarios. 7areas de usuario. 1eur*sticos a usar.

'=

;ormulario de recogida de deficiencias de usabilidad.. #nspeccin del dise/o% cada inspector traba(a en solitario recogiendo las deficiencias en el formulario Lad )ocL, teniendo en cuenta los )eur*sticos. En el formulario, (unto a la descripcin del defecto se deber reunin de traba(o. -antenimiento de reuniones formales de traba#o% ).reviamente los inspectores !abrn repasado los !eur+sticos*% #nspectores describen los defectos encontrados y se discuten, asumiendo el punto de vista de un usuario. Se aprueba el acta de deficiencias que )abr recogido el Secretario. El 3oderador deber evitar intentos de% $efensa de aspectos del dise/o por parte de los 9ropietarios, considerados como deficiencias. >.squeda de soluciones a las deficiencias durante las reuniones. Se priorizar la solucin de deficiencias% El 3oderador asigna la solucin de cada deficiencia al 9ropietario correspondiente, acordando plazo de e(ecucin. El 3oderador )ar seguimiento de deficiencias corregidas, en curso y pendientes, convocando reuniones de conflicto si fueran necesarias. encontrar un campo para recoger la ubicacin e-acta del mismo y otro campo de L4tras observacionesL que se completar durante la discusin en la

&evisin de Mu*as $escriben los principios a tener en cuenta en el dise/o y desarrollo de un Web site para garantizar su usabilidad.

Se decide que /u+a de $onsulta de 'sabilidad de las e0istentes se va a considerar seguir para el dise,o y desarrollo del Web site, ya sea respetndola de forma +ntegra o adaptada a las necesidades concretas. &e lo contrario !abr+a que partir de la elaboracin de una gu+a propia. Se establece la /u+a de $onsulta de 'sabilidad como estndar de consulta para el dise,o del interfa de usuario del Web site.

'A

Se estable una $!ec1List para la comprobacin del cumplimiento de los aspectos concretos del interfa de usuario que afectarn a la usabilidad. En posteriores anlisis de usabilidad, se c!equea el cumplimiento de cada uno de los elementos del interfa de usuario contra la $!ec1List..

I&.#2#0(1& 8)!')!*9

Indagacin El proceso de indagacin trata de llegar al conocimiento de una cosa discurriendo o por conjeturas y se@ales. En este tipo de mtodos de evaluacin de la usabilidad una parte muy significativa del trabajo a realizar consiste en hablar con los usuarios y observarlos detenidamente usando el sistema en trabajo real y obteniendo respuestas a preguntas formuladas verbalmente o por escrito. $os principales mtodos de evaluacin por indagacin son;

+bservacin de campo

$a tcnica de evaluacin conocida como +bservacin de ,ampo tiene como principal objetivo entender cmo los usuarios de los sistemas interactivos realizan sus tareas y ms concretamente conocer todas las acciones que stos realizan durante la realizacin de las mismas. ,on ello se pretende capturar toda la actividad relacionada con la tarea y el contexto de su realizacin as" como entender los diferentes modelos mentales que de las mismas tienen los usuarios. 1ara realizar una observacin de campo &#IE'B) el trabajo que se realiza es visitar el lugar o lugares de trabajo donde se estn realizando las actividades objeto de nuestro estudio en las que encontraremos los usuarios representativos que observaremos. 1rocedimiento. $as visitas de campo deben prepararse previamente .la improvisacin induce a la indecisin del evaluador e inseguridad a los usuarios que van a ser observados0. Esicamente esta preparacin previa consistir en;
o o

Escoger una variedad de usuarios representativos del producto .de diversos lugares de trabajo0. Atilizar el sitio de observacin y el tiempo con eficacia. #uestras visitas no sern ni muchas ni de mucha duracinO por tanto ser vital aprovechar el tiempo al mximo y recoger cuanta ms informacin posibleO el anlisis de sta puede realizarse despus en nuestra oficina.

'B

%i pensamos complementar la informacin a partir de los usuarios es preferible elaborar a priori tanto la lista de las preguntas que necesitemos que las personas contesten como la lista de los datos y objetos que pensamos que nos sern 8tiles.

Ana vez en el lugar el mtodo se compone bsicamente de dos partes complementarias; a. Ana parte la principal es la observacin. +bservando todo cuanto acontece el lugar de la accin; ?e qu manera lo hacen qu objetos utilizan cmo los utilizan dnde estn ubicados para qu los utilizan qu secuencia de acciones siguen con quin hablan en qu orden lo hacen cul es la finalidad etc. b. N la otra adicional consiste en preguntar o entrevistar a los usuarios acerca de su trabajo para complementar la informacin recabada durante la observacin. 9l final de una sesin de observacin de campo obtendremos una lista de acciones objetos personas y en definitiva todo cuanto acontece en el lugar donde se desarrolla la accin que hace o har referencia al sistema que estamos evaluando. $a fase del ciclo de vida del modelo de proceso ms apropiada para realizar este mtodo es sin duda durante el 9nlisis de <equisitos momento en el que necesitamos conocer el entorno de trabajo los objetos las personas la organizacin los mtodos las tareas que se realizan etc. para poder recoger requisitos necesarios para el dise@o del sistema. N la tcnica de anlisis ms adecuada para su realizacin es el anlisis etnogrfico .tcnica que se trata en profundidad posteriormente en el apartado dedicado a la fase del anlisis de requisitos0. ?ebe mencionarse que la observacin de campo puede resultar obstrusiva e incluso algunos usuarios pueden variar sus hbitos por el hecho de sentirse observados e incluso negarse a ello. Ejemplo +bservacin de campo 4 Ejemplo +bservacin de campo 6 Inicio de la ventana

Grupo de ?iscusin ?irigido .=ocus Group0

El =ocus Group &#IE'B) o grupo de discusin dirigido es una tcnica de recogida de datos donde se re8nen de 3 a ' personas .generalmente usuarios y tambin implicados0 para discutir aspectos relacionados con el sistema. En ellos un evaluador experto en usabilidad yRo accesibilidad .dependiendo del objetivo de la evaluacin0 realiza la funcin de moderador. Pste preparar previamente la lista de aspectos a discutir y se encargar de recoger la informacin que necesita de la discusin. Esto permite capturar reacciones espontneas e ideas de los usuarios que evolucionan en el proceso dinmico del grupo.

'C

1rocedimiento. $os procedimientos generales para dirigir un =ocus Group son;

o o o o

$ocalizar usuarios representativos .t"picamente 3 a ' por sesin0 que quieran participar. En ocasiones puede haber uno o varios observadores que no intervienen en el debate y slo toman anotaciones. 1reparar una lista de temas a discutir y los objetivos a asumir por los temas propuestos. El moderador deber poner especial nfasis en; Jue todos los participantes contribuyen a la discusin. Jue no haya un participante que domine la discusin. ,ontrolar la discusin sin inhibir el flujo libre de ideas y comentarios. 1ermitir que la discusin discurra libremente en ciertos momentos pero procurando seguir el esquema planeado. 9l final el moderador .y el o los observadores0 realizarn un informe escrito con los resultados y las conclusiones del debate. Incluir las opiniones que han prevalecido y los comentarios cr"ticos de la sesin.

'D

9spectos a considerar. 9l dirigir un =ocus Group hay una serie de aspectos importantes a tener en cuenta;
o

7ener ms de un grupo principal puesto que el resultado de una sola sesin puede no ser representativo o incluso que una parte significativa del tiempo de la discusin pudo haberse centrado en aspectos de importancia menor. Es preferible que el moderador tenga dotes dinamizadores y comunicativos. #o es tan simple como preparar las preguntas y presentarlas a los usuariosO el moderador necesita facilitar y dirigir la discusin en tiempo real y saber sortear hbilmente todo tipo de imprevistos que puedan surgir. ?ebe dudarse siempre de los datos recogidos porque debido a su naturaleza desestructurada y de flujo libre tienden a tener una validez cuestionable y son muy dif"ciles de analizar.

El mtodo se puede aplicar en cualquiera de las fases de ciclo de vida del proceso softDare aun as" en las que ms se ha aplicado .y por tanto de la que se tiene mayor experiencia0 es en la fase de lanzamiento. Inicio de la ventana

Entrevistas.

Ana entrevista consiste bsicamente en una conversacin donde uno o varios usuarios reales del sistema que se va a desarrollar o a redise@ar responden a una serie de preguntas relacionadas con el sistema que el entrevistador les va formulando. En este caso el entrevistador es el evaluador y va tomando nota de las respuestas para obtener las conclusiones finales. Entrevistar a los usuarios respecto de su experiencia en un sistema interactivo resulta una manera directa y una tcnica potente de adquirir informacin &9$<'(). $as 'E

entrevistas pueden ser estructuradas o abiertas .o desestructuradas0 en las primeras el evaluador es ms r"gido en procurar el buen seguimiento del guin preestablecido mientras que en las abiertas se da espacio a los contertulios a expresarse con ms libertad. $as cuestiones pueden variar con tal de adaptarlas al contexto. #ormalmente en una entrevista se sigue una aproximacin de arriba abajo con el objetivo de seguir un discurso ordenado. $as entrevistas pueden ser efectivas para una evaluacin de alto nivel particularmente para extraer informacin sobre las preferencias del usuario impresiones y actitudes. 1uede ayudar a encontrar problemas no previstos en el dise@o. 1ara que la entrevista sea lo ms efectiva posible ha de ser preparada con antelacin con todo un conjunto de preguntas bsicas. El revisor puede adaptar la entrevista al entrevistado y obtener el mximo beneficio. Esta tcnica puede ser utilizada en cualquier etapa del ciclo de vida del desarrollo del producto softDare pues en funcin de las necesidades del propio desarrollo precisaremos diferente informacin. 9un as" este tipo de evaluacin suele realizarse una vez el sistema ya ha sido puesto en marcha siendo en este caso el principal objetivo captar la satisfaccin del cliente o usuario con el producto. El principal problema en estos casos es que si no se ha realizado una correcta planificacin de la usabilidad del sistema en ese momento surgen una serie de caracter"sticas que de haber surgido anteriormente se hubieran ahorrado muchos problemas &%9$'(). Ejemplo entrevista Inicio de la ventana

,uestionarios.

7cnicamente el trmino cuestionario es una lista de cuestiones o preguntas planteadas sobre alg8n tema con la finalidad de que alguien las responda. En el mbito de la evaluacin de sistemas interactivos hablamos de cuestionarios para referimos a listas de preguntas que el avaluador distribuye entre usuarios yRo implicados para que stos nos las devuelvan respuestas y as" poder extraer conclusiones. El cuestionario normalmente se distribuye en formato escrito y las preguntas plantean aspectos relacionados con el sistema o aplicacin concreta. 9s" pues la base del cuestionario es la recoleccin de informacin a partir de respuestas contestadas por los usuarios yRo los implicados. $os tipos de preguntas a incluir en un cuestionario son;

2F

a. 1regunta de carcter general; 1reguntas que ayudan a establecer el perfil de usuario y su puesto dentro de la poblacin en estudio. Incluye cuestiones como edad sexo ocupacin lugar de residencia aficiones estudios aficiones etc. b. 1regunta abierta; 1reguntas 8tiles para recoger informacin general subjetiva. 1ueden dar sugerencias interesantes y encontrar errores no previstos. c. 1regunta de tipo escalar; 1ermite preguntar al usuario sobre un punto espec"fico en una escala numrica. d. +pcin m8ltiple; En este caso se ofrecen una serie de opciones y se pide responder a una o varias. %on particularmente 8tiles para recoger informacin de la experiencia previa del usuario. An caso especial es cuando se le dan opciones para contestar si o no. e. 1reguntas ordenadas; %e presentan una serie de opciones que hay que ordenar. 1artes de un ,uestionario. $a actividad de la realizacin de cuestionarios puede estar ligada a la consecucin de ciertas tareas que el evaluador ha cre"do conveniente realizar .actividad combinada de varios mtodos de evaluacin0 para medir aspectos interactivos del sistema. En estos casos es recomendable dividir el cuestionario en tres partes;
o

o o

1re5tarea; $as preguntas de esta seccin suelen ser generales acerca de ciertas habilidades del usuario .esta parte suele aprovecharse para recoger informacin 8til acerca del perfil del usuario0. 1ost5tarea; Esta seccin se repetir tantas veces como tareas tenga que resolver el usuario. 1ost5test; Esta seccin recoger aspectos generales acerca de la percepcin gomal del usuario tras la consecucin de las diferentes tareas planteadas.

<eflexin sobre los cuestionarios y las entrevistas; El cuestionario es menos flexible que la entrevista pero puede llegar a un grupo ms numeroso y se puede analizar con ms rigor. %e puede utilizar varias veces en el proceso de dise@o. 9 su vez la entrevista tiene el factor /interactividad/ entre el evaluador y el usuario lo que es una /arma de doble filo/; 1ermite por una parte mejorar la comprensin de ciertos aspectos mientras que por otra suele acabar con la prOrdida de la estructura inicial que el evaluador se hab"a propuesto. *s adelante al hablar de las *tricas de Asabilidad .punto Q.3.6.30 veremos una serie de cuestionarios especialmente dise@ados para evaluar la usabilidad de los sistemas interactivos. Inicio de la ventana

Grabacin del uso

$a tcnica grabacin de uso ms conocida como anlisis de logs o simplemente logging se basa en /grabar/ o /recoger/ todas las actividades realizadas por el usuario 2'

con el sistema para su posterior anlisis. 1ara ello es preciso de una aplicacin secundaria que realice automticamente esta labor que pase adems totalmente desapercibida por el usuario. El logging implica disponer en el ordenador de una ampliacin del sistema que recoja automticamente estad"sticas sobre el uso detallado del sistema. Es 8til porque muestra cmo los usuarios realizan su trabajo real y porque es fcil recoger automticamente datos de una gran cantidad de usuarios que trabajan bajo diversas circunstancias &El logging implica disponer en el ordenador de una ampliacin del sistema que recoja automticamente estad"sticas sobre el uso detallado del sistema Es 8til porque muestra cmo los usuarios realizan su trabajo real y porque es fcil recoger automticamente datos de una gran cantidad de usuarios que trabajan bajo divrsas circunstancias &19G-6). 7"picamente un registro de la interfaz contendr estad"sticas sobre la frecuencia con la que cada usuario ha utilizado cada caracter"stica en el programa y la frecuencia con que los diversos eventos de inters .tales como mensajes de error0 han ocurrido. $a estad"stica que muestra la frecuencia del uso de comandos y de otras caracter"sticas del sistema se puede utilizar para optimizar caracter"sticas usadas frecuentemente y para identificar las caracter"sticas que se no utilizan o se utilizan raramente. $a estad"stica que muestra la frecuencia de las diversas situaciones de error y el uso de la ayuda se puede utilizar para mejorar la usabilidad del sistema .reajustando las caracter"sticas que causan la mayor parte de los errores y la mayor"a de los accesos a la ayuda en l"nea0. 1rocedimiento. El registro se realiza generalmente o bien modificando drivers del sistema como por ejemplo del ratn del teclado o de otras partes del sistema que permitan registrar las acciones del usuario o modificando la aplicacin que estamos probando. Este 8ltimo mtodo suele ser el preferido ya que hace ms fcil registrar acontecimientos de inters. %i los 8nicos datos disponibles son entrada de informacin y salida sin procesar es mucho ms dif"cil analizar los acontecimientos de gran inters para el uso del sistema tal como situaciones del uso de alguna caracter"stica o de error. %i el sistema equipado se ejecuta en una unidad central o en sitios de trabajo con un espacio compartido del fichero es fcil recoger datos de registro simplemente copiando los ficheros de diario de cada usuario en los intervalos regulares. %i no puede ser necesario recoger datos de registro a travs de correo electrnico automticamente o pidiendo que los usuarios ejecuten peridicamente un programa que env"e el fichero por correo. ,aracter"sticas. $as principales caracter"sticas que definen este mtodo son;
o

<esulta ser un mtodo muy econmico puesto que pueden analizarse las acciones de un n8mero de usuarios muy elevado prcticamente con el mismo coste.

22

o o o

#o se necesita la presencia f"sica de los usuarios .o si ste es realizado para analizar sitios Deb no es necesario ni un espacio especial para la tarea0. 1uede realizarse remotamente lo que permite evaluar un gran n8mero de datos de infinidad de usuarios sin desplazarse a su lugar de procedencia. $os datos suelen tener un formato estndar lo que facilita la comparacin de datos seg8n diferentes criterios .meses d"as semanas pa"ses etc.0. $os resultados se obtienen de manera instantnea. #o es necesario esperar a un anlisis especial de expertos para entender qu ha pasado ni se necesitan transcripciones ver cintas de v"deo etc. 1ermite tener al usuario en su entorno habitual .el log se recoge con el usuario en su ordenador sin sentirse observado ofreciendo datos ms reales sobre el uso0. *uestras amplias .normalmente estaremos hablando de miles de usuarios0. *uestreo de los usuarios a lo largo del tiempo recogiendo as" su variabilidad. Est especialmente indicado para analizar sitios Deb; %e detecta fcilmente el verdadero uso del sitio .pginas ms vistas palabras ms buscadas etc.0. Esta tcnica se puede utilizar en las etapas de prueba de versiones avanzadas del sistema de despliegue o para el redise@o de aplicaciones existentes .caso para el cual es muy indicado0.

1uede observarse que esta tcnica es muy apropiada para analizar las acciones que los usuarios realizan en los sitios Deb. El anlisis de los archivos de logs que los usuarios annimamente van dejando en los servidores Deb permite realizar reajustes al sitio para mejorar entre otros aspectos la usabilidad del mismo.

2!

$a informacin acerca de los gustos del usuario las quejas las necesidades y la identificacin de requisitos son informaciones indispensables sobre todo en etapas tempranas del proceso de desarrollo. 1or tanto hay que descubrir y aprender hay que generar ideas de dise@o y va a resultar de especial inters que las metodolog"as 5a aplicar preferentemente en una primera fase5 proporcionen informacin relacionada con el uso y las posibilidades de acceso de un producto que a8n no se ha empezado a fabricar. En este tipo de mtodos se realiza hablando con los usuarios observndolos usando el sistema en trabajo real y obteniendo respuestas a preguntas verbalmente o por escrito.

testing
1. T/0&(0#' .! T!')(&2
'.

:.1 C*&0!6)*' G!&!%#$!'7 :a medida de la usabilidad tiene raices en conceptos y tcnicas de%

9sicolog*a e-perimental. An lisis estad*stico de datos

@na buena combinacin de tcnicas es%

9rotocolo de Lpensar en voz altaL. 3edida de rendimiento. 3!)*.*$*2;#7

*edir la usabilidad

tarea.

Se elige un grupo de usuarios que realicen una serie de tareas espec+ficas en el escenario del site ba#o estudio. 2bservacin directa de la operativa de los usuarios y medicin de datos% $unto tiempo tardan en reali ar cada tarea. $untos errores cometen al reali ar cada 3u dificultades !an tenido durante la reali acin de una tarea. &eterminar qu es lo que realmente se pretende averiguar%

3u aspectos de la interactividad de los usuarios con el site se quieren realmente estudiar. &ividir el ob#etivo general en ob#etivos simples fcilmente medibles. Disear el Test: 4dentificar el colectivo de usuarios para las

2=

pruebas.

&eterminar el dise,o e0perimental% de qu forma se organi arn y e#ecutarn las pruebas para eliminar del e0perimento las variables sin inters.

Desarrollar las tareas que los usuarios realizarn durante cada experimento y el escenario asociado. Especificar las mquinas y software auxiliar, as+ como otros medios )video, audio, espe#os, capturadores de pantalla...*, para las pruebas.:

Identificar personal requerido: para e0plicar las pruebas, recoger datos, etc.: 7esters ;acilitador 3oderador 4bservadores onseguir usuarios de manera que resulten una muestra representativa%: Esta!lecimiento de la prue!a: .reparacin de los aparatos de medida. .reparar la muestra de usuarios que reali arn las pruebas. E"ecuci#n de la prue!a: .reparacin del su#eto para la prueba% normalmente estar incmodo. 5ay que darle instrucciones y e0plicarle las reglas del #uego. 6Se prueba el site no el usuario7.

E#ecucin en s+ del test y toma de datos% normalmente sin muc!a interaccin con el usuario, salvo aquellas preguntas que puedan ayudarnos a determinar porqu !i o alguna accin.

Interrogar al usuario: &iscutir la prueba con el usuario, una ve finali ada. $nalizar los datos:

prueba.

&eterminar primero los grandes problemas de usabilidad% normalmente ya se !abrn detectado durante la

de tareas, etc.

8esumir y esquemati ar los datos de rendimiento recogidos, tales como tasas de error, duraciones

8esumir y esquemati ar los datos de preferencias del usuario durante la prueba, en base a lo observado, lo comentado con l, sus observaciones, lo e0presado en cuestionarios, etc.

0 #&.*

*edir la usabilidad
$urante todo el ciclo de desarrollo del proyecto.

2A

2.

:.2 P%*)*0*$* .! <P!&'#% !& V*= A$)#<7 $urante una prueba de usabilidad el usuario debe e-presar en voz alta sus impresiones, sentimientos, pensamientos y opiniones sobre lo que est sucediendo, cmo, porqu y como le parecer*a a l que debiera ser el comportamiento del site. 3!)*.*$*2;#7

1rotocolo de pensar en

voz alta

Se recogen los comentarios y observaciones del usuario, bsicamente en cuanto a la forma en la que este "vive" su e0periencia con el interfa , las situaciones que le son incmodas y comportamientos no9naturales y su modelo mental en la interactuacin con el site.

:sicamente es una tcnica cualitativa. Es importante tanto lo e0presado por el usuario, como la forma en que lo !ace. .robablemente ser bueno recoger algunas de sus e0presiones en modificaciones futuras del interfa .

0 #&.*

)($(=#%

1rotocolo de pensar en voz alta

$urante todas las fases del desarrollo del proyecto.

=.

:.: M/)*.* .! C*-D!'0 ,%(3(!&)*7 2 participantes intentan realizar una tarea durante la prueba (untos y de forma colaborativa, mientras el e-perto en usabilidad les observa. :a venta(a sobre el 9rotocolo de 9ensar en <oz Alta es que con 2 participantes las alternativas a una dificultad de usabilidad se suceden muc)o antes, sintindose el usuario menos desamparado y obtenindose de su intercambio de comentarios m s informacin sobre la percepcin del interfaz.

*todo de co5 descubrimiento

3!)*.*$*2;#7

Se prepara el escenario y se entrega a los ; usuarios la secuencia de tareas a reali ar.

sistema. 0 #&.* )($(=#%

Se les pide comenten entre ellos como van a reali ar cada cosa y sus sensaciones y opiniones sobre la interactividad con el

*todo de co5descubrimiento
$urante todas las fases del desarrollo del proyecto. Es

ideal para sistemas de car cter colaborativo, 5or8flo5, group5are, etc.

2B

A.

:.4 P%*)*0*$* .! <R!'6*&.!% P%!2 &)#'<7 Al usuario se le )acen preguntas durante la prueba relativas a como realizar las tareas, alternativas a acciones, etc. Sus respuestas nos pueden informar que partes del interfaz son superfluas, cuales obtusas, etc. :a venta(a sobre el 9rotocolo de 9ensar en <oz Alta es que con 2 participantes las alternativas a una dificultad de usabilidad se suceden muc)o antes, sintindose el usuario menos desamparado y obtenindose de su intercambio de comentarios m s informacin sobre la percepcin del interfaz. 3!)*.*$*2;#7

1rotocolo de responder

preguntas

Se e0plica al usuario el escenario y funcionamiento de la prueba y se le proporciona la relacin de tareas a reali ar, pidiendole que comente en vo alta sus impresiones durante la prueba ).rotocolo de .ensar en <o (lta*.

Sin embargo tambin se le !arn preguntas espec+ficas sobre la reali acin de tareas concretas. Se tomarn notas sobre aspectos relevantes de sus respuestas.

(l igual que en el .rotocolo de .ensar en <o (lta, es una tcnica cualitativa. Es importante tanto lo e0presado por el usuario, como la forma en que lo !ace.

0 #&.*

)($(=#%

1rotocolo de responder preguntas

$urante todas las fases del desarrollo del proyecto.

B.

:.> M!.(.# .! R!&.(3(!&)*7 Son pruebas encaminadas a obtener datos cuantitativos de la realizacin de tareas de los usuarios en el site. :as mtricas obtenidas pueden ser condicionantes del desarrollo del proyecto. 3!)*.*$*2;#7

*edida de rendimiento

.rimero y fundamental es establecer el propsito de la prueba, los ob#etivos y factores a medir, dise,o de las pruebas y e#ecucin de las mismas%

Los ob#etivos deben ser cuantificables. El dise,o e0perimental es muy importante% se debe evitar que en la medida de un factor influyan indirectamente otras variables del dise,o.

del problema. 0 #&.* )($(=#%

Los datos obtenidos no refle#an la totalidad

*edida de rendimiento
$urante las fases iniciales del desarrollo del proyecto,

para tener indicadores cuantitativos de aspectos o componentes del

2C

sistema.

$urante el ciclo de desarrollo para comparar las medidas aisladas con el comportamiento de dic)os componentes en el conte-to integrado del sistema.

D.

:.? S!2 (3(!&)* *0 $#%7 Se mide el discurrir de la mirada del usuario durante la prueba de usabilidad. Se usan tecnolog*as tales como%

Electrodos de superficie :entes de contacto marcadas " maras con procesamiento de im gen Seguidores de refle(os 3!)*.*$*2;#7

%eguimiento ocular

El equipo de seguimiento ocular es muy caro. =ormalmente son medidas que se reali an en laboratorios de usabilidad especiali ados que disponen de estos equipos.

0 #&.*

)($(=#%

%eguimiento ocular
Se usa slo en aspectos del desarrollo dnde la b.squeda

de ob(etos en el interfaz que realiza el usuario puede resultar cr*tica o muy significativa en trminos de usabilidad.

)!') En los mtodos de evaluacin por test, usuarios representativos traba(an

en tareas concretas utilizando el sistema +o el prototipo, y los evaluadores utilizan los resultados para ver cmo la interfaz de usuario da soporte a los usuarios con sus tareas

7est

2D

En los mtodos de usabilidad por test usuarios representativos trabajan en tareas utilizando el sistema 5o el prototipo5 y los evaluadores utilizan los resultados para ver cmo la interfaz de usuario soporta a los usuarios con sus tareas. $os principales mtodos de evaluacin por test son;

*edida de las prestaciones

Este mtodo de evaluacin est basado en la toma de medidas acerca del rendimiento u otro tipo de aspecto subjetivo que afecte a la usabilidad del sistema para lo que ser necesario disponer bien sea del sistema ya implementado o de un prototipo que permita evaluar estos aspectos.

1ara ello existen una serie de caracter"sticas importantes a tener en cuenta; a. #o debemos olvidar que el objetivo primordial es mejorar la usabilidad del productoO no debe confundirse con un test de funcionalidad que tiene como objetivo garantizar que el producto funcione de acuerdo con las especificaciones. b. $os participantes en el test .que evidentemente sern usuarios reales realizando tareas reales0 se analizarn tanto en la manera como utilizan el producto como midiendo el tiempo que les lleva realizarlo. c. 9 pesar de que tambin puede realizarse en el entorno del usuario este mtodo es muy apropiado realizarlo en un laboratorio de usabilidad. An aspecto primordial para la realizacin del test ser la seleccin de tareas que los usuarios debern realizar. $os siguientes puntos debern tenerse presentes a la hora de escoger dichas tareas; d. 7areas que demuestren problemas de usabilidad. El criterio ms importante para seleccionar tareas es utilizar aquellas que prueben los problemas potenciales de usabilidad del producto. e. 7areas sugeridas por la propia experiencia. $os desarrolladores siempre tienen algunas ideas respecto de dnde encontrar problemas. %aben qu partes del producto fueron ms dif"ciles de dise@ar y cules son los problemas que se han de probar. f. 7areas derivadas de otros criterios como por ejemplo las tareas que son dif"ciles de recuperar despus de un error. g. 7areas que los usuarios harn con el producto. %e seleccionan tareas habituales en el d"a a d"a de los usuarios en orden para optimizar la usabilidad de los aspectos ms cotidianos.

=uncionamiento del mtodo. ,omo se ha mencionado anteriormente trataremos en primer lugar de comprender qu es lo que se puede medir. 1ara ello podemos recoger;
o

*edidas de rendimiento. Esto quiere decir contar las acciones y los comportamientos. Este tipo de medidas son cuantitativas pudindose

2E

contar personas n8mero de errores cometidos cuntas veces repiten el mismo error... *edidas subjetivas. Esto quiere decir percepciones de las personas opiniones y juicios. 1ueden ser cuantitativas o cualitativas.

Inicio de la ventana S 1ensando en voz alta .thinFing aloud0. En este mtodo de evaluacin conocido como /thinFing aloud/ descrito por #IE$%E# &#IE'B) se pide a los usuarios y de forma individual que expresen en voz alta y libremente sus pensamientos sentimientos y opiniones sobre cualquier aspecto .dise@o funcionalidad...0 mientras que interaccionan con el sistema o un prototipo del mismo. <esulta ser un mtodo altamente eficaz para capturar aspectos relacionados con las actividades cognitivas de los usuarios potenciales del sistema evaluado. 1rocedimiento. %e proporciona a los usuarios el prototipo a probar y un conjunto de tareas a realizar. %e les pide que realicen las tareas y que expliquen en voz alta qu es lo que piensan al respecto mientras estn trabajando con la interfaz describiendo qu es lo que creen que est pasando por qu toman una u otra accin o qu es lo que estn intentando realizar. En definitiva Tcuantas ms impresiones mejorU. 1ensando en voz alta permite a los evaluadores comprender cmo el usuario se aproxima al objetivo con la interfaz propuesta y qu consideraciones tiene en la mente cuando la usa. El usuario puede expresar que la secuencia de etapas que le dicta el producto para realizar el objetivo de su tarea es diferente de la que esperaba. 9unque el principal beneficio del mtodo es una mejor comprensin del modelo mental del usuario y la interaccin con el producto hay asimismo otros beneficios como por ejemplo conocer la terminolog"a que el usuario utiliza para expresar una idea o funcin que deber"a ir incorporada en el dise@o del producto o en su documentacin. Este mtodo tiene como ventaja ms importante la simplicidadO requiere realmente poca experiencia para poderlo llevar a cabo y puede proporcionar ideas muy 8tiles acerca de los problemas con una interfaz &?IL'B pg. BM3). +tras ventajas importantes del mtodo son;
o

o o

Jue puede ser utilizado para observar cmo el sistema se utiliza actualmente .complemento para el mtodo de +bservacin de ,ampo visto anteriormente0. Jue puede realizarse en todas las fases del ciclo de vida .incluso en las ms iniciales0 y con cualquier tipo de prototipo. Jue se trata de un mtodo muy econmico.

N como principales inconvenientes tenemos; !F

o o

$a informacin proporcionada es subjetiva y selectiva .depender de las tareas escogidas0. El proceso de observacin puede alterar la manera en la que los usuarios realizarn sus tareas pudiendo obtener vistas parciales .describir lo que uno hace a menudo cambia la forma de hacerlo0.

>ariante del mtodo. Ana variante del thinFing aloud es mtodo conocido como evaluacin cooperativa que estimula al usuario a verse a s" mismo como un colaborador de la evaluacin ms que un simple sujeto experimental. Inicio de la ventana

Interaccin constructiva

Este mtodo conocido tambin con el nombre de aprendizaje por codescubrimiento es una derivacin del pensando en voz alta e implica tener en vez de uno a dos usuarios realizando conjuntamente cada test del sistema &+*9M(). $a principal ventaja de este mtodo es que la situacin del test es mucho ms natural que el pensar en voz alta con usuarios individuales ya que las personas normalmente verbalizan cuando tratan de resolver un problema conjuntamente y adems hacen muchos ms comentarios. Este mtodo tiene la desventaja que los usuarios pueden tener diferentes estrategias de aprendizaje. An aspecto a tener en cuenta es que la interaccin constructiva requiere el doble de usuarios que el mtodo de pensar en voz alta aspecto importante a considerar si ello puede tener repercusiones econmicas. Inicio de la ventana

7est retrospectivo

%i se ha realizado una grabaci3oacuteOn en v"deo de la sesin de test es posible recoger ms informacin haciendo que el usuario revise la grabacin &!EHM2). $os comentarios del usuario mientras est revisando el v"deo son ms extensos que mientras ha estado trabajando en la tarea de test y por tanto es posible que el evaluador pare el v"deo y pregunte al usuario con ms detalle sin tener miedo de interferir con el test que esencialmente ha sido completado. El aspecto negativo ms evidente es que con cada usuario se tarda como m"nimo el doble del tiempo necesario con cualquier otro mtodo. Inicio de la ventana

*todo del ,onductor !'

El mtodo del conductor &*9,'6) es algo diferente de estos mtodos de test vistos hasta ahora en los que hay una interaccin expl"cita entre el usuario y el evaluador .o conductor0. El 8ltimo trataba de interferir lo menos posible al usuario mientras realizaba el test. Este caso resulta ser totalmente al contrario en este aspecto; %e conduce al usuario en la direccin correcta mientras se usa el sistema. ?urante el test el usuario puede preguntar al evaluador cualquier aspecto relacionado con el sistema y ste le responder. Este mtodo se centra en el usuario inexperto y el propsito del mismo es descubrir las necesidades de informacin de los usuarios de tal manera que se proporcione un mejor entrenamiento y documentacin al mismo tiempo que un posible redise@o de la interfaz para evitar la necesidad de preguntas. Inicio de la ventana

+rdenacin de tarjetas .card sorting0.

Este mtodo tiene un enfoque distinto a los presentados anteriormente y a pesar de que como veremos suele asociarse con la implementacin de la 9rquitectura de la Informacin en el dise@o de sitios Deb es un mtodo completamente vlido para relacionar la informacin de cualquier medio interactivo. 9l comenzar un nuevo ejercicio de dise@o de la informacin es normal encontrarse con una larga lista de "tems sin relacionar que /hay que incluir/ y /no sabemos cmo hacerlo/. El reto radica en organizar esta informacin de manera que sea 8til y comprensible para los usuarios del sistema. 9unque es cierto que cuidadas investigaciones sobre el anlisis de la informacin pueden revelar algunas pistas dif"cilmente podr determinarse qu tpicos deben agruparse entre ellos. $a tcnica conocida como ordenacin de tarjetas o card sorting es la utilizada para conocer cmo los usuarios visualizan la organizacin de la informacin. El dise@ador utiliza las aportaciones de los usuarios para decidir cmo deber estructurarse la informacin en la interfaz. %e trata de una tcnica simple 5fcil de entender y de aplicar5 barata rpida y que involucra a los usuarios que es especialmente indicada cuando disponemos de una serie de "tems que precisen ser catalogados as" como para decidir la estructura organizativa de cualquier sistema de informacin. Esta tcnica tiene demostrada utilidad para desarrollar sitios Deb para la cual est especialmente recomendada &EE>-B). <ealizacin. $os pasos a seguir para implementar una ordenacin de tarjetas son los siguientes; !2

a. ?eterminar la lista de tpicos Identificar la lista de los "tems a ordenar. Esta lista no deber"a ser muy extensa .ha de ser manejable0 a la vez que debe ser comprensible para todos los participantes de la sesin. El evaluador no debe poner ning8n tipo de indicacin que pueda influenciar a los usuarios es su decisin as" como ning8n tpico que induzca a la agrupacin de trminos .ej.; 9rchivo edicin =9Js0. b. ,rear las tarjetas ,ada tpico deber escribirse en una tarjeta .papel cartn0 que ocasionalmente puede adjuntar alg8n tipo de explicacin .aunque no es muy recomendable0. ?eber adems proporcionar unas cuantas tarjetas en blanco a los participantes. c. %eleccionar a los participantes $os participantes preferentemente sern usuarios finales .gerentes y otros implicados no son usuarios finales0 de quienes deberemos estar seguros que representan fielmente a grupos de usuarios potenciales del sistema. d. 1roceder con laRs sesinRes de ordenacin ,ada sesin debe comenzar con una explicacin del mtodo y de los objetivos animando a todos los participantes a organizar las tarjetas y etiquetar en las tarjetas en blanco los grupos seg8n sus criterios personales. El organizador de la sesin debe tomar nota de todo aquello que pueda resultar relevante para la evaluacin final.

!!

e. 9nalizar las agrupaciones Ana vez han concluido todos el evaluador deberV analizar todas las agrupaciones en un ejercicio de /anlisis democrtico/ para identificar aquellas agrupaciones ms frecuentes para poder decidir la estructura final. Existen programas informticos espec"ficos &7+<-4) que pueden ayudarnos mucho en esta labor de s"ntesis. Errores a evitar. $a constante aplicacin de esta tcnica en todos los proyectos relacionados demuestra que el grado de conocimiento que aporta la experiencia prctica est por encima de la teor"a de dicho conocimiento lo que ha dado lugar a una relacin de errores t"picos que no se encuentran referenciados en la bibliograf"a cient"fica. $os errores ms frecuentes son; a. $os resultados de las agrupaciones suelen carecer de la fiabilidad necesaria si la comunicacin previa a la realizacin del test con el usuario no ha sido la apropiada. El evaluador debe expresarles los objetivos claros de la prueba de forma /muy concreta/ para que los usuarios sepan /exactamente que se espera de ellos/ durante la prueba. b. 1or otra parte el evaluador suele caer en la falsa tentacin de /querer facilitar el trabajo de los usuarios/. ,on tal objetivo reduce el n8mero total de tarjetas a base de crear tarjetas que en realidad son agrupaciones de unidades de informacin con entidad propia lo que confunde al usuario y dificulta el anlisis de los resultados esperados. S !erramientas para el ,ard %orting .en recursos CC softDare0.

7abla comparativa de los distintos mtodos de evaluacin de la usabilidad de los sistemas interactivos

!=

$eyenda de la tabla; !A

=9%E; 9< .9nlisis de <equisitos0 ? .?ise@o0 I .Implementacin0 y $ .$anzamiento0 %i una fase est en negrita indica que es la fase ms adecuada para la aplicacin del mtodo $ugar; $ .$aboratorio0 E .Entorno0

!36;%(0*

C*&' $)# 8I&@ (%59

M*.!$#.* A&#$;)(0*

!B

S(3 $#0(1&

Me han solicitado que evale un sitio web, desde un punto de vista tcnico. Como siempre he dicho, no soy un profesional del rea ni me considero un e!perto, aunque ten"o e!periencia y el conocimiento suficiente para, al menos, tener corriendo este blo". #e tratado de buscar informaci$n sobre pautas para hacer este tipo de evaluaciones, y la verdad es que no he encontrado mucho% la mayor&a de los resultados al buscar web site evaluation est n m s relacionados con c$mo determinar la credibilidad'utilidad de un sitio web como fuente de informaci$n para traba(os de investi"aci$n )al"o muy importante, por lo dem s*, aunque en WWW CyberGuides for Web Evaluation he hallado dos "u&as de evaluaci$n, una para el contenido y la otra para el dise+o. #e sacado al"unas ideas de ellas, pero en este caso preferir por una evaluaci$n m s cualitativa y profunda que la que plantean en esas "u&as ,que, por otra parte, me parecen bastante adecuadas.

-.or qu crear una pauta de evaluaci$n/ 0o se trata de un tema de objetividad, sino de poder presentar al"o que vaya m s all de la opinologa para que pueda ser un verdadero aporte ,porque claro, o(al el ob(etivo de la evaluaci$n'cr&tica contemple la entre"a de su"erencias y me(oras. 1inalmente, considero que otro factor fundamental al momento de plantear una evaluaci$n'cr&tica es la declaraci$n de la propia posici$n desde la que se plantea, tanto en relaci$n con las preferencias personales como tambin en cuanto a la declaraci$n de intereses al respecto. Me e!plico% si bien ar"umentar a favor de la usabilidad es una cuesti$n tcnica, la postura que cada uno tiene frente a ella puede tener al"o m s personal )por e(emplo, en cuanto a su importancia relativa a otros factores* en el que se me2clan datos duros con la e!periencia y percepci$n personal. 3n cuanto a lo se"undo, me parece un poco m s claro% no es lo mismo evaluar un sitio web porque s& a evaluarlo porque te podr&an encar"ar que lo reconstruyeras de c$mo es tu evaluaci$n. Con estas cuestiones en mente, paso a plantear seis aspectos a considerar en la evaluaci$n de un sitio web.

Aspectos a considerar en la evaluacin de un sitio web

1. Uso de tecnologas

!C

3ste aspecto se refiere a la elecci$n de tecnolo"&as para la presentaci$n del contenido y la nave"aci$n a travs del sitio web. 4 sicamente, se trata de determinar si de acuerdo al prop$sito del sitio estas elecciones han sido acertadas% por e(emplo, un sitio que pretende principalmente presentar te!tos, -deber&a estar construido en 1lash/ .or otra parte, si la intenci$n es presentar videos, -es m s conveniente mostrarlos en el mismo sitio a travs de una interfa2 1lash o de(ar los enlaces para descar"ar archivos de 5uic67ime'8indows Media/ 9bviamente, en la mayor&a de los casos la elecci$n de base ser ):*#7M;<C==. ;a utili2aci$n de otras tecnolo"&as depender del prop$sito del sitio%

o o

1lash sirve )en mi opini$n* solamente para presentar aplicaciones interactivas, contenido multimedia, (ue"os. .antallas de presentaci$n o efectos de animaci$n en la nave"aci$n por lo "eneral no aportan absolutamente nada

2.

R se ha convertido en una opci$n indispensable para sitios que se actuali2an con frecuencia, como blo"s, peri$dicos, portales de noticias, etc. o ;a opci$n de ofrecer documentos a travs de archivos P!" me parece conveniente cuando los te!tos son bastante e!tensos, comple(os, o necesariamente deben estar presentados en un determinado formato )p. e(% documentos "ubernamentales*. >dem s, pueden ser usados en lectores de libros electr$nicos o 3n este punto incluir&a tambin la elecci$n de un sistema de gestin de contenido, al"o muy necesario en muchos sitios y totalmente indispensable en otros )no me podr&a ima"inar un diario en l&nea a punta de puro #7M;*. Cdigo: validez, semntica =i el punto de partida para cualquier web es ):*#M7;<C==, es necesario cuidar que las p "inas estn apropiadamente estructuradas, si"uiendo los est#ndares web. M s all de los problemas del $uir%s mode, la valide2 del c$di"o tiene que ver con la calidad "lobal del traba(o de un webmaster% una p "ina con c$di"o inv lido puede ser una se+al de que quien la ha constru&do (am s ha tomado su traba(o lo suficientemente en serio como para revisar las especificaciones del W&. ?uardando las proporciones, es como que una persona crea que puede ser ciru(ano sin leer (am s un libro de anatom&a, o confundiendo un ri+$n con el h&"ado. =aber dise+ar )de forma amateur o profesional* no implica saber crear p "inas web, as& como saber ):*#7M;<C== no implica saber dise+ar. .or supuesto, saber ocupar 'acromedia !reamweaver o 'icrosoft "rontpage tampoco facultan a una persona para llamarse webmaster como tampoco saber utili2ar Adobe P(otos(op constituye un dise+ador. .or otra parte, quien tome en serio su pe"a probablemente estar al menos familiari2ado con el concepto de sem#ntica, por lo que sus documentos no solamente estar n bien estruturados, sino adem s el uso del marcado ser apropiado a las caracter&sticas de cada elemento y sus atributos.

3.

Esttica: adecuacin a er!il 5ui2 s uno de los puntos m s dif&ciles de evaluar de forma ob(etiva sea la esttica de un sitio@ creo que para escapar del me "usta'no me "usta, la me(or alternativa es considerar el dise+o como un elemento que debe con(u"arse con la identidad del producto, or"ani2aci$n o lo que sea que est detr s del sitio web. 3s probable que aquelloAqueAbuscaApresenciaAenAinternet ya ten"a una ima"en definida antes de comen2ar a construir su sitio, por lo que el sitio podr&a plantearse en la mayor&a de los casos como una e!tensi$n de ese concepto de dise+o% ser&a bastante raro ver un sitio de CocaACola con colores que no fueran ro(o, blanco y ne"ro )di"amos, verde, morado y "ris*. 3n caso de no tener una ima"en predefinida, el mismo car cter de aquelloAqueAest Adetr sAdelA sitio determinar las posibilidades estticas% me e!tra+ar&a bastante ver un sitio web para un hospital utii2ando principalmente colores oscuros, o una funeraria con colores festivos.

".

Usa#ilidad 1undamental, indispensable. eg)n la Wi%ipedia, abarca no solamente la capacidad de uso, sino tambin la facilidad de uso ,los remito al art&culo para mayor informaci$n al respecto. *a%ob +ielsen es sin lu"ar a dudas el "ur de la usabilidad@ sin lle"ar a ser tan e!tremista como a veces pareciera que l lo es, considero que su punto de vista es muy ra2onable% la

!D

mayor&a de los visitantes a un sitio web )o usuarios del sitio* se limitan a ho(ear )-u o(ear/* la p "ina. =i no e!isten claros indicios de c$mo funcionan sus elementos o c$mo est estructurada, lo m s probable es que el usuario se sentir frustrado y de(ar el sitio. 3n pocas palabras% nadie deber&a verse en la necesidad de aprender c$mo usar un sitio web, sino que deber&a ser lo bastante obvio como para que sea usado de un modo intuitivo. $. %ccesi#ilidad Como planteaba en cierta oportunidad, la accesibilidad y la usabilidad son conceptos que suelen ser pensados como un plus de un sitio web@ como si fueran al"o accesorio, conceptos de moda que hay que implementar pero no repercut&an mucho en la calidad del sitio. Besde mi punto de vista, la aplicaci$n de estos conceptos al desarrollo de sitios web no es un plus, es un ,must-, es decir, una obli"aci$n, un deber. #ay que pensar en la accesibilidad como un principio rector del dise+o% no se trata solamente de $ue los usuarios con discapacidades visuales puedan utili.ar el sitio web , sino en cualquier obst culo al acceso y utili2aci$n de los contenidos de un sitio. B C 3 ? 9 ; > 1 D 3 0 7 3 comentaba en su art&culo Paradoja accesible% no tiene sentido pensar en un sitio web accesible que a la ve2 est mostrando una "ran cantidad de elementos que consuman tal cantidad de recursos en el ordenador del usuario que lo ha"an poco accesible, tal como ocurre en varios sitios de peri$dicos que intentan se"uir las pautas de accesibilidad pero a la ve2 revientan el computador del usuario mostrando EF elementos 1lash con publicidad. &. Com ati#ilidad 1inalmente, esta cate"or&a abarca parte de los dos anteriores, y se refiere a una cuesti$n b sica% un sitio web debe verse bien y funcionar bien independientemente del navegador $ue utilice. 3sta no es una cuestin del pasado cuando Cnternet 3!plorer empe2aba a introducirse y crecer en un mercado dominado por 0etscape 0avi"ator% a pesar de que en el presente es inne"able que la mayor&a de los usuarios utili2an M = C 3 , la utili2aci$n de otros nave"adores como "irefo/ u 0pera va en aumento y no es despreciable. =e"n las estadsticas de W& c(ools, a >"osto de este a+o, al"o m s de un &12 de los usuarios utili2a nave"adores distintos a M = C 3 . 1inalmente, no debemos olvidar que e!isten otros sistemas operativos aparte de 8indows% ;inu! y Mac tambin van en aumento, por lo que desarrollar un sitio web que s$lo sea utili2able en una plataforma y con un nave"adorG simplemente no es buena idea. Cuidar la valide2 del c$di"o "eneralmente resulta en sitios usables en la mayor parte de los nave"adores, el que suele fallar en (acer las cosas bien esG s&, adivinaron, M = C 3 .
3ags4 C 5 !esarrollo Web5 !ise6o5 7nternet5 893':

Artculos relacionados

obre fuentes y legibilidad Proyecto4 Revista Paralaje 7ncrustar im#genes en (ojas de estilo ;<7 y otros "ramewor%s C 3ipografas web y <buntu=:inu/ em#ntica en clases e ids Recuento >11?

!E