Página Inicial de WebUsable

Página anterior Página Inicial de WebUsable Disminuir tamaño de letra Aumentar tamaño de letra Mapa de WebUsable Envía tus comentarios
 


 Usabilidad del Servidor Web

En la Web podemos encontrar cientos de artículos sobre consideraciones de todo tipo acerca de como mejorar la experiencia de usuario durante su discurrir en un sitio Web.

En ellos se analizan lo que es correcto y lo que no en el tratamiento de cada uno de los elementos que pueden componer un interfaz de usuario en Intenet (Menús, Barras de Navegación, Formularios...), hasta las problemáticas específicas por tipología de Web site (Comercio Electrónico, Foros, Sistemas Transaccionales...)

Sin embargo, para la mayoría de los consultores de usabilidad el Web Server es una caja negra que entrega páginas a petición, y en la que suceden una serie de procesos que nada tienen que ver con la experiencia de suario en sí.

Esto es así debido fundamentalmente a dos razones:

  • El escaso perfil técnico que suelen tener la mayoría de consultores de Usabilidad.

  • El marcado cariz empírico que la Usabilidad ha tenido desde sus comienzos: un sitio Web se testea por un experto en base a unos heurísticos y "checklists", y con usuarios-testers, y se sacan conclusionmes de qué no está funcionando. Las consideraciones técnicas del proceso no importan.

Y, sin embargo, hay aspectos de configuración y funcionamiento del Servidor Web que van a afectar directamente a la esperiencia del usuario en cualquier sitio de Internet.

  1. El prefijo "www" debe ser opcional:

    Al teclear la URL de un sitio Web los datos verdaderamente identificativos del mismo son:

    • El Nombre de Dominio
    • La Extensión de Dominio

    Las "www" de cara a la identificación del site son ruído y no aportan valor. De hecho, está muy generalizado en Internet que los usuarios con experiencia sólo tecleen en la URL del navegador el Nombre y la Extensión de Dominio y se les lleve a la Home Page del sitio en cuestión.

    Si en lugar de esto se les devuelve una página de "página no encontrada" suelen sentirse verdaderamente contrariados.

    • Se debe configurar el Web Server para que siempre resuelva www.sitio.ext independientemente de que se teclee:

      • www.sitio.ext
      • sitio.ext

  2. Inicio de página



  3. Preveer errores en el número de "www":

    Precisamente por lo irrelevante de las "www" los usuarios suelen teclearlas muy rápido y sin prestar demasiada atención, para cumplir de la forma más rápida con el molesto trámite. Por esta razón es relativamente frecuente que tecleen:

    • ww.sitio.ext
    • wwww.sitio.ext

    • Se debe configurar el Web Server para que siempre resuelva www.sitio.ext independientemente de que se teclee:

      • ww.sitio.ext
      • wwww.sitio.ext
      • w.sitio.ext

  4. Inicio de página



  5. Soportar variaciones, abreviaciones y errores de escritura del nombre de dominio.

    Dependiendo del idioma y la complejidad del nombre de dominio (sobre todo cuando está formado de varias palabras), pueden darse con bastante frecuencia errores de escritura de la URL de diferenctes tipos. Pongamos por caso "Barnes and Noble". Cuando un usuario escucha el nombrde del site "Barns an Nobel dot (punto) com", puede escribir la URL de diferentes maneras:

    • www.barnesandnoble.com
    • www.barnes&noble.com
    • www.barnes-noble.com
    • www.barnes_noble.com
    • www.barnesandnobel.com
    • ...

    Por descontado que si lo ha visto escrito se reducen las probabilidades de error pero, por experiencia, se sabe que aún así, los errores de deletreo de URL's son frecuentes.

    Incluso, la picaresca tan frecuente en internet. ha hecho florecer empresas que se dedican a registrar variantes de marcas conocidas, recogiendo así un gran número de visitas ajenas a las que inducir a negocios de todo tipo.

    De otra parte, cuando un usuario hace varios intentos de escribir la URL de un site y recibe sistemáticamente errores de existencia, llega a desesperarse y, con frecuencia abandona el intento.

    Por estas razones es importante registrar no sólo el nombre de dominio oficial de la empresa, sino también posibles variantes e, incluso el(los) nombres errados más comunes. Ni que decir tiene que todos ellos deben redireccionar a la misma página corporativa para evitar crear confusión al usuario y preservar la imágen corporativa de la empresa.

    Finalmente, para el caso de nombres compuestos, es muy recomendable registrar también la abreviatura más lógica, e incluso, ofrecerla como nombre de dominio por defecto. En el ejemplo que nos ocupa, Branes and Noble recibe un gran número de visitas através de la URL:

    www.bn.com
  6. Inicio de página



  7. Soportar varias extensiones de dominio:

    En países como Alemania, la mayoría de sitios tienen extensión de dominio "de", por lo que la mayoría de la gente tiene tendencia a terminar las URL's con un .de, casi de forma automática.

    En estas circunstancias crear un sitio de ámbito sólo nacional con extensión "com" es garantizarse un buen número de intentos de acceso fallidos a la URL por culpa de la extensión de dominio.

    En España, por el contrario, ante la dificultad de obtener dominios conn extensión "es" de un lado, y por esnobismo, por otro, la tendencia del usuario corriente es a pensar que cualquier dominio tiene extensión ".com" lo que complica el problema, ya que el "estándar" es en cierto sentido impropio.

    Y al usuario poco experimentado se le complica la cosa cuando hay que manejar ".net", ".org". Y ni que decir tiene con las nuevas extensiones ".biz", ".info"...

    Finalmente, y de nuevo por la picaresca en Internet, se trata de proteger el "Branding" de la marca, ya que, para marcas de relevancia, siempre aparecerán empresas que traten de registrar la marca con extensiones de países en los que no esté registrada.

    En consecuencia, es recomendable:

    • Utilizar siempre en primer lugar la extensión de dominio del país originario del sitio.
    • Si la empresa es de ámbito internacional, utilizar extensión ".com" para la página de ámbito iternacional, normalmente en inglés, y desde la que se ofrecen entradas a las de otros idiomas.
    • Si la empresa es de ámbito internacional, registrarla con todas las extensiones de dominio de país que sean posibles, sobre todo si hay riesgo de que otros lo hagan. Y como mínimo con las extensiones de los países en los que tenga presencia real, o a cuyos idiomas esté traducido.
    • Registar si es posible el dominio con extensiones de tipo de actividad (".org", ".net", ".biz", ".tv", ".info"...) pero sólo si es consistente con la actividad del site.
  8. Inicio de página



  9. Evitar URL's complejas:

    Si alguien quiere entrar en la sección de "autos" de Yahoo debe teclear:

    • http://autos.yahoo.com/

      Es decir, utilizan un dominio virtual para la sección = "autos" lo que facilita mucho al usuario cuando en el futuro quiera volver a acceder a esta sección. En vez de esta solución podrían haberse garantizado usabilidad adoptando "nombres nemotécnicos de carpetas físicas de contenidos", utilizando por ejemplo:

    • http://www.yahoo.com/autos
    • Dentro de "autos", Yahoo tiene dos categorías fundamentales, lógicas para los usuarios interesados en este tama, "nuevos" y "usados". Si un usuario está interesado en un "coche usado" y pulsa el enlace correspondiente, obtendrá una página de URL:.

    • http://used-cars.autos.yahoo.com/used_cars.html;_ylt=AujNRRy917n87D2psHnQLhwEc78F

      Obviamente, imposible de recordar si en el futuro tratara de acceder directamente a esta subsección. Estaría obligado a recorrer toda la secuencia de navegación si qjuisiera llegar a "coches usados".

    • Hubieran facilitado mucho las cosas a los usuarios si les hubieran provisto de la siguiente URL de acceso:

    • http://autos.yahoo.com/usados

    • Utilizar siempre URL's sencillas para secciones y subsecciones del site:

      • Utilizando Dominios Virtuales para secciones de primer nivel.
      • Utilizando nombres nemotécnicos de carpetas físicas de contenidos para secciones de segundo y tercer nivel.
      • Utilizando Alias que redireccionen a la URL concreta en el caso de generarse esta dinámicamente.

  10. Inicio de página



  11. Humanizar al usuario la "boca del lobo" de "Error 404 Página no encontrada (Page not found)":

    La frustración que el usuario normal sufre cuando fracasa en la petición de una página y se le devuelve "Error 404 Página no encontrada". o similares mensajes propios del Web Server es grande. Cuando además son en inglés e implican códigos de error u otras características técnicas del fallo la sensación es además de "entorno inhóspito", lo más alejado del concepto de HCI (Human-Computer Interaction).

    • Ayudar al usuario a moverse desde el "vacío" en que se encuentra al fallar en una petición:

      • Presentándole un interfaz visual amigable y en su idioma (el del site).
      • Explicando brevemente en lenguaje llano las posibles causas de la no-presentación de la página solicitada.
      • Proporcionandole la URL de la Home Page del sitio. El logo del mismo suele aportar una sensación de familiaridad.
      • Presentándole el mapa del site para que pueda moverse entre enlaces "correctos" a páginas existentes.
      • Presentándole el Menú de Navegación del sitio Web.
      • Ofreciéndole posibilidades de búsqueda en el site.
      • Sacándole de la Página de Error después de un breve lapso de tiempo, mediante:

        <meta http-equiv = "refresh" content = "90; url = http://www.sitio.com">

    • Buscando referencias en el site a páginas ya obsoletas o inexistentes. Existen herramientas "ad hoc" que permiten detectar los Enlaces Rotos entre todas las páginas del Web Server.

  12. Inicio de página



  13. Preveer errores de servidor. Página de "Web Server Error":

    El Web Server puede dar errores debido a diferentes circunstancias. Habida cuenta que al usuario no le interesan explicaciones técnicas de que está pasando en nuestro Servidor Web, porqué sucede y cual es la solución técnica a los problemas, y todo esto para cada uno de los posibles errores de Web Server que pueden ocurrir:

    • Diseñar y presentar al usuario una única página de "Web Server Error":

      • Examinar el Log del Web Server para ver los errores que da. Los códigos de respuesta empezarán por "5" (500, 501, 502...).

      • Diseñar una única página de "Error de Servidor Web", similar a la de "Error 404 Página no encontrada", dónde se explique al usuario escuetamente que hay un error en el servidor (sin entrar en consideraciones técnicas). Amablemente invitarle a visitar el sitio con posterioridad, cuando los problemas se hayan solucionado.

      • Redireccionar las páginas de respuesta correspondientes a los códigos de respuesta de "Web Server Error" a la página de usuario de "Error de Servidor Web".

  14. Inicio de página



  15. Disponer de una "Página de Mantenimiento":

    Durante la vida de un sitio Web habrá circunstancias que obliguen a parar el servicio, no por fallos técnicos, sino debido a diversas circunstancias:

    • Modificaciones costosas del sistema de navegación.
    • Cambios en el sistema de publicación dinámica.
    • Nuevas versiones del diseño gráfico de la imágen del site..
    • Cambios de versiones de Sistema Operativo o software de base del servidor.
    • Cambios de configuración del Web Server...

    • Diseñar y presentar al usuario una única "Página de Mantenimiento".

      • Como deberá ser utilizada para cubrir diversas circunstancias, sencillamente explicar que se están haciendo cambios para mejorar el servicio prestado por el site. Invitar amablemente al usuario a visitar el sitio con posterioridad, cuando los trabajos de mantenimiento hayan finalizado.

      • Sustituir provisionalmente la Home Page del site por esta "Página de Mantenimiento".

      • Habida cuenta que podremos tener entradas por otras páginas que no son la Home Page, consigurar el Web Server para que dicha página sea la única entregada, sea cual sea la petición..

  16. Inicio de página



  17. Habilitar un Robot de Respuesta a E-mails:

    Una de las cosas que más .molesta a un usuario es invitarle a enviar una duda o sugerencia a través del e-mail del sitio Web, y no ser respondido. Y más con el abuso que en la actualidad se hace de las direcciones de correo electrónicas obtenidas.

    Pero aún cuando tengamos habilitado un procedimiento de respuesta a correos electrónicos, hay muchas probabilidades de que hasta que podamos.atender el de un usuario concreto hayan pasado un buen número de horas, e inclu días. Y esto en un medio dónde los usuarios cada vez más están acostumbrados a una respuesta inmediata.

    • Siempre es recomendable disponer de un Robot de Respuesta Atomática a E-mails: tranquiliza recibir "feedback" aunque sólo sea en forma de acuse de recibo.

      • La respuesta estándar a un correo recibido debe ser clara y no hace falta dar muchas explicaciones. Se trata de comunicarle al usuario que se ha recibido su correo en el sitio al que él creía haberlo mandado, que va a tener respuesta personal, y que esto se va a producir en un breve plazo de tiempo.

      • Existe controversia sobre si en esta respuesta automática especificar que le está respondiendo un robot (programa). En realidad no hace falta, aunque algunos avogan por la transparencia a ultranza.

      • De comprometernos con el usuario a que tendrá respuesta personal futura, hay que cumplirlo. De lo contrario es preferible no comprometerse.

      • Existen respuestas automáticas muy útiles en las que se describen qué pasos se van a dar a raíz de una acción realizada por un usuario, como por ejemplo en el caso dela realización de una compra electrónica.

        Evidentemente, no es lo mismo responderle al usuario:

        • ¡Acaba de realizar una compra electrónica.en nuestra tienda! Su pedido será atendido a la mayor brevedad.

        • Que describirle esquemáticamente la secuencia de acciones que sucederán a continuación:

        • ¡Acaba de realizar una compra electrónica.en nuestra tienda!
        • El tiempo estimado para proceder a su envío es de 9 días.
        • En el momento que hayamos proceddido al envío se lo comunicaremos por e-mail (también respuesta automática).
        • Como usted ha elegido forma de envío "Correo Ordinario", a partir de que realicemos el envío y usted tenga confirmación por correo electrónico, debería recibirlo en un máximo de 5 días.
        • De no recibir la entrega en este plazo de tiempo, el responsable de posibles retrasos sería Correos. No obstante le agradeceríamos nos lo comunicara por correo electrónico a fín de que investiguemos las posibles causas.

  18. Inicio de página



  19. Analizar periódicamente la Integridad referencial de la arquitectura de contenidos.

    Analizar periódicamente la estructura de páginas del servidor en búsqueda de enlaces rotos es una tarea que normalmente no se realiza y que en la mayoría de sites produciría desagradables sorpresas.

    Porque, con el fín de facilitarle al usuario la navegación y la disponibilidad de vías de acceso o herramientas, en el diseño e implementación de sitios Web casi siempre se termina por construir una telaraña de hiperenlaces más extensa y compleja de lo que generalmente somos conscientes:

    • Menú de Navegación de Contenidos.
    • Barras de Herramientas.
    • Barra de Idiomas.
    • Iconos de Desplazamiento (Top of Page, Back, Home Page...)
    • Iconos de Utilidades (Imprimir, Enviar Correo, Añadir a Favoritos...)
    • Hiperenlaces de referencias internas de contexto.
    • Hiperenlaces de referencias externas de contexto.
    • Sección de Enlaces Recomendados.
    • Banners de sitios anunciados o amigos.
    • Thumbnails...

    Esta complejidad hace que, con el transcurso del tiempo y el crecimiento de la estructura de contenidos, crezcan progresivamente el número de enlaces rotos sin que seamos conscientes de ello.

    • Es muy recomendable disponer de un Analizador de Enlaces Rotos:

      • Son herramientas sencillas y baratas pero su uso periódico puede ayuda a garantizar en gran medida la integridad referencial del site.
      • Evita la incomodidad y frustración a los usuarios por contenido inexiastente.
      • Ayuda a evitar la mala imágen de "Página No Encontrada".
    • Hay diferentes tipos de analizadores:

      • Analizadores: residentes en el Web Server, discrecionales o desatendidos.
      • Analizadores: residentes en Cliente.
      • Servicios externos on-line.

    • Normalmente todos funcionan de forma similar: a partir de una página inicial van analizando todos los hiperenlaces, creando la correspondiente estructura de árbol que refleja la arquitectura de contenidos, y detectando la existencia de la página a la que se apunta.

      Cuando una página referenciada no existe se identifrica el hiperenlace como roto y se refleja como una entrada en un Log de Incidencias.

    • Algunos de estos Analizadores de Enlaces Rotos son:

    • Analizando el URL Referer ver si las peticiones de páginas obsoletas provienen de Web Servers externos. En este caso contactar con el webmaster correspondiente para eliminar o actualizar el enlace.

    • Redireccionar páginas inexistentes u obsoletas en el Web Server a una de "Ayuda a la Navegación" o a la Home Page del site. (Esto puede ser más cónodo si una página está siendo direccionada desde varios buscadores).

 
 
WebUsable.com © Todos los derechos reservados.
Subir al inicio de página Página anterior Página Inicial de WebUsable Imprimir esta página Envía tus comentarios Recomienda esta página a un amigo Mapa de WebUsable