Ir al contenido | Versión móvil

miércoles, 31 de octubre de 2007

Prototype y Explorer 5

El objeto XMLHTTPRequest, base de lo que es AJAX, existe desde Explorer 5. Esto quiere decir que un desarrollo AJAX funcionará en Explorer 5.

Podríamos pensar que Prototype, una de las librerías más populares y utilizadas en desarrollos AJAX, sería compatible con Explorer 5. No hay documentación que lo afirme o lo niegue, pero parece lo razonable.

Bien, la triste conclusión de hoy es que la implementación de Prototype no es compatible con Explorer 5. La única confirmación a mi conclusión la he encontrado en Listado de librerías Ajax/DHTML. Portabilidad y compatibilidad con los navegadores.

No se acaba el mundo, mis cinco mil usuarios de Explorer 5 serán derivados a la versión accesible, la de toda la vida, con recarga de páginas, pero es una lástima que a pesar de que Ajax funciona en Explorer 5, no se haya tenido en cuenta este navegador en la implementación de Prototype.

¿Alguien me alegra el día y me dice que usa Prototype en Explorer 5 sin problemas?

lunes, 22 de octubre de 2007

HIJAX

Artículos relacionados
[14-11-13] Live Regions y WAI-ARIA. Cómo mejorar la accesibilidad de contenidos que se actualizan automáticamente
[07-09-07] WAI-ARIA. Introducción, referencias, ejemplos, herramientas
[26-05-07] AJAX accesible



El otro día me preguntaban qué era Hijax, si era la evolución de AJAX, o algo nuevo, o ¡qué era!, muy preocupado por si se estaba perdiendo algo referente a AJAX. No me voy a extender mucho, ya habló de Hijax Fran Tarifa el otro día en Hijax: ¿Ajax accesible? (aunque no estoy de acuerdo con sus conclusiones)

Hijax es una metodología a seguir a la hora de realizar aplicaciones AJAX, que consiste en aplicar a estos desarrollos la estrategia que se conoce como "mejora progresiva", propia del diseño web, para que dichos desarrollos AJAX sean accesibles.

Jeremy Keith ya hablaba de aplicar la "mejora progresiva" a AJAX en marzo de 2005, antes de que se le ocurriera bautizar a esta metodología como Hijax, en su artículo Progressive enhancement with Ajax.

Parece que esto de Hijax es nuevo, pero Jeremy no se inventó el término ayer, sino el 1 de enero de 2006 a las 7:40, en el artículo Hijax. Supongo que esa Nochevieja fue sonada para sentarse a primera hora a hablar de Hijax [bromilla].

El caso es que últimamente se oye hablar mucho de Hijax, como algo nuevo, lo cual se debe en parte a sus ponencias como "Bulletproof AJAX (Ajax a pruebas de balas)" y en parte a ese curioso boca a boca exponencial (buzz) propio de Internet.

Esto de bautizar a todo con un nombre gancho es muy habitual (AJAX, Web 2.0, etc.) y muy eficaz para estar en boca de todos (o en blog de todos, como tendríamos que decir hoy en día), pero bueno, no está mal si eso ayuda a difundir buenas prácticas. Hay que reconocerle a Jeremy Keith que lleva ya años abogando por hacer las cosas bien, es simplemente que me hace gracia como de repente todo el mundo habla de algo cotidiano y habitual como si fuera muy novedoso por tener un nombre vistoso. Él mismo ironizaba:

I’ve even got a nice shiny buzzword for this technique: Hijax. (Hijax, Jeremy Keith) [1]


Pero dime, ¿en qué consiste eso de Hijax? Pues me temo que te va a decepcionar un poco, porque no es más que aplicar aquello que venimos recomendando una y otra vez: JavaScript no intrusivo a la hora de plantear alternativas accesibles.



El resumen es el siguiente:

1. Haz que la aplicación funcione sin AJAX mediante peticiones normales al servidor que recarguen la página.

2. Ahora añade JavaScript no intrusivo para incluir el código AJAX, de este modo, si el user-agent no admite JavaScript o está desactivado, la aplicación seguirá funcionando correctamente, puesto que el código es invisible y no afecta al funcionamiento de la página.

Según dice Jeremy, la clave es: Plan for Ajax from the start. Implement Ajax at the end.



Nada nuevo, pero si llamarle Hijax ayuda a difundir las buenas prácticas de la programación AJAX, pues nada: viva Hijax! todos a aplicar Hijax! es decir, a seguir haciendo las cosas bien.




[1]

There seems to be an inherent paradox in saying that you need to think about your server-side architecture but you should just be building old-fashioned page by page submissions before hijacking them with Ajax (Hijax, Jeremy Keith)


Hijax, vendría del término "hijack", secuestrar.



Artículos relacionados
[14-11-13] Live Regions y WAI-ARIA. Cómo mejorar la accesibilidad de contenidos que se actualizan automáticamente
[26-05-07] AJAX accesible I
[07-09-07] AJAX accesible II: WAI-ARIA
[27-03-09] AJAX accesible IV: Técnicas ARIA de las WCAG 2.0

lunes, 1 de octubre de 2007

La usabilidad como metodología para el desarrollo de una aplicación

Artículos relacionados
[15/03/2012] Estándares formales de usabilidad y su aplicación práctica en una evaluación heurística
[07-03-08] Metodología DCU MPlu+a
[11-03-08] Wireframes
[15-11-07] Disciplinas relacionadas con la usabilidad



Introducción

Cuando preguntas dentro del mundo de la informática "¿qué es la usabilidad?" dirigiéndote a aquellos que no son expertos en la materia, puedes obtener cualquier respuesta. Desde un "ni idea", a un "me suena", a un "¿lo del Nielsen ese?". Puede parecer imposible a los que nos dedicamos a esto, pero es la realidad.


Muchas personas confunden además los términos "usabilidad" y "accesibilidad", que sin bien están estrechamente relacionados, ni son sinónimos ni antónimos. Creo además que hay mucha más gente que sabe lo que es la accesibilidad (aunque lamentablemente lo reduzcan a "que los ciegos puedan acceder a una aplicación") que los que saben realmente qué es la usabilidad.


Cuando encuentras a alguien (hablo siempre de personas que no son profesionales de la usabilidad) que afirma que sí sabe lo que es la usabilidad, lo más habitual es que te digan que "se trata de conseguir que una aplicación sea fácil de usar" y muchos aluden a varias "reglas" para conseguirlo.


Para la mayoría de los profanos la usabilidad se reduce a una serie de reglas, reglas como "que los enlaces estén subrayados", "que los menús estén siempre en el mismo sitio", "poner migas de pan y un mapa del sitio".



Por supuesto es cierto que toda persona dedicada a la usabilidad debe, no ya conocer, sino tener interiorizadas unas pautas de usabilidad, pero la usabilidad es más que unas pautas, que unas leyes o que determinados estudios y personajes, la usabilidad supone toda una metodología de trabajo.




¿Por qué fracasó ese portal web?


Parecía el portal perfecto. Tanto los desarrolladores como los clientes estaban más que satisfechos. Era precioso, tenía mucha información, era rápido, no había errores, estaba exquisitamente programado, incluso era accesible doble-A.


Y sin embargo, cada vez recibía menos visitas, éstas abandonaban rápidamente el portal, nadie realizaba trámites o compras online…



Ese portal fracasó por una única razón, porque estaba centrado "en el cliente". El cliente redactó los textos, el cliente decidió cómo estructurar el portal, el cliente, el cliente, el cliente…



¿Y el usuario?


El portal no resultaba útil a los usuarios, quienes se sentían perdidos, incapaces de encontrar la información o realizar las tareas para las que entraron.



La usabilidad como metodología de trabajo: Diseño Centrado en el Usuario(UCD)


El Diseño Centrado en el Usuario(UCD) es una metodología estructurada de desarrollo de producto que implica a los usuarios a través de todas las etapas de desarrollo del mismo. El objetivo es crear un producto que aúne los objetivos de negocio de una organización y resuelva las necesidades de los usuarios.


Los beneficios son conocidos por todos: aumenta la productividad, la satisfacción del cliente y las ventas, se reducen costes, etc.


Podría basarme en muchas fuentes o citar mucha bibliografía para desarrollar el tema de la usabilidad como metodología de trabajo, pero voy a centrarme en una única fuente que me encanta y que creo que debería ser la web de cabecera de todo jefe de proyecto: la metodología desarrollada por el gobierno de EEUU en materia de usabilidad que se recoge en usability.gov


Seguramente tú hubieras escogido otras fuentes, ¿las compartes en los comentarios?


Esta metodología consta de 4 pasos:

  • Plan
  • Analyze
  • Design
  • Test & Refine



Voy a resumir brevemente cada paso. Para desarrollar cada apartado, ver ejemplos, etc. podéis acudir directamente a usability.gov



Plan

Think About the Process

Reflexiona sobre la audiencia que deseas atraer al portal y clasifícala por grupos, por roles en relación con el portal, etc.


Verifica tus presunciones previas acerca de los usuarios del portal: qué necesidades tienen, qué expectativas, qué nivel de conocimientos sobre el tema que trata, qué experiencia con sitios similares, etc.



Follow Research-Bases Guidelines

En este apartado se recogen las pautas de usabilidad que toda persona involucrada en la creación de un portal web (diseñadores, maquetadores, especialistas de usabilidad, etc.) debe interiorizar:


Develop a Plan

Se trata de realizar el Project Plan, establecer el alcance del proyecto, los objetivos, entender los requisitos, establecer el timeline, pensar en los recursos necesarios y los costes.


Assemble a Project Team

El siguiente paso lógico es crear el equipo de trabajo correctamente dimensionado y con los perfiles necesarios: especialistas en usabilidad y arquitectos de la información, diseñadores gráficos, escritores web, programadores, especialistas en la materia sobre la que trata el portal, etc.


Hold a Kick-Off Meeting

Kick-off meeting hace referencia aquí a la reunión interna de comienzo del proyecto, con tu equipo, para aunar criterios. Por kick-off meeting yo suelo entender la reunión con el cliente para hablar sobre los requerimientos del proyecto, los objetivos, sus usuarios, etc.


Lo más interesante de este apartado en la lista de preguntas que no pueden faltar en el kick-off meeting y que nos sirve para ambos casos.


Write a Statement of Work (SOW)

En este apartado se recoge el caso de que se vaya a subcontratar el diseño y las tareas de usabilidad, en cuyo caso es necesario redactar un SOW (se incluyen ejemplos) describiendo el trabajo que se debe realizar, el timeline, etc. de modo que el empresa aspirante pueda realizar una oferta. Se apunta también cómo valorar esa oferta.


Hire a Usability Specialist

Especifica cómo seleccionar a un experto cualificado en usabilidad, indicando qué conocimientos y experiencia es necesario que tenga.




Analyze

Evaluate Your Current Site

Se trata de evaluar el portal actual de la organización y contestar a tres preguntas: ¿cumple con los objetivos de la organización? ¿satisface las necesidades de los usuarios? ¿sigue las pautas de usabilidad?


Para contestar a estas preguntas se proponen distintas acciones: revisión de logs, test de usabilidad, revisión heurística, etc.


Learn About Your Users

Es este apartado se explican las diferentes técnicas para recopilar toda la información posible sobre los usuarios del portal: test de usabilidad, entrevistas contextuales, focus groups, etc.


Conduct Task Analysis

Se trata de estudiar las tareas que se pueden realizar en el portal, las que los usuarios intentar realizar y cómo las realizan. De este modo se puede establecer qué tareas son necesarias, refinando la navegación o la búsqueda para facilitar la manera más eficiente de realizarlas y emparejándolas con las metas de los usuarios.


Develop Personas

Este punto me encanta. Gracias a todo lo anterior tenemos claramente identificados a los grupos de usuarios de nuestro portal. Bien, pues se trata de que cada grupo sea representado por un personaje ficticio.


Se debe crear una ficha para cada uno de estos personajes, una ficha con foto, nombre y apellidos, datos personales (su edad, educación o etnia), datos profesionales (cargo y responsabilidades), datos referentes a sus objetivos, metas y tareas en relación con el portal, etc. Y por supuesto colgar estas fichas en la pared a la vista de todo el equipo.


¿Por qué se hace esto? Por muchas razones:

  • De este modo las metas y necesidades de los usuarios se convierten en el objetivo común de todo el equipo
  • El equipo se concentra en diseñar un portal para un número manejable de personajes que saben que representan las necesidades de muchos usuarios
  • Los diseños se evalúan constantemente contra los personajes
  • Los desacuerdos sobre el diseño se resuelven referenciándolos a los personajes
  • Etc.

Según Forrest muchas compañías como Microsoft desarrollan personajes porque permiten:

  • Una comprensión mejor de los clientes
  • Ciclos más cortos de diseño
  • Mejor calidad del producto

Write Scenarios

En este apartado se detalla cómo elaborar los escenarios. Un escenario es una historia corta sobre un usuario específico con una meta concreta en el portal, por qué viene al sitio y qué desea hacer.


Es crítico para el diseño del portal, puesto que si tienes los panoramas más comunes antes de construir el sitio, estarás centrándote en el usuario y las tareas que este desea realizar en el portal antes que en la organización y la estructura interna del mismo. Sabrás qué contenido debe tener el sitio y qué contenidos deben ser los más fáciles de encontrar y entender.


Set Measurable Usability Goal

Se trata de establecer metas mensurables de usabilidad en cuanto al tiempo para realizar una tarea, la exactitud con la que se realiza y el éxito en su realización.


Un ejemplo de meta mensurables sería: que el 95% de los viajeros sean capaces de realizar una reserva online en menos de dos minutos.




Design

Determine Web Site Requeriments

Antes de empezar el diseño, es necesario tener claros los requisitos, es decir, las características, las funciones y el contenido del portal, todo lo que debe tener y lo que debe admitir que los usuarios hagan.


El resto de pasos del diseño te ayudan a cerciorarte de que el sitio está organizado, escrito, y diseñado para satisfacer los requisitos


Conduct a Content Inventory

Se trata de realizar una lista de todo el contenido del sitio, que incluya todas las páginas, e indicar por cada contenido determinados datos: url, título, descripción, quién escribió la página, responsable de su actualización, etc.


Se puede organizar por categorías o por fechas, de manera que permita saber: en un portal nuevo, todo el contenido que es necesario desarrollar de una manera controlada y metódica; en la actualización de un portal nuevo, revisar qué contenidos faltan, sobran o deben ser revisados.


Perform Card Sorting

Descripción detalla de la técnica card sorting, técnica que permite construir la estructura del portal y etiquetar las categorías de forma que la organización del sitio sea lógica para los usuarios.


Define the Information Architecture

Da las claves para definir la navegación del sitio, de manera que refleje el propósito primario de la organización y ayude a los usuarios a encontrar rápidamente la información, por ejemplo recogiendo en la home lo más importante y las tareas más realizadas. Explica cómo crear un mapa del sitio y un wireframe.


Writing for the Web

Este es un punto fundamental que muchas veces se deja de lado: escribir para la web no es lo mismo que escribir para una publicación impresa, por ello necesitamos profesionales especialistas en la redacción para la web, que conozcan las particularidades de este medio. Asimismo es necesario reflexionar sobre el contenido que se incluye, ¿es relevante ese contenido para los usuarios, es lo que desean o necesitan? El usuario no quiere leer, quiere recabar información.


Use Parallel Design

Se propone preparar varios diseños de interfaz alternativos para que después el equipo los evalúe, compare y se puedan fusionar en un diseño final mejorado.


Develop a Prototype

Llega el momento de preparar el prototipo, bien de baja-fidelidad o de alta-fidelidad, que permita comprobar la usabilidad en una etapa temprana y poder realizar modificaciones a tiempo con el menor impacto en el proyecto.


Program the Site

Ya podemos llevar a cabo la maquetación y la programación de la aplicación. Hay que destacar que es en este punto donde se deben aplicar las pautas de accesibilidad de la WAI que aseguren un resultado accesible.




Test&Refine

Learn About Evaluations

Se explica la diferencia entre evaluaciones de usabilidad como la evaluación heurística, en la que no interviene los usuarios sino expertos en usabilidad y que predicen los problemas o éxitos que tendrán los usuarios con nuestra web, de los test o pruebas de usabilidad con usuarios que indicarán si las predicciones fueron válidas.


Se deben realizar en etapas tempranas del proyecto, desde el momento en que se tiene un prototipo.


Learn About Usability Testing

En este apartado se explica en profundidad qué es un test de usuarios.


Develop the Test Plan

Se desarrolla cómo preparar el plan de pruebas de usabilidad, en el que se ha de definir el número de participantes, el número de sesiones y su duración, etc.


Create Final Scenarios

Una vez establecido y aprobado el plan de pruebas, hay que preparar los escenarios, las tareas que los usuarios van a intentar realizar en el test de usuarios.


En este apartado se explica cómo crear un buen escenario, que se entienda sin dificultad, que podría ser por ejemplo ¿En qué edificio del Gobierno puedes encontrar el cuadro que pintó Bertrand Adams en 1937 denominado "Primeros Colonos de Dubuque"?, de manera que el usuario debe encontrar esa información en nuestro portal sin ninguna pista de cómo lograr la tarea.


Recruit Participants

Se explica qué tipo de usuarios deben participar en el test de usuarios y cómo preparar un cuestionarios para seleccionarlos, especialmente útil si se contrata para esta tarea los servicios de una empresa externa. Ejemplo de cuestionario.


Set Up for the Test Sessions

Antes de comenzar el test de usuarios, ¿qué revisar? Que el prototipo funciona, que los ordenadores van bien, que tenemos preparadas las autorizaciones mediante las cuales los participantes autorizan ser grabados, que las cámaras y micrófonos funcionan, etc. o incluso hacer una prueba piloto con uno de los usuarios.


Conduct the Usability Test

Da las claves para conducir un test de usuarios: cómo tratar a los participantes, cómo contestar a las preguntas permaneciendo neutral, cómo tomar las notas (ejemplo de notas), etc.


Analyze the Results

Detalla cómo analizar los resultados, tanto los datos cuantitativos que permitirán extraer datos estadísticos como los cualitativos, en los que habrá que buscar patrones y clasificarlos según su importancia y su carácter global o local.


Prepare the Usability Test Report

Explica como preparar el informe final del test de usuarios, en el que prive la concreción, los resultados y las recomendaciones (ver ejemplo de plantilla).


Implement and Retest

Llega el momento de aplicar las recomendaciones resultantes del test de usuarios y definir el número de iteraciones necesarias para asegurar que los usuarios logran las metas con eficacia.




Artículos relacionados
[07-03-08] Metodología DCU MPlu+a
[11-03-08] Wireframes
[15-11-07] Disciplinas relacionadas con la usabilidad