Innovación y experiencia de usuario

Usability is often viewed as being inherently risk-averse, and even at odds with innovative ideas. The usability practitioner seeks to meet users’ expectations – or “mental models” – eliminate surprises rather than capitalize on them, and follow standards that provide consistency with outside interfaces. User experience designers employ design patterns that have been proven over time, and utilize prototyping tools that encourage the use of established pattern libraries. User testing also tends to focus on the first use, making it very difficult for seemingly innovative ideas to beat out the familiar and immediately recognizable user interfaces that employ well known design techniques.
[…]
Whether UX practitioners care to admit it, many of these claims are true. UX professionals don’t tend to be the greatest advocates of innovation, and our designs are often limited to what others are doing and the depth of our pattern libraries. These are the side-effects of lazy design, however, and not the nature of User Experience. User Experience designers have a unique opportunity to become the facilitators of holistic design and the advocates of innovation. By combining traditional user-centered activities with a greater emphasis on creating engaging designs we can bring usability into alignment with innovation in the design process. Here are some thoughts on how […]

Where Innovation Belongs in User-Centered Design by Jake Truemper

He llegado al artículo gracias a un twitt de César García Gascón y de forma primitiva, rondaba por mi cabeza desde hace tiempo…

Quitar elementos ante un problema

Una de las cosas que la gente tiene la tentación de hacer cuando hay un problema de usabilidad es añadir algo. Si alguien no ha entendido las instrucciones, añada más instrucciones. Si alguien no ha podido encontrar lo que estaba buscando en el texto, añada más texto. Si alguien no se ha dado cuenta de algo que necesitaba, añádale más color, póngalo en negrita, o más grande.

Pero muy a menudo la mejor forma de solucionar un problema de usabilidad es hacer justo lo contrario: quitar algo. elimine algo de las páginas.

El problema real muy a menudo es que ya hay mucho. La mayoría de las páginas tienen todo tipo de cosas que el usuario no necesita: demasiadas palabras, demasiadas imágenes irrelevantes, demasiada decoración, demasiado “ruido”, y ésa es la razón por la que los usuarios no encuentran lo que necesitan.

Si su primer impulso es añadir algo, siempre se lo debería cuestionar. Normalmente siempre es mejor que quite algunas de las cosas que distraen al usuario.

Steve Krug en “Haz fácil lo imposible. Cómo detectar y determinar los probleas de usabilidad”, página 169.

Tercera encuesta de lectores de pantalla de WebAIM

Se acaban de publicar los resultados de una encuesta, la tercera ya, de WebAIM a 1245 usuarios de lectores de pantalla Screen Reader User Survey #3 Results. No se cuenta mucho sobre la metodología de la encuesta, pero se adivina que los resultados pueden tener un sesgo muy importante: En la muestra hay 1049 usuarios angloparlantes (casi un 85%).

Como bien dicen ellos The sample was not controlled and may not represent all screen reader users. Pero eso no quita para encontrar algunos resultados más que interesantes, y aunque no se pueda extrapolar estadísticamente al universo de usuarios de lectores de pantalla (y mucho menos a las personas con discapacidad en general), sí que nos puede dar información de cierta utilidad y posibles tendencias.

Un detalle importante del informe, es que los resultados están muy bien organizados y permite ojearlos con mucha facilidad (título, gráfico de sectores, información en tablas y en ocasiones interpretación de resultados). Comencemos extrayendo algunos datos que me han llamado la atención, y que cada uno saque sus propias conclusiones.

  • Un 52.6% se consideran usuarios avanzados de lectores de pantalla (Screen Reader Proficiency).
  • Un 59.2% usa JAWS (de Freedom Scientific) como lector de pantalla principal (Primary Screen Reader).
  • Un 80% ha actualizado el lector de pantalla el último año. Me parece un dato muy importante (Screen Reader Updates).
  • El 98.4% tiene Javascript activado (JavaScript Enabled).
  • El 66.7% utiliza lectores de pantalla en el móvil (¡en Enero del 2009 sólo era de un 12%!). Mobile Screen Reader Usage
  • A la pregunta ¿Cuál de las siguientes opciones cree que tendría un mayor impacto en la mejora de la accesibilidad web? Un 75.8% responde que sitios webs más accesibles y un 24.2% mejores tecnologías de asistencia (Impacts on Accessibility).
  • Sobre sitios de Social Media,… un 52.2% son usuarios de Facebook (en el tercer Observatorio de Redes Sociales de The Cocktail Analysis son un 78%) y un 42.8% son usuarios de Twitter (en el estudio de The Cocktail Analysis son un 14%). Obviamente las cifras no son comparables porque metodológicamente los estudios no tienen nada que ver, pero bueno, aunque sólo sea por curiosidad, llama la atención. Sobre la accesibilidad de este tipo de webs (blogs, facebook, Linkedin, MySpace, Twitter, Youtube,…) un 52.3% piensa que son “un poco” accesibles (Social Media, Social Media Accessibility).
  • Con respecto a las sensaciones que les produce la inminente publicación y posible difusión de HTML5 con en relación con la accesibilidad, un 49.5% no lo sabe y un 33.7% opinan que mejorará la accesibilidad (HTML5).
  • Con respecto al uso de Landmark Roles (de Accessible Rich Internet Applications WAI ARIA 1.0), se puede interpretar desde muchos puntos de vista, pero las respuestas a la pregunta ¿Cuál de las siguientes opciones describe mejor el uso de Landmark Roles? Un 30.9% no conocía que existiese la funcionalidad; un 25.9% lo usa para navegar; un 25.0% lo usa a veces; un 14.5% lo usa cuando está presente y un 3.6% todavía no lo tiene implementado en su lector de pantalla (ARIA Landmarks).
  • En páginas grandes, un 57.2% usan los títulos para navegar, un 21.5% el buscador y un 12.8% la búsqueda (Finding Information).
  • Parece que decrece el uso de vínculos para saltar contenido y los atajos de teclado (con respecto a la encuesta anterior) ¿Tal vez por el uso de Landmark Roles? (“Skip” Links, Access keys).
  • Resultados con cierta similitud los que se encuentran en el uso de versiones alternativas de un sitio web, ya sea la versión móvil o la versión de sólo texto (o específica para lectores de pantalla). La usan siempre que está disponible (13.9% versión móvil y 21.9% versión sólo texto); casi siempre (20.1% versión móvil y 15.3% versión sólo texto); a veces (30.7% versión móvil, 26.6% versión sólo texto); casi nunca (15.9% versión móvil, 18.3% versión sólo texto) y nunca (19.3% versión móvil, 13% versión sólo texto). Mobile Versions, Text-only or Screen Reader Versions.
  • Sobre la preferencia del uso de los títulos h1 en una página web, un 50.3% prefieren dos, uno para el nombre del sitio web y otro para el título del documento (Heading Structures).
  • Por último, con respecto a los atributos longdesc un 26.2% lo consideran muy útil y un 34.4% bastante útil (Longdesc).

Lenguajes de marcado en la web y MIME Type

Saco de la nevera un artículo que llevo cerca de dos años dándole vueltas (ya está bien). Personalmente me ha servido para tener más claro ciertas cosas que ignoraba y para recopilar algunas citas y vínculos: trata sobre HTML, XHTML, text/html y application/xhtml+xml. Es excelente si sufres insomnio.

HTML y XHTML

¿Qué diferencia hay entre text/html y application/xhtml+xml? ¿Porqué con HTML sólo puede usar text/html y con XHTML puede usar text/html, application/xhtml+xml, application/vnd.wap.xhtml+xml, text/xml, application/xml,…? ¿Por qué los desarrolladores web con un mínimo de conocimiento y experiencia suelen tener cierta aversión a Internet Explorer?

Son preguntas que no se responderán aquí, pero tendrás pistas. Y casi ni se hablará sobre HTML5. Como si no existiese.

HTML y XHTML: a tener en cuenta

Una de las ventajas-desventajas del HTML es su permisividad con los errores. Si hay algo que el navegador no entiende, simplemente lo ignora. Eso explica que cualquiera pueda hacer una página web, incluso con un editor de textos de ofimática. La página, puede que incluso se visualice en un navegador. Aunque el código generado probablemente una chapuza. Algo similar puede ocurrir si usamos los editores What You See Is What You Get (lo que ves es lo que obtienes), si se hacen páginas sin ver ni entender el código.

Como consecuencia, la sintaxis que se puede utilizar en HTML, podemos denominarla dualmente como sencilla-compleja:

  • Sencilla, porque casi cualquier código que se publique, se visualiza en un navegador (por ejemplo <p class="description">Párrafo</p>, <P class=description>Párrafo, <P CLASS='description'>Párrafo</p>,… da igual si se usan mayúsculas y minúsculas en los elementos y atributos, se el valor de los atributos va entre comillas o no,…). De ahí que mucha gente pueda decir que sabe HTML, y que la web tenga la difusión actual.
  • Pero a la vez es complejo: es más complicado aprenderlo (demasiadas opciones, falta de una sintaxis única,…), es difícil de mantener el código, y los navegadores tienen que hacer un esfuerzo mayor para que -sabiendo que el código generalmente no es muy bueno-, se muestre “algo” en los periféricos de salida (pantalla, altavoz, terminal braille,…)

Por otro lado, tenemos XHTML: la sintaxis es única (de los ejemplos anteriores, sólo es válido <p class="description">Párrafo</p>). Pueda que exija un poco más de cuidado y atención en los detalles -sobre todo, si alguien está acostumbrado a un mal código de HTML -, pero si sabes XHTML de verdad, entonces sabes HTML. Desde un punto de vista didáctico, es recomendable aprender con la sintaxis de XHTML, y usar un validador de código. Usarlo mucho.

Por si acaso, y aunque se tratará con más profundidad el asunto de text/html y application/xhtml+xml más adelante, aquí va una introducción esquemática:

  • text/html y application/xhtml+xml son dos MIME Type, los más utilizados para páginas webs.
  • Los MIME Type se pueden configurar desde el servidor y también se puede modificar mediante lenguajes de programación.
  • text/html se usa para todas las páginas HTML y las páginas XHTML 1.0 que aunque usan la sintaxis de XHTML, son en la práctica, páginas HTML normales y corrientes. En principio es así para ser compatible con los navegadores más antiguos (e Internet Explorer hasta la versión 9).
  • application/xhtml+xml se usa para documentos XHTML que se comportan como documentos XML en navegadores más avanzados (donde, no está Internet Explorer hasta la versión 9) y una de sus características es que es extensible (se pueden añadir nuevos módulos como XHTML+RDFa, XHTML Role Attribute Module o XHTML Access Module) y se puede combinar con otros lenguajes (XML como SVG, MathML ó SMIL). Se emplea application/xhtml+xml obligatoriamente en XHTML 1.1 y se puede usar también en XHTML 1.0.

Si los navegadores fuesen estrictos con las páginas XHTML, la Web, se rompería

Ojo, que hay un falso alarmismo en los siguientes párrafos: XHTML servido como text/html es equivalente a HTML. Y sabemos que cualquier código HTML, por malo y cutre que sea, se mostrará en el navegador aunque el resultado no sea el deseado por el desarrollador web (leer desarrollador web con tono irónico). Pero sigamos con el alarmismo parcialmente injustificado.

Siendo puristas – con XHTML se debería de ser muy purista, especialmente cuando no se envía como text/html, es decir, lo trata como un documento XHTML de verdad – el código tiene que ser siempre válido. Teóricamente, no se deberían tener errores. Pero,… ¿qué ocurriría si los navegadores siempre fuesen estrictos, y no mostrasen las páginas XHTML que fuesen incorrectas?. O dicho de otra manera, ¿qué ocurriría si los navegadores interpretasen las páginas webs servidas como text/html (ya sea HTML o XHTML) como lo hacen con las páginas servidas como application/xhtml+xml? Te lo puedes imaginar: teniendo en cuenta que son excepcionales desde un punto de vista estadístico las webs que tienen su código correcto, serían las únicas que se mostrasen correctamente. ¿El resto? Tal vez sólo se vería una página de error, como el conocido XML Parsing Error de Mozilla.

Si los navegadores fuesen puristas, la Web, directamente, se rompería. Si, supongamos, el 95% de las páginas webs no se mostrasen correctamente en los navegadores, tendría un impacto cuanto menos, apocalíptico (para la web). ¿Un 95% de páginas inválidas no es una exageración? Pues no, en todo caso, es incluso optimista. Según el estudio MAMA elaborado por Opera durante el año 2008, sólo el 4,13% de las páginas validadas en su numerosa muestra (más de 3,5 millones de páginas) tenían su código correcto (puedes leerlo en MAMA: Markup validation report).

En el estudio se hace referencia a las páginas webs en general, sin distinguir entre HTML y XHTML. Se podría pensar que puede haber diferencias significativas, y aquellas páginas publicadas en XHTML, suelen tener menos errores… pero no. De aquellas webs que incluyen el icono de conformidad de código válido (puedes verlos The W3C “validation” icons), el porcentaje de páginas que mienten – es decir, que no tienen el código correcto -, es muy similar en HTML y XHTML: alrededor del 50%. Lo cierto es que incluir un icono de conformidad hoy en día tiene muy poco valor, ya sea para confirmar que el código es válido o que la web cumple los criterios de accesibilidad indicados. Vale, estamos en el 2011 y el estudio es del año 2008, pero honestamente, no creo que las cosas hayan cambiado mucho.

Por eso los navegadores tienen que intentar adivinar como interpretar más o menos el código de la vida real, por muy malo que sea y por muchos errores que tenga. Y por supuesto, tienen la obligación moral – ya el W3C recomienda, no obliga -, de cumplir las Recomendaciones (la denominación del W3C equivalente a estándar) que publica. Algunos aspectos de las recomendaciones, tienen una tolerancia al error asumible, en el sentido de que no pasa nada si no funciona: no es importante, o existen alternativas para solucionarlas. Pero en otros casos, las consecuencias pueden ser críticas y la transcendencia e importancia sobrepasan los tolerable. Uno de esos casos es el nulo soporte de Internet Explorer, desde su versión 6 hasta la actual, la 8, para application/xhtml+xml (menos mal que en la versión 9 de Internet Explorer por fin lo soporta).

text/html y application/xhtml+xml

text/html y application/xhtml+xml: un poco de historia

Tras la introducción podemos empezar diciendo que para HTML 4.01 (1999) el W3C especificó que las páginas se enviasen con el MIME Type text/html.

Más tarde, surgió XHTML 1.0. En la primera edición (año 2000) todavía no estaba claro que MIME Type se iba a utilizar (leer XHTML 1.0 (primera edición): 5.1 Internet Media Type para verlo en la especificación). Pero en la segunda edición, hay dos opciones:

  • enviarlo como text/html para ser compatible con los navegadores más antiguos.
  • o bien enviarlo como application/xhtml+xml – definido en RFC3236 (2002) -, para aquellos navegadores que interpretaban correctamente XML, y que podían aprovechar sus ventajas.

Entre los navegadores que interpretaban correctamente las páginas XHTML servidos como application/xhtml+xml – hablamos del 2002 -, estaban prácticamente todos los de la época y los que surgieron poco después. Hablamos de los tristemente difuntos Mozilla y Netscape, además de los que todavía siguen en activo: Firefox, Opera, Camino, Safari… Incluso aquellos navegadores para móviles que soportaban WAP2, (insisto, hablamos del 2002)… todos interpretaban correctamente las páginas XHTML servidas como application/xhtml+xml.

¿Todos? Todos…, excepto Internet Explorer. A día de hoy, año 2011, con la versión 8 de su navegador a punto de ser reemplazada (al menos en teoría, todavía hay muchas versiones 6), en Microsoft ha estado ignorando un estándar que tiene ya 9 años. Desde la versión 6 SP 1, hasta la versión 8 (incluida). Sin comentarios.

Posibilidades de XHTML servido como application/xhtml+xml

XHTML servido como application/xhtml+xml es interpretado como un documento XML de verdad. Gracias a la extensibilidad mediante la modularización de XHTML – por la X inicial -, tiene las siguientes posibilidades:

  • Lo típico, combinar XHTML 1.1 con estándares clásicos como SVG, MathML ó SMIL.
  • Validación XML.
  • Desde el punto de vista de la Web Semántica, podemos usar XHTML+RDFa, que ya es recomendación del W3C, y nos permite añadir información semántica de gran riqueza (ver RDFa Primer y RDFa in XHTML: Syntax and Processing) ó usar XHTML Role Attribute Module, también relacionado, entre otros aspectos, con la accesibilidad y adaptación a diferentes dispositivos. XHTML Role Attribute Module es más limitado pero útil (ojo, que de momento sólo es un borrador de trabajo).
  • Desde el punto de vista de la accesibilidad, podemos usar XHTML Access Module, aunque todavía es un borrador de trabajo.
  • … y lo que vaya saliendo, porque la modularización de XHTML tiene muchas posibilidades (digo yo, que con HTML5 no se cargarán XHTML, ¿no?).

A tener en cuenta cuando usamos XHTML servido como application/xhtml+xml

Se supone que antes de desarrollar en XHTML, has leído XHTML 1.0 The Extensible HyperText Markup Language y especialmente la sección C. HTML 1.0 The Extensible HyperText Markup Language Compatibility Guidelines. Y lo más importante: entiendes todo. Por descontado, tienes la buena costumbre de comprobar que tu código es válido (por ejemplo en The W3C Markup Validation Service).

En cualquier caso, al usar XHTML servido como application/xhtml+xml, hay que tener presente algunos aspectos muy importantes, que en ocasiones inconvenientes, que puedes encontrar en Hixie: Sending XHTML as text/html Considered Harmful, secciones “SPECIFIC PROBLEMS” y “The Myth of “HTML-compatible XHTML 1.0 documents” (por cierto, ¡está en formato txt!). El artículo de Hixie, actual editor de la especificación de HTML 5, es una referencia importante al recopilar las particularidades de application/xhtml+xml, y emite conclusiones discutibles. Pero tú, inteligente lector, tienes la capacidad de sacar tus propias conclusiones. Personalmente creo, que recomendar a los novatos no aprender XHTML es una estupidez de las gordas. Aún así, repito: el artículo es una referencia, y muy importante, sobre application/xhtml+xml.

Citas del W3C sobre text/html y application/xhtml+xml

Especificación de HTML 4.01 (24 de diciembre de 1999)

HTML documents are sent over the Internet as a sequence of bytes accompanied by encoding information (described in the section on character encodings). The structure of the transmission, termed a message entity, is defined by [RFC2045] and [RFC2616]. A message entity with a content type of “text/html” represents an HTML document.

HTML 4.01 Specification : 4.3 The text/html content type

Segunda edición de la especificación de XHTML 1.0 (1 de agosto de 2002)

XHTML Documents which follow the guidelines set forth in Appendix C, “HTML Compatibility Guidelines” may be labeled with the Internet Media Type “text/html” [RFC2854], as they are compatible with most HTML browsers. Those documents, and any other document conforming to this specification, may also be labeled with the Internet Media Type “application/xhtml+xml” as defined in [RFC3236]. For further information on using media types with XHTML, see the informative note [XHTMLMIME].

XHTML™ 1.0 The Extensible HyperText Markup Language (Second Edition): 5.1. Internet Media Type

HTML and XHTML Frequently Answered Questions (21 de julio del 2004).

Why is it allowed to send XHTML 1.0 documents as text/html?

XHTML is an XML format; this means that strictly speaking it should be sent with an XML-related media type (application/xhtml+xml, application/xml, or text/xml). However XHTML 1.0 was carefully designed so that with care it would also work on legacy HTML user agents as well. If you follow some simple guidelines, you can get many XHTML 1.0 documents to work in legacy browsers. However, legacy browsers only understand the media type text/html, so you have to use that media type if you send XHTML 1.0 documents to them. But be well aware, sending XHTML documents to browsers as text/html means that those browsers see the documents as HTML documents, not XHTML documents.

Which browsers accept the media type application/xhtml+xml?

Browsers known to us include all Mozilla-based browsers, such as Mozilla,Netscape 5 and higher, Galeon and Firefox, as well as Opera, Amaya, Camino, Chimera, DocZilla, iCab, Safari, and all browsers on mobile phones that accept WAP2. In fact, any modern browser. Most accept XHTML documents as application/xml as well. See the XHTML Media-type test for details.

Does Microsoft Internet Explorer accept the media type application/xhtml+xml?

No. However, there is a trick that allows you to serve XHTML1.0 documents to Internet Explorer as application/xml.

Include at the top of your document the line in bold here:

<?xml version="1.0" encoding="iso-8859-1"?>
<?xml-stylesheet type="text/xsl" href="copy.xsl"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
	"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

	<html xmlns="http://www.w3.org/1999/xhtml">
	<head>

where copy.xsl is a file that contains the following:

<stylesheet version="1.0"
	xmlns="http://www.w3.org/1999/XSL/Transform">
	<template match="/">
		<copy-of select="."/>

	</template>
</stylesheet>

Note that this file must be on the same site as the document referring to it.

Although you are serving the document as XML, and it gets parsed as XML, the browser thinks it has received text/html, and so your XHTML 1.0 document must follow many of the guidelines for serving to legacy browsers.

Your XHTML document will continue to work on browsers that accept XHTML 1.0 as application/xml.

HTML and XHTML Frequently Answered Questions

Working Group Note : XHTML Media Types – Second Edition (16 de enero del 2009)

Many people want to use XHTML to author their web pages, but are confused about the best ways to deliver those pages in such a way that they will be processed correctly by various user agents[…]

XHTML Media Types – Second Edition: Abstract

After the publication of [XHTML1], an RFC for XML media types was revised and published as RFC 3023 [RFC3023], and it introduced the ‘+xml‘ suffix convention for XML-based media types. The ‘application/xhtml+xml‘ media type [RFC3236] was registered following that convention.

[…]

In general, ‘application/xhtml+xml‘ should be used for XML Family documents, and the use of ‘text/html‘ should be limited to HTML-compatible XHTML Family documents intended for delivery to user agents that do not explicitly state in their HTTP Accept header that they accept ‘application/xhtml+xml‘ [HTTP].

[…]

Note that, because of the lack of explicit support for XHTML (and XML in general) in some user agents, only very careful construction of documents can ensure their portability (see Appendix A). If you do not require the advanced features of XHTML Family markup languages (e.g., XML DOM, XML Validation, extensibility via XHTML Modularization, semantic markup via XHTML+RDFa, Assistive Technology access via the XHTML Role and XHTML Access modules, etc.), you may want to consider using HTML 4.01 [HTML] in order to reduce the risk that content will not be portable to HTML user agents. Even in that case authors can help ensure their portability AND ease their eventual migration to the XHTML Family by ensuring their documents are valid [VALIDATOR] and by following the relevant guidelines in Appendix A.

XHTML Media Types – Second Edition: Introduction

The ‘application/xhtml+xml‘ media type [RFC3236] is the primary media type for XHTML Family documents.

application/xhtml+xml‘ should be used for serving XHTML documents to XHTML user agents (agents that explicitly indicate they support this media type).

This media type must be used when writing documents using XHTML Family document types that add elements and attributes from foreign namespaces, such as XHTML+MathML [XHTML+MathML].

XHTML Media Types – Second Edition: 3.1. ‘application/xhtml+xml

The ‘text/html‘ media type [RFC2854] is primarily for HTML, not for XHTML. In general, this media type is NOT suitable for XHTML except when the XHTML is conforms to the guidelines in Appendix A.

In particular, ‘text/html‘ is NOT suitable for XHTML Family document types that add elements and attributes from foreign namespaces, such as XHTML+MathML [XHTML+MathML].

XHTML Media Types – Second Edition: 3.2. ‘text/html

Otras referencias

Al final

Aquí no hay moraleja que valga: pero si hay una recomendación coherente, los navegadores y los desarrolladores las interpretan correctamente, y los navegadores antiguos no se ven perjudicados, perfecto. Si no, en la historia de la web, que no tiene demasiados años, podemos encontrar algún que otro “Caso de fracaso”: el aquí ampliamente expuesto, Guerra de Navegadores, la interpretación personal de Explorer del modelo de caja (Internet Explorer Box Model Bug),… veremos al final que pasa con HTML5, pero miedo me da.