Entradas etiquetadas “dispositivos”.

Buenas prácticas para la web móvil, del W3C

El original y una traducción, libre, de la lista de 60 buenas prácticas que tratan en profundidad:

  • Asegura que el contenido al que da acceso un URI dé una experiencia temáticamente coherente al acceder a él desde diferentes dispositivos.
  • Explota las capacidades de los dispositivos para mejorar la experiencia de usuario.
  • Toma pasos razonables para subsanar las implementaciones deficientes.
  • Haz pruebas sobre dispositivos reales, además de en emuladores.
  • Haz breves los URIs de los puntos de entrada.
  • Da solo una navegación mínima en lo alto de la página.
  • Ten en cuenta los compromisos entre tener demasiados enlaces en una página y pedir al usuario que siga demasiados enlaces para llegar a lo que busca.
  • Da mecanismos de navegación consistentes.
  • Asigna teclas rápidas a los enlaces de los menús de navegación y a la funcionalidad de uso frecuente.
  • Identifica claramente el objetivo de cada enlace.
  • Anota el formato del fichero enlazado a menos que estés seguro de que el dispositivo lo soporta.
  • No uses mapas de imagen a menos que sepas que el dispositivo los soporta de manera efectiva.
  • No uses pop-ups ni hagas aparecer otras ventanas ni cambies la ventana actual sin avisar al usuario.
  • No crees páginas que se autorefresquen periódicamente a menos que informes al usuario y le dotes de un mecanismo para detener el refresco.
  • No uses marcado para redirigir páginas automáticamente: configura el servidor para hacer las redirecciones mediante códigos HTTP 3xx.
  • Minimiza el número de recursos externos enlazados.
  • Asegúrate de que el contenido es adecuado para su uso en un contexto móvil.
  • Usa lenguaje claro y simple.
  • Limita el contenido a lo que el usuario ha pedido.
  • Divide el contenido en porciones usables pero limitadas.
  • Asegúrate de que el tamaño total de la página sea apropiado para las limitaciones de memoria del dispositivo.
  • Limita el ’scroll’ a una dirección, a menos que el scroll secundario sea inevitable.
  • Asegúrate de que el material central al significado de una página preceda al que no lo es.
  • No uses gráficos para el espaciado.
  • No uses imágenes que no puedan mostrarse en el dispositivo. Evita las imágenes grandes o de alta resolución excepto cuando de otra forma se perdería información crítica.
  • Asegúrate de que la información comunicada a través del color también esté disponible sin este.
  • Asegúrate de que la combinación de color de primer plano y fondo dé suficiente contraste.
  • Al usar imágenes de fondo, asegura la legibilidad del contenido en el dispositivo.
  • Usa títulos de página breves pero descriptivos.
  • No uses marcos.
  • Usa las características del lenguaje de marcado para indicar la estructura lógica del documento.
  • No uses tablas a menos que sepas que el dispositivo las soporta.
  • No uses tablas anidadas.
  • No uses tablas para maquetar.
  • En la medida de lo posible, da una alternativa para las presentaciones tabulares.
  • Da un equivalente textual para cada elemento no textual.
  • No confíes en objetos embebidos ni scripts.
  • Especifica el tamaño de las imágenes en el marcado, si tienen un tamaño intrínseco.
  • Cambia el tamaño de las imágenes en el servidor, si tienen un tamaño intrínseco.
  • Crea documento que validen según las gramáticas formales publicadas.
  • No uses medidas en píxeles ni unidades absolutas en los valores de los atributos de los lenguajes de marcado y valores de las propiedades de las hojas de estilo.
  • Usa hojas de estilo para controlar la maquetación y la presentación, a menos que sepas que el dispositivo no las soporta.
  • Organiza los documentos de forma que puedan leerse, en caso necesario, sin las hojas de estilo.
  • Usa hojas de estilo cortas.
  • Usa marcado conciso y eficiente.
  • Envía el contenido en un formato que sepas que el dispositivo soporta.
  • Siempre que sea posible, envía el contenido en un formato preferente.
  • Asegura que el contenido use una codificación de caracteres soportada por el dispositivo.
  • Indica en la respuesta la codificación de caracteres usada.
  • Da mensajes de error informativos y formas de navegar desde la página de error a información útil.
  • No confíes en que las cookies estén disponibles.
  • Da información de caché en las respuestas HTTP.
  • No confíes en los estilos de las tipografías.
  • Minimiza las pulsaciones de teclas.
  • Evita la entrada de texto libre en la medida de lo posible.
  • Da valores por defecto preseleccionados siempre que sea posible.
  • Especifica modo de entrada de texto, idiomas y/o formatos de entrada por defecto, si el dispositivo los soporta.
  • Crea un orden lógico para los enlaces, controles de formulario y objetos.
  • Etiqueta todos los controles de formulario apropiadamente y asocia explícitamente las etiquetas con los controles.
  • Posiciona las etiquetas de forma que que queden dispuestas apropiadamente en relación a los controles a que se refieren.

Pocas sorpresas, mucho sentido común y un lenguaje, inevitablemente, políticamente correcto. Pero una buena lista de cosas a tener en cuenta cuando nos ponemos a desarrollar.

Web móvil y otras cosillas…

Excelente el artículo The Web Beyond the Desktop, de Dave Shea en Digital Web Magazine. No habla solo de web móvil, sino de cómo la experiencia web huye del escritorio habitual y se marcha a la sala de estar, al dormitorio y, desde luego, a los dispositivos móviles. Su cuadro de “device viewing scenarios” tiene números de convertirse en un clásico. Interesante también cómo incide en que las mejoras de accesibilidad deberían repercutir también en la experiencia “fuera del escritorio” y en que es conveniente diseñar interfaces diferentes al del sitio principal para su consumo en pantallas “pequeñas”. Lectura muy recomendable.

Aprovecho que el Pisuerga pasa por Valladolid para enchufar aquí un par de cosillas que tenía como borrador desde hace una eternidad.

La primera. A veces una pantalla pequeña es mejor. Mucho más discreto leer Google Reader o charlar por Messenger en una reunión con el N95 que con el iPod Touch, por no hablar de cosas más grandes, como un N800 o un portátil…

La segunda. Safari para iPhone y iPod Touch es ‘la web’ y no la web móvil. Jobs dixit. Opera Mini para el N95 (y demás dispositivos sobre los que corre) también afirma lo mismo. Tristemente, cuando lo dicen lo que quieren decir en realidad es que pasan olímpicamente de las hojas de estilo para handheld. Todo parece indicar que las próximas versiones de Internet Explorer para dispositivos harán lo mismo. Si eso es respeto a los estándares… Y aún así Google, Facebook, Yahoo! y demás grandes propiedades de la web se afanan en diseñar páginas específicas para dispositivos, mientras que “startups” como Mowser se dedican a “movilizar” sitios web de terceros. ¿No querrá eso decir algo? En mi experiencia particular, además, hace dí­as que le dije a Google Reader que reformatease las páginas web que visito desde él tanto desde el Touch como desde el N95. Efectivamente, los dispositivos móviles que usamos hoy en día son potentes como los ordenadores de anteayer. Pero las pantallas tienen los tamaños y resoluciones que tienen, las interfaces de usuario de los dispositivos son las que son (sin importar que sea un dedo, un teclado numérico o un mando a distancia, decididamente no son un ratón) y muchos de los elementos habituales en el diseño de interfaces web dejan de ser válidos.

Esta segunda observación me lleva a una recomendación del W3C en sus buenas prácticas para desarrollo web que no me cuadra en absoluto. Dicen: Diseña para una web única. No. De ninguna manera. Diseña para una web plural. En la que no sabes si el usuario mira una pantalla de 3 pulgadas a un palmo de distancia, de 17 a 4 palmos o de 42 a unos pocos metros. Y en la que el usuario puede navegar con un teclado numérico, los dedos, un ratón o un mando a distancia (ya que estamos, no olvidemos la posibilidad de que el usuario, directamente, no vea la pantalla y solo la oiga). Lo que nos lleva a poner los contenidos textuales primero, el maquetado después (a poder ser adaptado al medio), añadir las imágenes a continuación (de nuevo, a poder ser, pensando en tamaños y depeís) y, finalmente, añadir comportamientos (para los dispositivos en que tenga sentido)…