Utilizar Google para accesibilidad a archivos.

Google, el megabuscador, me ha dado una alegría tras leer muchos comentarios acerca de su pobre usabilidad y su falsa sencilleza.

Todos conocemos las búsquedas que google realiza sobre ciertos formatos de archivos: PDF, PPT, DOC ... Pero tal vez no todos nosotros, yo al menos no lo hacía hasta hoy, es aprovechar la presentación que hace Google para estos archivos.

Tras la búsqueda, Google nos avisa del formato del archivo, mostrándolo entre corchetes antes del titular de la entrada encontrada.
Yo, como todo buen usuario de módem de 56kb descarto a priori todos los documentos, por su tiempo de descarga, opto por abrir una página HTML normal y corriente, y usualmente más rápida que los demás archivos.

Pero hoy, por alguna extraña razón, me he acordado de ese fantástico link de Google : "Versión HTML" que nos muestra el archivo, en una versión HTML.

No estoy descubriendo América verdad?

Pero si recapacitamos acerca de ésta posibilidad que Google nos brinda, vemos que es un comportamiento accesible envidiable. El usuario no necesita tener el lector de archivos PDF, ni el de presentaciones PPT, ni ninguno de los programas necesarios para abrir un fichero de texto en su debido formato.
Incluso las personas que utilizen dispositivos móviles que carezcan del software apropiado pueden acceder al contenido de ese archivo sin mayor problema.

Esto es comportamiento accesible, al menos a mí me ha ayudado a acceder a archivos que de otra forma, quizás no hubiera accedido.
Ahora me puedo permitir el lujo de hacer búsqueda sólo sobre ciertos formatos de archivos gracias al comando de Google:

Sintaxis: filetype:[PDF|PPT|DOC|...] clave de búsqueda
Ejemplo: filetype:PDF accesibilidad en archivos

Además, Google nos facilita la búsqueda de nuestra palabra clave en documento, subrayándola para remarcarla, y ahorrándonos tener que aplicar criterios de búsqueda.

Desgraciadamente, la versión HTML que Google genera a partir de un archivo indexado no es 100% accesible. Contiene 6 errores según la verificación con Hera. Y no todos los archivos tienen su versión en HTML o están en caché, pero sí la mayoría.

Otra herramienta más dispuesta a ser utilizada por todos aquellos que solicitemos accesibilidad a nivel de ficheros.

Añadidos

Tras escribir este artículo me he interesado en verificar esta herramienta de accesibilidad en otros buscadores importantes. Estos son los resultados obtenidos.

Yahoo
Yahoo también proporciona la "Versión HTML" de los artículos con los mismos errores de Google, pero con 33 revisiones manuales frente a las 22 de Google.

MSN
MSN no proporciona versión HTML como tal sino como acceso a su caché (en HTML). No ofrece el marcado de la búsqueda como Google y Yahoo, y contiene 7 errores pese a validar las pautas de nivel 1.

Lycos
Lycos no proporciona versión de HTML para archivos.

Altavista
Altavista no proporciona la herramienta de versión en html ni opción de caché. En su lugar indican el formato del artículo y añaden un link de "Descarga Acrobat Reader".

AllTheWeb
AllTheWeb tampoco proporciona soporte HTML para ficheros.

Hotbot
Hotbot tampoco proporciona soporte HTML para ficheros.

Aquí veis la actitud de unos cuantos buscadores al mostrar los archivos que tienen indexados

Technorati Tags: google accesibilidad usabilidad archivos búsqueda

La Accesibilidad en Ingeniería del Software

En la actualidad, la gran mayoría de los Sistemas de Información de mediana y gran envergadura siguen un proceso de desarrollo por etapas conocido como Ingeniería del Software que cumple con varias normativas ISO para su estandarización:

· ISO/IEC FDIS 9126-1 (2000): Ingeniería de Software y Calidad de Producto

· ISO 13407 (1999): Procesos de diseño centrado en las personas para sistemas interactivos

· ISO TR 18529 (2000): Ergonomía de la interacción persona-sistema. Descripciones del proceso del ciclo de vida centrado en las personas

Lógicamente, todo esta Ingeniería es válida y usada en el desarrollo de Sistemas de Información basados en Web, que son los que especialmente me interesan, aunque se puede enfocar generalmente para cualquier Sistema de Información.

Estas etapas son (por orden cronológico): Especificación, Diseño e Implementación. Os daré una definición propia para cada una de ellas:

Especificación: Son el conjunto de técnicas y/o pautas que se siguen para determinar las funcionalidades y requisitos que el Sistema de Información va a tener, así como los diversos componentes que de él van a formar parte.

Diseño: Se modela la especificación y se crea un mapa conceptual de diseño con los componentes software que forman el proyecto, así como la interacción que seguirán entre ellos. Se establecen también los modos de comunicación, patrones y objetos para el desarrollo del sistema.

Implementación: Tras tener la visión clara y concisa que proporciona el diseño, basta con escoger una plataforma de desarrollo y un lenguaje de programación y codificar literalmente los diagramas de secuencia y operaciones obtenidas del diseño.

El ciclo de vida del software es algo más complejo que lo que aquí explico, cada etapa tiene sus metodologías muy clarificadas y bastante estandarizadas además de existir una realimentación de atrás hacía adelante para el mantenimiento y actualización del Sistema de Información.
Pues bien, ¿Dónde encontramos la Accesibilidad en todo este desarrollo?

De la experiencia que he ido adquiriendo a lo largo de estos últimos meses, podría casi afirmar que la Accesibilidad es parte de la implementación, allí donde se diseñan, gráficamente (no confundir con diseño conceptual) las interfaces de usuario.

Dicho de otra manera: Allí donde se programa usando XHTML y CSS o sea, en Implementación.

La cuestión es: ¿Se pueden aplicar los principios de Accesibilidad en las otras etapas?

A lo que yo mismo me respondo un enorme SÍ.


Posteriormente: ¿Por qué razónes no se aplican entonces?

* Falta de concienciación y conocimiento y/o experiencia en el tema.
* Por el mismo motivo que no siempre se aplica un desarrollo basado en esta metodología. Falta de tiempo, recursos y bagaje analítico.
* Por que los clientes tienen 10 razones por las que no invertir en accesibilidad.
* A saber…

¿Qué perfiles informáticos y en qué fases se podrían hacer cargo de la Accesibilidad?

- El especificador en la Especificación.

- El analista y el diseñador de bases de datos en Diseño.

- El programador y el diseñador gráfico en Implementación.

O sea, todas por las que pasa un sistema software en desarrollo, tienen la posibilidad de aplicar la Accesibilidad en su etapa correspondientes.

Pero no, de todos ellos, es únicamente los programadores y diseñadores gráficos sobre quién recae toda la carga, en cuanto a trabajo, que puede requerir un Sistema Software según las necesidades y los objetivos pactados entre cliente y especificador durante el análisis de requerimientos del sistema.

¿Se obtendría alguna mejora de aplicar los principios de accesibilidad en las diferentes etapas?


Lógicamente sí. Los implementadotes están formados para codificar un modelo estandarizado (p.e en UML- Unified Modeling Language) a su lenguaje de programación. Si el analista que ha modelado el sistema ya ha tenido en cuenta la accesibilidad durante su etapa, el programador solo se deberá a aplicar la accesibilidad a elementos muy propios de la programación, es decir, al código fuente. Ahorrándose así tener que desarrollar nuevos comportamientos y funcionalidades (por iniciativa propia) para obtener la accesibilidad en ciertos requisitos del sistema en los cuales el diseñador no la ha tenido en cuenta.

Pero es más, si a su vez el especificador hubiera especificado con la accesibilidad in mente, el diseñador no habría tenido que averiguar (por iniciativa propia) las funcionalidades que requieren de unos comportamientos diferentes, especiales, para su accesibilidad, o de unos requisitos exigidos por el cliente.

Ahorrándose esto, el diseñador se centrará más en temas de accesibilidad para los elementos básicos de su labor: los componentes del sistema y la interacción entre ellos.

El pez que se muerde la cola como veis.

Distribuir la accesibilidad entre todas las etapas haría que el proceso de “accesibilización” de una página se redujera a aplicar pocos principios en cada una de las etapas, pero el resultado final, sería en el peor de los casos el mismo que tal y como se desarrolla ahora.

Además evitaría el, “Uf, ahora hay que hacer esto accesible” cuando ya está en una versión beta, porque casi sin darse cuenta, todo el proceso se habrá hecho antes.

¿Cómo lograríamos que el especificador y el analista hicieran su labor integrando la accesibilidad como un requisito más del sistema?

Sólo hay una manera: Concienciación y Formación.

¿La teoría queda bastante clara verdad?

Si todos ponemos de lo nuestro, el proyecto sale mejor. Argumentación simple y sencilla.

Pero pongámonos ahora en la piel de cada profesional para ver qué puede aportar él, en su etapa, a la accesibilidad final del Sistema.

El Especificador

Tal vez la labor más primordial, ya no solo del especificador si no de todo el proyecto, es saber captar los requerimientos que el cliente nos solicita. El cliente es un usuario inexperto en informática (por eso requiere nuestro servicio), pero es muy experto en su sector, nos hablará de su visión de negocio, de las funcionalidades que necesita obtener del programa para agilizar el trabajo de sus empleados, de beneficios, gastos… Pero pocas veces se va a dar el caso que sea el cliente que nos diga: esta parte del Sistema necesito que sea accesible para tal motivo o para tal otro.

Pensemos en un ejemplo de requerimiento accesible que no tenga por que estar relacionado con disfunciones físicas o psíquicas de los usuarios. Algo mucho más simple.

El jefe se pasa la semana fuera de la empresa y todos los días quiere poder acceder desde su PDA a una herramienta de reporting que el sistema llevará integrada.

Si el especificador no entrevé un posible problema de accesibilidad en este aspecto, no tomará nota de esto, y todo el posterior proceso de reporting se hará sin tener en cuenta este aspecto.

Este aspecto concierne al Analisi de Requerimientos que realiza el especificador. Veamos otro caso relacionado con otra sub-etapa de la Especificación.

En la empresa hay una persona discapacitada motriz que lleva 30 años trabajando allí y es de muchísimo valor para la empresa dada su experiencia. Esta persona es la encargada de actualizar diariamente las previsiones de ventas para los próximos días. La discapacidad del trabajador impide a este el uso del teclado cómodamente (lo usa con mucha dificultad).

El cálculo de previsiones es un proceso crítico en la empresa, y tras cada operación se requiere una verificación y aceptación de la misma por parte del usuario. El sistema lanza un mensaje tras cada paso pidiendo confirmación.

Pero el usuario discapacitado dada su experiencia, no requiere de una confirmación para saber si está haciendo bien la actualización o no. Ya que por simples cálculos a partir de datos históricos conoce el resultado de dicha actualización de antemano.

Bien, el especificador al no percatarse de que hay un usuario, un “actor del sistema” que requiere un comportamiento “especial” al de los demás usuarios en ese Caso de Uso, está causando que el discapacitado tenga que sobre-esforzarse de manera totalmente innecesaria para llevar a cabo su labor.

En este ejemplo aparte de problemas de accesibilidad los hay también de usabilidad, pero vale para ver que en la sub-tarea de definición de Casos de Uso, el especificador puede considerar actores del sistema que no tienen porque seguir el mismo comportamiento que los demás.


El Diseñador

Hemos comentado que el diseñador (conceptual) es el profesional que se encarga de abstraer las necesidades del cliente un nivel por encima, de tal manera que se pueda modelar el concepto en un componente software, entiéndase: objetos y/o funciones. Al final de su etapa el diseñador conceptual hace unos esquemas del diseño gráfico de la aplicación con el fin de indicar los campos y datos que necesita para la ejecución de sus funciones.

Tal vez si el especificador no hubiera documentado nada acerca del Caso de uso “especial” para el empleado discapacitado, el diseñador no habría tenido en cuenta los posibles objetos y funciones que fueran necesarios para desarrollar ese comportamiento diferenciado del de los demás usuarios. Pero esto es un ejemplo acarreado por un fallo del especificador.

Veamos que aspectos debe controlar el diseñador en su etapa por una mejor accesibilidad y/o usabilidad.

La empresa ya tenía un sistema de indicadores de stock de una versión antigua, a la que los empleados estaban muy acostumbrados tras 10 años de trabajo sobre él. En el nuevo diseño se ha modificado la estructura del formulario, se han cambiado colores, incluso antes era en modo texto y ahora es con ventanas mil colores y formas diferentes. Cuando presentemos esto al usuario, éste se sentirá confuso y habremos provocado un riesgo funcional (riesgo provocado por un funcionamiento no habitual o intuitivo de un sistema) que incluso puede llegar a provocar el rechazo del usuario a la nueva aplicación.

El programador

Todos sabemos el ámbito de trabajo de este profesional basándose en la codificación y el diseño grafico para proporcionar un front-end amigable, usable y accesible. Así que no hablaremos de él porque la asociación que existe entre accesibilidad y diseño gráfico o programación la conocemos todos y el objetivo era demostrar que se puede hacer un seguimiento de la accesibilidad durante todas las etapas de la Ingeniería del Software.


Esperemos pues, que en un futuro no muy lejano, la accesibilidad se extienda a toda la Ingeniería del Software para una mejora incremental durante el desarrollo de los Sistemas Software del mañana.

Tech Tags: Accesibilidad Usabilidad Ingeniería Sofware Diseño Código

Nuevo colaborador y nueva sección

Me enorgullece poderos presentar a un nuevo colaborador de Accesibilidad Web.

Su alias es posavasos y me sorprendió de él su capacidad para recolectar información de mucho, mucho interés, por este motivo propuse establecer una colaboración en este blog y el accedió amablemente.

Como podeis ver, se ha añadido una nueva sección a la bitácora, concretamente se trata de un LinkBlog. Una herramienta de recolección de artículos y/o notícias de otras muchas fuentes de información que se relacionan con el contenido de éste blog, en concreto con la accesibilidad.

Pues bien, de ésta sección, y en el futuro espero que de alguna más, se encargará posavasos gracias a esa capacidad innata de recolectar fuentes y artículos de importante contenido como venía haciendo en su del.icio.us.

He escogido este formato de presentación mediante enlaces para no tener que usar un post para cada uno de los posibles enlaces que se vayan recopilando.

Espero que esta nueva sección y este nuevo colaborador os nutran de información relevante en cuanto a accesibilidad se refiere.

Consorcio de Herramientas para Accesibilidad

Vía Access Matters me entero de esta genial iniciativa.

Se ha creado un Consorcio para el desarrollo de Herramientas para Accesibilidad con muchas aplicaciones desarrolladas y otras planeadas.

Un buen empujón tecnológico para la accesibilidad sin duda alguna.

Entrevistas Accesibles: Alejandro de Webposible en el blog de Daniel Garcia

Leo en el Blog de Daniel García una excelente entrevista a Alejandro Gonzalo de Blog Posible.

Toda una experiencia en cuanto a accesibilidad se refiere. No os la perdais!

Cosas de la vida...

Parece mentira, pero a veces la vida tiene estas cosas... Sorprendentemente, almenos para mí, me han realizado una entrevista sobre accesibilidad, cuando hace nada era yo el que las hacía.

Podeis ver que no miento en la página de Daniel, quien aprovechando la entrevista intentó animar y conscienciar a los webmasters Chilenos sobre la importancia de la accesibilidad, tras acudir a una charla-seminario con escasa afluencia de oyentes.

Aquí os dejo la página de este nuevo gran amigo Daniel y el enlace a la entrevista.

Espero que os guste y agraceder desde aquí a Daniel y su interés por la accesibilidad y la motivación que esto y todo lo que se pueda hacer pueda aportar a todos los webmasters del mundo.

Saludos!

Foro Accesibilidad

Foro Accesibilidad nace con la intención de crear un lugar de encuentro colectivo de interesedos y entendidos del principio de accesibilidad en el diseño de aplicaciones informáticas.

La idea surge tras visitrar foros de habla inglesa sobre el mismo tema, y tras observar que no existe ninguno con este tópico para habla española.

Esperamos así que este foro crezca como punto de discussión sobre temáticas relacionadas con la accesibilidad.

Un saludo enorme a todos y muchas gracias por vuestra atención.

Página del Foro
(http://foroaccesibilid.7.forumer.com)

Haciendo una bitácora Accesible

Navegando por los links, sin siquiera recordar la fuente que me llevó hasta él, descubro a Carlos Egea y su blog personal Haciendo una bitácora Accesible
En su bitácora Carlos nos explica paso a paso como crear un blog accesible usando un CMS (Content Management System) como blogger.
Todo un manual imprescindible para todos aquellos que, aún siendo una simple bitácora, deseemos adaptarnos a los estándares sobre accesibilidad, facilitando así el uso de nuestro contenido a todos.

Un saludo enorme para Carlos y muchos ánimos a seguir con el proyecto que ha iniciado.

Mostrando el Feed de una manera Accesible y Usable

Los Feeds de RSS se están convirtiendo en herramientas indispensables en toda web. Con ellos se difunde la información de una manera directa hacia el usuario, sin obligar a que este tenga que visitar nuestra página obligatoriamente para observar los cambios.

Planteándome el tema de los Feeds con Mario nos dimos cuenta que exponer directamente el link al RSS puede resultar algo peligroso.

Nos ponemos en el caso de usuarios inexpertos o con alguna disfunción física o psíquica que por curiosidad entraran al típico link de RSS y observaran ese cúmulo de carácteres especiales entremezclados con carácteres de texto, con mas bien poca estructura (al menos conocida). El usuario inexperto no comprende lo que ha sucedido, se ha podido cargar mal la página, se trata de un error o una broma? El usuario se siente confuso y puede tomar las decisiones típicas de este tipo de usuarios...
Una persona con disfunciones visuales puede ser bombardeado con una locución incoherente de símbolos y letras sin significado aparente alguno, otro usuario confuso.

Para evitar estas situaciones creamos una solúcion fácil y útil, al alcance de cualquiera y a la que se le pueden añadir más funcionalidades.

La idea es crear una página intermedia entre nuestro blog y el propio fichero XML. Dicha página nos podría servir para incluir una breve aclaración sobre "que es un Feed RSS" y un link al archivo XML que lo contiene.
Así el usuario inexperto no entrará de repente en una página que no sigue un formato Web estándard, ahorradose así la confusión, y además encontrará una explicación sobre dónde está y que puede encontrar ahí.

Los usuarios que sabían lo que buscaban y querían acceder directamente al link del Feed, lo seguirán teniendo, aunque sea en una segunda capa.
Lo que no encontramos lógico fue el hecho de tratar el link al Feed RSS como un enlace cualquiera a otra parte de la web o a una externa, que sería el comportamiento que cabe esperar en cualquier enlace en Internet, independientemente de nuestra experiencia en el medio.

Una vez creada la página intermedia, podríamos aprovechar para poner en ella todo lo relativo a Feeds RSS. Unos buenos elementos a añadir en esta página serían las imágenes-enlaces a agregadores de Feeds como Bloglines, FeedReader, MyMSN, MyYahoo, NewsGator...
Envez de mostrarlas en la página principal de una manera un tanto incoherente, podemos aprovechar esta página dedicada al Feed RSS para proporcionar estos enlaces de manera acorde con el contenido del marco donde se encuentran.

Como veis, una solución fácil, usable y accesible que puede facilitar las cosas a mucha gente y sigue el marco semántico de toda la web.

He creado la página del Feed de Accesibilidad Web como ejemplo.

Tech Tags: Feeds XML RSS accesibilidad Usabilidad

Haciendo CRM para la Web

Las iniciales CRM se leen aquí y allí en todo el ámbito empresarial global, el término completo es Client Relashionship Management, literalmente algo así como Gestión de la Relación con el Cliente.

Qué filosofía hay tras un concepto tan útopico?
No se trata de llevarse a cenar al cliente y atiborrarlo de buen vino y buenos licores para aumentar así su sensación de bienestar y confianza en nuestra empresa. Es algo más complejo cuya misión és determinar con exactitud el Grado de Satisfacción del Cliente, que aquí llamaré GSC.(Hoy me da por iniciales mira...)

Y bien, Qué hacemos ahora con el GSC ?
Sabemos el estado del cliente respecto a nuestra empresa, sabemos que se enfadó y mucho tras atrasarnos en la entrega de su último pedido, sabemos que con muchas posibilidades ese fuera su último pedido a nuestra empresa si no se toman medidas urgentes.
Se puede "mimar" al cliente con suculentas recompensaciones, mayormente económicas, que calmen sus ánimos y vuelvan a mejorar su GSC. A nadie interesa hoy en dia tener un cliente enfadado.

A que viene esta aclaración económico-financiera aquí?
La web no deja de ser otro mercado económico más, aquí cada uno vendemos nuestros productos, unos venden componentes electrónicos, otros golosinas, hasta los hay que venden (me han dicho que hasta gratis) cosas etéreas como: conocimiento, experiencias, vivencias y todas las "-encias" que la vida nos pueda deparar.
Demostrado queda que este blog es una tienda más en este enorme centro comercial llamado Internet.
Pensemos pues como empresa, a toda empresa le gusta vender más, y para vender más los clientes tienen que comprar más y para que un cliente compre mas habrá que tener su GSC lo más alto posible.
El concepto del Grado de Satisfacción en Internet es algo más sutil que en el mundo empresarial, pero la idea es la misma, es proporcionarle al usuario lo que él nos pida y de la manera que él nos lo pida, así y solo así, el usuario se sentirá como en su casa.
Las empresas se bastan de múltiples variables para sus estudios de Grados de Satisfacción, historiales de ventas, entrevistas y encuestas a consumidores, comportamiento de los rivales... y un sinfín de números mediante técnicas extractivas como la Minería de Datos, ayudan a los directivos a conocer el estado de sus clientes.
En la web parece no existir ese afán de lograr la satisfacción de los clientes, exceptuando tiendas on-line claro, pero esta afirmación no es del todo cierta, a todos nos agrada enterarnos que hemos fidelizado un cliente, un internauta en nuestro caso, a nuestra web.

Veamos ahora unos cuantos medios que nos podrían ayudar a la hora de extracción de conclusiones.

Las estadísticas Web.

Todos conocemos este fantástico espejo de nuestra web,¿ pero realmente lo aprovechamos al máximo?
Está bien tener un contador con varios millones de visitas, y que cada día engorda otros miles de vistas más, pero no es suficiente. Hay multitud de sitios web que proporcionan contadores de visitas con estadisticas, sino también hay cientos de scripts en todos los lenguajes de programación habidos y por haber que realizan esta labor.
Nos desnudan la interacción del usuario en su visita a nuestra web con datos como:

Páginas Visitadas: Cuantas páginas nuestas ha visitado cada usuario y cuales han sido, un excelente dato para conocer los sitios más interesantes de nuestra web y los contenidos más comunmente visitados por los usuarios. Podremos enfatizar esas partes distingidas de nuestra web para añadirle aún más importancia y derivarlas en otro punto de entrada secundario a nuestro sitio, como un segundo Inicio (índex o "home").

Tiempo de la Visita: Muestra los minutos que ha estado el usuario conectado a nuestra web o incluso a cada una de las webs que ha visitado. Este dato nos ayudará a conocer las páginas más destacadas que he comentado en el punto anterior.

Ruta seguida: El contador de estadísticas nos indica los saltos que ha ido dando el usuario en su recorrido por nuestra web, podemos observar así que relación hay entre los saltos y los links que hay en cada página de la que provenía el usuario. Sabremos así si el link está bien colocado en ese lugar, si lleva al usuario a dónde lo queriamos llevar, o lo desvía por otra rama de nuestra web hasta perder su interés inicial.

Páginas de mayor entrada y salida: Nos indica las páginas que suelen ser más visitadas como punto de entrada a nuestra web y cuales son las páginas más comunes a partir de las que el usuario abandona nuestro sitio. Complementar las páginas de entrada más comunes ampliará el abanico de posibilidades del usuario en nuestra web, mientras que mejorar las páginas de mayor salida evitará agotar al atención del usuario y provocar que abandone la web.

Visitas externas: Reconocemos así qué usuarios nos llegan redireccionados desde otras páginas ajenas a las nuestras o desde motores de búsqueda.
Analizando las páginas de origen de los visitantes sabremos mucho sobre ellos, sabremos sus intereses nada más y nada menos. Incluso podemos llegar a saber el nivel de estos usuarios. Conocer bien a nuestros usuario es fundamental para conocer lo que buscan y lo que les interesa para poderselo servir a su agrado.
De las visitas provenientes de buscadores extraemos las claves de búsqueda, esas pequeñas joyas que nos permiten saber "de qué" se conoce nuestra web en internet, buscar esas claves en nuestra web nos ayudará a entender "qué" buscan los motores, y para el futuro, tendremos ese "qué" en cuenta a la hora de "cómo" aportar nuestra información haciéndola visible a buscadores y/o usuarios. (Casi que nada...)


Las estadísticas Web sea quizás el método más conocido y usado para analizar a nuestros visitantes, pero no és el único.

El Feedback
Un simple formulario como el que teneis a la derecha bastará para que el usuario haga sus quejas formales tras visitar nuestra web. Puede usarlo como medio de queja o como medio de agradecimiento o felicitación. En ambos casos deberemos leer detalladamente lo que el visitante nos explica de su experiencia a través de nuestro sitio para poder realimentar, de ahí la palabra, todo el sistema potenciando esas alabanzas o mejorando esas críticas.

Encuestas
La típica encuesta de "Qué te parece el sitio: Bueno Normal Nefasto" es muy básica, aunque nos puede dar un enfoque global correcto. Una vez trabajemos bajo la suposición que nuestro sitio no es nefasto, podemos dedicarnos a hacer una encuestas más concretas que nos permitan intuir mejor el Grado de Satisfacción de nuestros visitantes.

El Log de errores
Pese a parecer una estupidez creo que es uno de los puntos más a tener en cuenta. El usuario abandonará casi que con un 1oo% de probabilidades nuestra página tras un link roto o mal escrito. El Log de errores nos informa de estos links caídos y apresurarnos a repararlos evitará otras pérdidas. Tambien cabe la posibilidad que utilizan algunas web, especialmente de descargas de , "Notificar de Enlace Roto", pero eso sólo valdrá si el usuario está realmente interesado en ese enlace y en vez de abandonar nuestra web haya vuelto atrás para notificarnos el error.

Los Comentarios y mails al Webmaster
En algunas páginas, los blogs por excelencia, el usuario puede comentar artículos o contenidos posteados por el autor. Muchas veces, en estos comentarios se hacen críticas al respecto de la información, la escritura o muchos otros factores que hayan desagradado al usuario.
Otra opción es no negligir los mails que se reciben como Webmaster, muchas veces no son de nuestro agrado, dada la facilidad de mala palabra que tiene mucha gente, pero incluso hay personas que puede hacen críticas constructivas que nos ayuden a mejorar nuestro sitio y la relación del cliente con éste.


Tenemos entonces todos los datos disponibles para conocer la experiencia del usuario en nuestra web, sólo nos falta analizarlos conscienzudamente y adaptar nuestro sitio a los requerimientos sugeridos, completarlo con las ausencias detectadas y enfatizar los puntos destacados del mismo. Todo con el fin de que el usuario aumente su Grado de Satisfacción (usando el concepto empresarial) para que vuelva, aunque no sea para comprar :).

Technorati Tags: estadísticas web usuarios experiencia accesibilidad visitas