logodotmobi.pngDentro de la documentación que hay que saber y necesaria para aprobar el examen de certificación dotMobi Mobile Web Developer Certification se encuentra la más que conocida Mobile Web developer´s Guide de Blue Flavor de buenas practicas para el desarrollo web móvil a la que en alguna ocasión he hecho referencia. El caso es que gracias a un compañero del curro os puedo pasar, con su permiso, un resumen a modo apuntes de dicha guía. Espero que os sea de tanta utilidad como a mi.

Gracias Fernándo estás hecho un crack¡¡.

1 OBJETIVOS DEL SITIO WEB

1.1 Del negocio

  • Como ayuda a la organización, la presencia móvil.

1.2 Del usuario

  • Como se beneficia la audiencia de una presencia móvil.
  • Pensar en como y donde va a interactuar el usuario con el sitio web.

Los objetivos del cliente son un buen punto de inicio, especialmente cuando se considera la presentación móvil.

2 ARQUITECTURA

Mantener la sencillez.

  • Limitar las opciones: Evita el riesgo de que el usuario se pierda.
  • Estructura simple en forma de árbol. Poco ramificado y poca profundidad.
  • Limitar la cantidad de categorías o el usuario se desorientará.
  • Limitar los enlaces a 10 por página: Codificar los enlaces con accesskeys para que se pueda navegar con el teclado.
  • Priorizar los enlaces por actividad o popularida: Aumenta probabilidad de mostrar primero lo que buscan.
  • Click streams: Separa la info en múltiples páginas, mejor que presentarlo todo en un sola.

3 DISEÑO WEB

La usabilidad la define el ancho de pantalla.

  1. Teléfonos, “solo llamadas de voz”: No son relevantes para la web móvil.
  2. Teléfonos multimedia: Habitualmente teclado de 12 teclas, Enfocados al mercado general.
  3. Smartphones: Permiten ejecutar aplicaciones de terceros. Consumidores avanzados o sector negocios como dispositivos de productividad.
  4. PDAs: Incluyen pantalla táctil y algunas teclado QWERTY. Pantalla más grande. Pueden cambiar entre horizontal y vertical. Orientados a tareas organizacionales.

3.1 Layout

[CABECERA]
[NAVEGACIÓN]
[CONTENIDO]
[NAVEGACIÓN]
[PIE]

  • Evitar medidas en píxeles (px), mejor usar porcentajes(%) o em.
  • En bloques <pre> limitar a 25 o 30 chars (carácteres) o usar un estilo pre{white-space:pre-wrap;}

4 ESTÁNDARES DE LA WEB MÓVIL.

4.1 Contexto por defecto (DDC: Default Delivery Context)

  1. Entorno mínimo en que se puede experimentar la web.
  2. Diseñar con estos dispositivos en mente asegura la interoperatividad, pero solo considerar estos desaprovecha la oportunidad de proporcionar mejor experiencia a otros más capaces.

4.2 Reglas de dominio dotMobi

  1. Debe presentar las páginas en XHTML-Mobile 1.0 o posterior como presentación por defecto.
  2. Se debe poder acceder desde http://www.dominio.mobi y http://dominio.mobi
  3. No se deben usar frames

4.3 Recomendaciones del dominio dotMobi

Seguir las best practices del W3C (World Wide Web Consortium).

5 XHTML

Uso del XHTML Basic o XHTML Mobile Profile

5.1 Usar el ENCODING y DOCTYPE correctos

  • <?xml version="1.0" encoding="UTF-8" ?>
  • <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.1//EN" "http://www.w3.org/TR/xhtml-basic/xhtml-basic11.dtd">
  • <!DOCTYPE html PUBLIC "-//WAPFORUM//DTD XHTML Mobile 1.0//EN" "http://www.wapforum.org/DTD/xhtml-mobile10.dtd">

5.2 Utilizar siempre código bien formado

  • Todos las etiquetas deben estar cerradas.
  • Las etiquetas deben anidarse correctamente
  • Para todas las imágenes debe utilizarse el atributo alt
  • Cualquier texto debe estar contenido en un bloque, no directamente en el body.
  • Todos los valores de atributos deben estar entra comillas dobles
  • Todas las etiquetas y atributos deben estar en minúsculas.

5.3 No usar tablas para el layout

Emplear tags <div> para el contenido y aplicar hojas de estilo (CSS).

5.4 Emplear navegación en el cuerpo del contenido

No es bueno tener toda la navegación en cada páginas. Emplear solo la relevante para cada páginas.

5.5 Usar accesskey en la navegación principal

  1. <a href="./index.xhtml" accesskey="1">Principal</a>
  2. Deben corresponderse con un número del teclado siempre que sea posible.
  3. Es dificil proporcionar atajos de teclado para más de 10 elementos.

5.6 Utilizar listas ordenadas para la navegación

  • Procurar que la navegación de la página se encuentre en el cuerpo para evitar verticalidad y peso.
  • Para la páginas principal se puede proporcionar una descripción para cada enlace, envolviendo cada descripción en etiquetas <span>

5.6 Enlazar número de teléfono

<a href=”tel:+3499399203″>Teléfono +3499399203<a>
Se recomienda mostrar el número de teléfono en lugar de una descripción del mismo

5.7 Tratar con formularios puede ser complicado

Reducir al mínimo la información requerida en los formularios.

6 BUENAS PRÁCTICAS

6.1 Caracter encondig

Los documentos XML tienen siempre codificación UTF-8, los servidores como text/html ISO 8859-I

6.2 Doctype

  • Emplear XHTML MP 1.0 como lenguaje de marcas por defecto para páginas específicas para móvil.
  • <!DOCTYPE html PUBLIC "-//WAPFORUM//DTD XHTML Mobile 1.0//EN" "http://www.wapforum.org/DTD/xhtml-mobile10.dtd">

6.3Tipo MIME

Para XHTML MP y Basic se recomienda application/xhtml+xml, no debe servirse como text/html.

6.4 Título de páginas

  1. Usar un título corto y descriptivo, teniendo en cuenta que el dispositivo puede truncarlo.
  2. Un título util puede estar compuesto de una breve descripción del contenido de la página más el nombre del sitio web.
  3. Tener en cuenta que se utilizará para los bookmarks (enlaces favoritos).

6.5 Hojas de estilos

  • Muchos dispositivos cargar primero el markup, cargando las imágenes y hojas de estilo después.
  • Se puede evitar el salto en la presentación añadiendo en el propio markup los estilos más importantes en la cabecera.

6.6 Objetos incrustados y scripts.

Muchos dispositivos no soportan objetos incrustados o scripts, o pueden haberse deshabilitado. Hay que evitarlos.

6.7 Autorefresco

Evitarlo salvo que se notifique al usuario y se proporcione forma de deshabilitarlo.

6.8 Redirecciones

Configurar el servidor para usar peticiones HTTP 3xx.

Evitar en la medida de lo posible, ya que añaden coste en tiempo y dinero.

6.9 Cacheo

  1. Reduce el número de veces que los dispositivos descargar recursos comunes.
  2. No todos los navegadores web lo soportan.
  3. <meta http-equiv="Cache-Control" content="max-age=300" />

6.10 Estructura

Estructurar con encabezados y subencabezados para asegurar una estructura lógica y con sentido.

6.11 Tablas

  1. Envitarlas al menos que el dispositivo lo soporte
  2. Nunca para layout
  3. Para mostrar datos mejor emplear definition lists (<dl>)

6.12 Frames

No se permiten en los sitios dotMobi. Mejor emplear SSI (Server Side Includes).

6.13 Contenido

  1. Limitar a 10 enlaces por página y añadirsles accesskeys.
  2. Priorizar por popularidad
  3. El final de cada página debe permitir navegar hacia: categoría padre, contenido relacionado, inicio o mostrar una lista de navegación.
  4. Los accesskeys deben ser consistentes a lo largo de todo el sitio web.
  5. Evitar los textboxes y textareas en la medida de los posible.
  6. Metodo de entrada por defecto: Establecer el inputmode (alfanum o num) del dispositivo de acuerdo con la entrada.
    <input type="text" style=' -wap-input-format: "*N"' />
    <input type="text" style=' -wap-input-format: "A*a"' />

6.14 Imágenes

  1. Hacer tan pequeñas como sea posibles (en pixeles).
  2. El ancho debe ser inferior a 120 px salvo que el dispositivo lo soporte.
  3. Evitar que la imagenes compongan información muy extensa, al redimensionar se puede dejar de ver bien (se pierde la información).
  4. Declara el tamaño de la imagen, sino, lo tendrá que calcular el dispositivo.
  5. Evitar mapas de imagenes.
  6. Siempre emplear texto alternativo para las imágenes.

6.15 Otra buenas práticas

  1. Evitar los popups
  2. Limitar el numero de recursos externos y mantener su tamaño lo menor posible.
  3. El tamaño total (contando los recursos incluidos), debe permanecer por debajo de los 10kb.

7 PUBLICACIÓN MÓVIL

7.1 Soporte de dispositivos

  1. Solo los sitios web que formen parte de un portal de proveedor móvil deben soportar todos los dispositivos
  2. Reconociendo el dispositivo se puede proporcionar mejor experiencia
  3. Dependiendo de la audiencia, algunos dispositivos pueden no ser soportados
  4. Un buen punto de inicio es soportar las 5 clases de dispositivos principales representativos del mercado

7.2 Nombrado de los sitios web

  1. Utilizar el dominio .mobi para indicar que el sitio es “mobile friendly”
  2. Si no se dispone de un dominio .mobi, educar al usuario para que entre por dominio.com/mobile o mobile.dominio.com
  3. Detectar el tipo de dispositivoy redireccionar a la versión móvil, permitiendo acceder a la versión de escritorio.

7.3 Tipos MIME

Usar application/xhtml-xml

7.4 Prueba

  • Emuladores
  • Dispositivos reales
  • iFrame con proporciones del dispositivo para probar desde escritorio
  • Navegadores específicos: Opera tiene pantalla pequeña que simula la pantalla móvil. Firefox tiene extensioens que dejan cambiarel user-agent

8 ADAPTACIÓN

Consiste en seleccionar y formatear el contenido basándose en las diferencias entre los distintos tipos de dispositivos.

8.1 Elección del usuario

  1. Los dispositivos móviles no presentan la misma experiencia que el navegador de escritorio:
    • Tamaño de pantalla
    • Carencia de teclado completo
    • Carencia de dispositivo de señalización (obstáculo para la navegación)
  2. Antincipar las necesidades del usuario no debe evitar que pueda accder a otros contenido. Permitir que pueda saltarse lo que hemos asumido.
  3. Incluir enlace a modo escritorio en la parte móvil y vicerversa.

8.2 Adaptación en el lado del cliente

  1. Selectores de media usando CSS:
    • <link href="screen.css" rel="stylesheet" type="text/css" media="screen" />
    • <link href="mobile.css" rel="stylesheet" type="text/css" media="handheld" />
    • @media handheld {#image1 {display: none}}
  2. Es limitado. Útil solo cuando varía únicamente la presentación
  3. El dispositivo descarga lo mismo que el navegador de escritorio (tiempo y coste).

8.2 Adaptación en el lado del cliente

  1. Variar el contenido que mejor se adapte al dispositivo.
  2. Presentar una imagen de tamaño que mejor se adapte al dispositivo (limitar 120px si no se conoce)
  3. Redimensionar imágenes en el servidor mejor que en el navegador
  4. Preparar imágenes previamente dimensionadas y escoger el mejor tamaño

8.3 Detección del dispositivo

WURFL: Device Description Repository

<?php
$msie = strpos($_SERVER[“HTTP_USER_AGENT”],’MSIE’) > 0;
if (!$msie) {
header(“Content-Type: application/xhtml+xml; charset=UTF-8”);}
else {
header(“Content-Type: text/html; charset=UTF-8”);}
?>

8.4 Estrategias de adaptación

  1. Un tamaño para todos: Sitios con navegación simple pueden mostrarse correctamente tanto en escritorio como en dispositivos móviles
  2. Adaptaciones menores: Detectando las capacidades del dispositivo se pueden presentar mejores imágenes y características extra a dispositivos que se sepa que las soportan
  3. Redirección:
    • Sitios web separados para escritorio y dispositivos móviles
    • Combinando con adaptaciones menores para aprovechar las características de dispositivos más avanzados
    • El servidor compara el user-agent contro WURL (o la presencia de UAPROF, o el navegador informe que soporta WAP)
    • Si no se reconoce el dispositivo, se debe redireccionar por defecto a la versión móvil
    • El servidor envía una cabecera HTTP 301 o 302 con la URL de la página correspondiente
    • La redirección dificulta a los usuarios móviles acceder a la versión de escritorio si lo necesitaran
    • Algunos navegadores emulan user-agent de escritorio, dificultando a usuarios móviles acceder a la versión móvil.
    • Tanto la página móvil como la de escritorio deben contener enlace a la complementaria para permitir a los usuarios escoger

Los criterios que se asuman respecto al contexto del usuario móvil deben guiar el diseño de la experiencia móvil por defecto, pero debe evitarse que por los criterios que se han asumido los usuarios no puedan acceder a algún tipo de contenido.