Archivo

Posts Tagged ‘WURFL’

Técnicas y estrategias para el diseño de sitios multi-dispositivo. (moviles)

noviembre 8, 2010 2 comentarios

Hoy en día cuando se desarrolla una aplicación web, se debe tener en cuenta que puede ser visitada desde diferentes medios.

Al diseñar un sitio multi-dispositivo, se debe considerar cuales funciones y características se van a mostrar en cada tipo de dispositivo, suponiendo que estos varían, se va a requerir alterar el formato emitido por el servidor.

Debido a que existen numerosos dispositivos y dentro de estos existen numerosas versiones (versión del OS, navegador, html, css, js), se generan numerosas combinaciones que son un dolor de cabeza para los desarrolladores Web. Hoy en día, de las principales tareas en el desarrollo de un sitio web son la detección de las capacidades del medio y la detección del medio.

La detección de medio permite la identificación  de las propiedades y características de un dispositivo, con el propósito de determinar el mejor contenido, diseño, markup o aplicación a servir hacia el dispositivo, permite a los desarrolladores identificar funciones y características como tamaño de pantalla, tipo de navegador (o versión), si soporta video y audio, nivel de soporte de CSS, HTML y JS.

Identificación de medio por Bases de datos de dispositivos.

Cuando se desarrolla sitios, tarde o temprano se necesita saber que dispositivo está usando el usuario, es inevitable, todos los dispositivos son diferentes y para ofrecer una gran experiencia móvil se necesitan conocer las capacidades específicas de cada dispositivo. Entre más refinada se necesite la segmentación de un sitio web, se necesitará hacer algo más que checar las palabras clave en las cabeceras HTTP.

Actualmente, la mejor forma para detección de dispositivos es por medio de bases de datos de dispositivos,  como DeviceAtlas o Wurfl.

Estas bases de datos pueden ayudar a conocer todas las propiedades generales del dispositivo (así como proveer ajustes más finos dentro de los grupos que se definan con capacidades específicas). Estas base de datos tienen grandes conjuntos de datos con los tamaños de pantalla.

WURFL

WURFL está basado en el concepto de familias de dispositivos. Todos los dispositivos son descendientes de un dispositivo genérico, pero pueden también descender de familias más especializadas, este mecanismo llamado ‘fall_back’, permite a los desarrolladores derivar las capacidades de un teléfono buscando las capacidades de su familia, a menos que una cierta característica sea específicamente diferente para ese teléfono. Ver post anterior sobre WURFL.

Device atlas.

Device atlas es una solución para detección de dispositivos y contiene datos de más de 6,000 dispositivos. Se utiliza por medio de un API que provee device atlas y soporta PHP, Java, .NET, Ruby y Python. Para más información visitar: http://deviceatlas.com/get-started

Identificación de propiedades de dispositivo con  media queries.

CSS-3 mejora el soporte para los CSS que son dependientes al medio, y permite seleccionar las hojas de estilo de manera más precisa utilizando los media queries.

Los media queries  se usan del lado del cliente, y son muy útiles porque  permiten que el contenido se adapte a un rango específico de dispositivos de salida sin necesidad de tener que cambiar el contenido en sí. Se pueden usar para ajustar el diseño y el estilo de una página una vez que se carga en el dispositivo.

Un media query consiste de un tipo de medio y cero o más expresiones que comprueban  las condiciones de las características particulares del medio como ancho, alto o color. Las expresiones lógicas resuelven verdaderas o falsas. Por ejemplo

<link rel=”stylesheet” media=”screen and (max-device-width: 360px)” href=”ejemplo.css” />

Esto será verdadero para tipos de medio que sean screen y que tengan como ancho máximo 360px

El resultado de la expresión es verdadero si el tipo de medio especificado en el media query cumple con el tipo de dispositivo en donde el documento está siendo visto y todas las expresiones del media query son verdaderas.

Cuando el media query es verdadero, el CSS correspondiente es aplicado siguiendo las reglas de la hoja de estilo.

Se pueden crear consultas complejas usando operadores lógicos (not, and, only), así como combinar varios media queries en una lista separada por comas, si una consulta de la lista es verdadera entonces la hoja de estilos asociada es aplicada, es el equivalente al operador “or”.

El operador not, niega el resultado de la consulta “all and (not color)” es verdadera para dispositivos monocromáticos sin importar el tipo de medio.

El operador only, esconderá las hojas de estilo para navegadores antiguos que no soporten media queries.

<link rel=”stylesheet” media=”only screen and (color)” href=”ejemplo.css” />
Esto será verdadero para tipos de medio screen y que sean de color.

Los media queries no son sensibles a las mayúsculas y los paréntesis son requeridos para las expresiones.

Un problema que tienen es que su uso es vago en dispositivos de nivel medio / bajo, por lo que se debe de utilizar Progressive enhancement (seguir leyendo) de una manera que se degrade elegantemente el sitio.

Otro problema es que los media queries solo permiten manipular el estilo y tienen poca influencia sobre lo que se descargue al dispositivo, no pueden manipular el html por lo que se debe confiar en las reglas de CSS para por ejemplo cambiar el tamaño de las imágenes para que se adapten  al dispositivo.

Estrategias para servir contenido a diferentes dispositivos.

Existen diferentes técnicas para servir contenido en pantalla, además dependiendo del medio, existen API’s que facilitan estas acciones.

Progressive enhancement (mejora progresiva).

Una técnica muy común es desarrollar primero para navegadores antiguos y móviles (con menos capacidades que los modernos o de escritorio) y usar Progressive enhancement (mejora progresiva) para servir el contenido que soporte el dispositivo. Se pueden usar media queries y javascript para lograrlo. Una buena explicación de  Progressive enhancement se puede leer en la siguiente liga. http://www.alistapart.com/articles/understandingprogressiveenhancement/

Redirección de sitio.

Otra técnica es la redirección a otro dominio (o subdominio), dependiendo del medio que se detecte se reenvía a otro URL especifico para el dispositivo. Generalmente se usa por medio de la detección del agente de usuario o alguna librería de dispositivos del lado del servidor.

Plantillas.

Otra técnica es el uso de plantillas para familias de dispositivos, se agrupan capacidades de dispositivos en familias, dependiendo de las capacidades del medio que se detecten, se identifica la familia a la que corresponde y se muestra la plantilla. Se puede utilizar media queries, javascript o alguna librería de dispositivos del lado del servidor.

Algoritmos.

Es una técnica que usa algoritmos para cambiar el contenido van adaptando el contenido de manera apropiada para cada dispositivo. Generalmente se usa javascript.

Técnicas para cuidar el  rendimiento en la detección de dispositivos.

Es importante considerar el rendimiento en las aplicaciones Web. Detectar el dispositivo o las capacidades del medio en cada página que se visite de un sitio web no se considera como buena práctica porque afecta el rendimiento de la aplicación al estar realizando la misma tarea repetitivamente, para ayudar a mejorar el rendimiento, se realiza la detección en la primer visita y en las demás accesos solo se consulta la información que se guardó.  Algunas técnicas son:

Cookies de propiedades.

Para los dispositivos que aceptan cookies, una buena técnica es crear una cookie por medio de javascript, en esta cookie se almacenan las propiedades del medio de donde se está viendo la aplicación web, como por ejemplo ancho y alto de pantalla, y además se puede almacenar sus capacidades como por ejemplo si acepta xhr, canvas, flash ó localización.
La cookie se consulta por medio de la aplicación para proveer contenido adecuado al dispositivo,  y adaptarlo. Adicionalmente se puede combinar esta información con alguna base de datos para conocer características adicionales del dispositivo en caso de que sea necesario y formatear el contenido antes de enviarlo al dispositivo.

Los pasos generales son:

  1. Crear un objeto JS donde se guarda las propiedades y características que se necesitan en la aplicación.
  2. Cifrar el objeto en una cadena JSON y guardarlo en una cookie.
  3. Para cargar los datos de la cookie se descifra la cadena JSON de nuevo en un objeto JS.

Esta técnica funciona muy bien cuando se guarda poca información.
Un problema puede ser que si el navegador de donde se consulta no acepta cookies o las tiene desactivadas no funcionará así como tampoco si tienen javascript desactivado. Esto debido a que esta técnica se basa completamente en cookies y en javascript. Una solución a este problema es combinarlo con media queries o detección del lado del servidor, para conocer si acepta javascript y cookies.

Frames / iFrames.

Esta técnica se utiliza creando dos Frames, un Frame informativo, y otro Frame que se utiliza como navegación, este frame es el que se actualiza y en donde se generan todas las peticiones. Las propiedades y características del medio se guardan en un objeto javascript en el frame informativo. Esta técnica funciona también con iframes.
Un problema de este acercamiento es que el uso de frames no es una buena práctica en algunos dispositivos, además que no son soportados (o están desactivados) por algunos navegadores.

Web Storage (Almacenamiento Web).

Para navegadores que acepten HTML5 existe una característica que se llama Web Storage que es una especificación que define una API para el almacenamiento de datos (clave-valor) en los clientes Web. Este acercamiento es muy similar al de Cookies de propiedades pero usando un objeto nativo del navegador llamado localStorage.
Una ventaja es que acepta más tamaño de almacenamiento que las cookies. La desventaja es que solo se puede usar en navegadores modernos.

Recomendaciones para el desarrollo de sitios multi-dispositivos.

La meta de una aplicación multi-dispositivos o multi-pantalla no es necesariamente que se vea idéntica en cada dispositivo, más bien que se adapte a cualquier dispositivo.

Pensando en términos de  multi-dispositivo, se debe tomar en cuenta la experiencia de usuario del dispositivo (touch, track ball, track pad, teclado, etc) y asegurarse de que los elementos clickeables sean adecuados a la forma de navegación (los botones en ambientes touch sean suficientemente grandes para pulsarse).

Pensando en términos de multi-pantalla, se debe ajustar dinámicamente a la resolución y PPI del dispositivo en el cual se está viendo, desplegando más información en pantallas grandes, y removiendo o encogiendo elementos en pantallas pequeñas.

Para que las aplicaciones funcionen en diferentes pantallas, se deben diseñar de tal manera que se dibujen a sí mismas en el momento adecuado y con las restricciones adecuadas.

Siempre se debe de programar con código bien estructurado.

Para que se cargue rápido la aplicación se debe comprimir el contenido cuando y donde sea posible.

Se debe evitar el envío de datos innecesarios.

Al agrupar dispositivos por tamaño de pantalla, se debe considerar el markup que soporta, capacidades, método de interacción y más, todo depende del tipo de sitio.

Mantener un balance entre la accesibilidad, las capacidades, experiencia de usuario, usabilidad, funcionalidad, rendimiento y ancho de banda.

Anuncios

WURFL (Wireless Universal Resource FiLe) y Tera-WURFL para detección de capacidades de dispositivos móviles

agosto 25, 2010 4 comentarios

Debido a que existe una gran cantidad de navegadores para dispositivos móviles es complicado para los desarrolladores construir aplicaciones que trabajen adecuadamente en la mayoría de los dispositivos, de entrada necesitamos conocer las características que cada dispositivo soporta y las diferencias entre dispositivos; además de que se debe evitar modificar las aplicaciones cuando un nuevo modelo salga al mercado.

Los navegadores y dispositivos son diferentes, pero comparten muchas características en común entre ellos, muchas veces son del mismo fabricante, y son por lo general una evolución del mismo hardware/software, por lo tanto las diferencias entre modelos de un mismo fabricante son mínimas además que los dispositivos de diferentes fabricantes comparten también características y pueden correr la misma aplicación, es por esto que es mejor servir el contenido de nuestras aplicaciones basado en las características que soporta el dispositivo, en lugar de servir el contenido de acuerdo al modelo del dispositivo.

WURFL y Tera-WURFL son depósitos globales de dispositivos móviles y las capacidades que soportan, están orientados para ayudar a los desarrolladores en la construcción de mejores aplicaciones y mejores servicios para los usuarios, mientras que WURFL es un archivo de configuración XML, Tera-WURFL es una base de datos MySQL (SQLServer en su versión beta) que usa WURFL como su fuente de datos, ambas son herramientas muy útiles para detección de dispositivos, sus capacidades y características de manera programática, algunos ejemplos de uso podrían ser:

  • Redirección a versiones móviles de los sitios.
  • Detectar el tipo de video que el dispositivo móvil del usuario soporta.
  • Detectar usuarios iPhone, iPad, iPod y redirigirlos a sitios específicos para estos dispositivos.
  • Detectar la resolución de la pantalla del dispositivo del usuario para servir las imágenes adecuadas para esa resolución.
  • Detectar soporte de javascript, java o flash lite.
  • Detectar si es un dispositivo touch.

WURFL está basado en el concepto de familias de dispositivos. Todos los dispositivos son descendientes de un dispositivo genérico, pero pueden también descender de familias más especializadas, este mecanismo llamado ‘fall_back’, permite a los desarrolladores derivar las capacidades de un teléfono buscando las capacidades de su familia, a menos que una cierta característica sea específicamente diferente para ese teléfono.

Por ejemplo Nokia tiene varias versiones del modelo 7110, algunas de estas no soportan tablas WML,  otras si, WURFL extrae este conocimiento gracias al mecanismo fall_back:

La familia genérica especifica una capacidad llamada “table_support”

<device fall_back=”root” id=”generic” user_agent=””>
<group id=”ui”>
:
<capability name=”table_support” value=”true” />
</group>

Esto se lee como “Dispositivos WAP Genericos soportan tablas WML”

De manera inicial, los telefonos Nokia soportan tablas porque heredan de generic (fall_back=”generic”):

<device user_agent=”Nokia” fall_back=”generic” id=”nokia_generic”>
<group id=”ui”>
<capability name=”Capacidades que acepta este grupo” value=”false” />
</group>
</device>

Tomando en cuenta el soporte de tablas, el codigo anterior implica que para un dispositivo Nokia generico (nokia_generic) debe ser usado el mismo valor que tiene en generico.

<device user_agent=”Nokia7110/1.0 (04″ fall_back=”nokia_generic” id=”nokia_7110_ver1″>
<group id=”ui”>
<capability name=”table_support” value=”false” />
</group>
</device>
<device user_agent=”Nokia7110/1.0 (04.67)” fall_back=”nokia_7110_ver1″ id=”nokia_7110_ver1_sub467″ />
<device user_agent=”Nokia7110/1.0 (04.69)” fall_back=”nokia_7110_ver1″ id=”nokia_7110_ver1_sub469″ />
<device user_agent=”Nokia7110/1.0 (04.94)” fall_back=”nokia_7110_ver1″ id=”nokia_7110_ver1_sub494″ />
<!– 7110 new-age –>
<device user_agent=”Nokia7110/1.0 (05″ fall_back=”nokia_7110_ver1″ id=”nokia_7110_ver2″> <group id=”ui”>
<capability name=”table_support” value=”true” />
</group>
</device>
<device user_agent=”Nokia7110/1.0 (05.00)” fall_back=”nokia_7110_ver2″ id=”nokia_7110_ver1_sub500″ />
<device user_agent=”Nokia7110/1.0 (05.01)” fall_back=”nokia_7110_ver2″ id=”nokia_7110_ver1_sub501″ />

Tomando en cuenta de nuevo el soporte de tablas, el código anterior se lee como “hay una familia de teléfonos de 7110 para la cual las tablas no son soportadas y hay una familia para la cual si son soportadas”, Todos los modelos 7110 están en la lista anterior, pero cada uno hereda de una u otra subfamilia, con esto se puede conocer si un dispositivo soporta tablas o no.

WURFL trabaja por medio de API’s (java y php) y genera un cache para hacer mas rápido las consultas (el archivo XML pesa más de 15MB), por lo que cuando se instala y se ejecuta por primera vez tarda tiempo dependiendo del servidor pero ya las siguientes veces corre considerablemente mas rapido el cache puede ser por medio del sistema de archivos, Memcache, APC, EAccelerator y RDBMS y se especifica el método por medio del archivo de configuración de WURFL (WURFL-config.xml)

Para mas información de como descargar e instalar el api de php hay que visitar esta liga: http://WURFL.sourceforge.net/nphp/
Para descargar el archivo XML visitar esta liga: http://sourceforge.net/projects/WURFL/files/WURFL/

Una vez instalada la api (php), solo se necesita una manera eficiente para leer la información y usarla en las aplicaciones móviles para personalizarlas dinámicamente de acuerdo a las capacidades que soporte los dispositivos y estar al pendiente de actualizar el archivo XML para soportar los nuevos dispositivos que vayan entrando al mercado, el código básico php para utilizarla es:

<?php
$WURFLconfig = ‘/ruta_donde_esta_el_archivo/de_configuracion/WURFL-config.xml’;
$WURFLmanager = WURFL_WURFLManagerProvider::getWURFLManager($WURFLconfig);
$device = $WURFLmanager->getDeviceForHttpRequest($_SERVER);
?>

En el código anterior la primer línea especifica la ruta en donde se encuentra el archivo de configuración, en la segunda se instancia el manejador WURFL que es la interfaz que se usa para hacer las operaciones como crear instancia del dispositivo por medio de una petición HTTP o una cadena de agente de usuario, y en la tercera se instancia la variable $device que regresa un arreglo que contiene una gran cantidad de información acerca del dispositivo por ejemplo:

Array (
[resolution_width] => 770
[resolution_height] => 300
[rows] => 30
[columns] => 77
[max_image_width] => 600
[max_image_height] => 600]
[wbmp] => false
[bmp] => true
[epoc_bmp] => false
[gif] => true
[gif_animated] => true
[jpg] => true
[png] => true
[tiff] => false
[flash_lite] => false
:
)

Para ver completo los valores del arreglo visitar http://WURFLapi.pointbeing.net/

Por otro lado Tera-WURFL es una librería basada en PHP y MySQL que usa usa los datos del archivo XML WURFL y los pone en la base de datos MYSQL para identificar las capacidades de dispositivos móviles, la librería encapsula las consultas a la base de datos y provee una interfaz simple orientada a objetos de los datos además provee una interfaz para obtener la ultima versión del archivo XML de WURFL de sourceforge e importarla a la base de datos.

Una de las principales ventajas sobre WURFL es el rendimiento, normalmente entre 5 y 10 veces mas rápido, como la generación del objeto implica varias consultas, Tera-WURFL guarda el resultado como una cadena serializada en en una tabla dedicada, lo que significa que las siguientes peticiones del mismo agente de usuario es reducida a una sola consulta de esa tabla a la llave primaria (que es el agente de usuario), esto combinado con el cache mismo de MySQL, hace que sea mucho más rápido al ahorrarse muchas las consultas.

El código básico php para utilizarla es:

<?php
require_once ‘/ruta_donde_esta_el_archivo/tera_WURFL/tera_WURFL.php’;
$device = new Tera_WURFL();
$device->getDeviceCapabilitiesFromAgent($_SERVER[‘HTTP_USER_AGENT’]);
?>

En la primer línea se especifica donde está el archivo tera_WURFL.php que es necesario, en la segunda se instancia la clase para poder usar tera-WURFL y en la tercera se obtiene las capacidades del agente de usuario (en caso de no encontrar ese agente de usuario busca en la cabecera HTTP-ACCEPT), en un arreglo que contiene la información acerca del dispositivo, la diferencia con el API de WURFL radica en que el arreglo de Tera-WURFL es multidimensional mientras que el de WURFL API es unidimensional, la librería requiere que pasemos $_SERVER[‘HTTP_USER_AGENT’] como parámetro para el método getDeviceForHttpRequest(), esto es la cabecera de HTTP de agente de usuario basada en la cual las consultas de Tera-WURFL usarán como parámetro en la base de datos para obtener los detalles del dispositivo a diferencia de la API de WURFL que pasa $_SERVER la cual contiene todas las cabeceras de petición del protocolo HTTP.

Para ver un ejemplo del arreglo completo visitar: http://tw.pointbeing.net/

Un ejemplo para detectar si el visitante es un usuario móvil y redirigirlo sería:

<?php
require_once ‘/ruta_donde_esta_el_archivo/tera_WURFL/tera_WURFL.php’;
$wurflObj = new Tera_WURFL();
$wurflObj->getDeviceCapabilitiesFromAgent($_SERVER[‘HTTP_USER_AGENT’]);
if ($wurflObj->getDeviceCapability(“is_wireless_device”)) //detectar si es un usuario movil
header(“Location: http://www.sitioweb.com/movil/&#8221;)//redireccionar
?>

Para descargar tera-WURFL: http://www.tera-wurfl.com/wiki/index.php/Downloads

Un problema de usar la cabecera de agente de usuario como parámetro (HTTP_USER_AGENT) es que algunos operadores cambian el agente de usuario y lo reemplazan con alguna cadena genérica, por ejemplo un usuario de Blackberry puede cambiar en las configuraciones del navegador la identificación de navegador con el que quiere navegar (BlackBerry, Firefox, Internet Explorer) por lo que si lo cambia de su modo normal (Blackberry) no se van a servir las paginas adecuadamente, otro ejemplo es Opera mini que envía su propia cabecera user-agent la cual no especifica los detalles del dispositivo en el cual está corriendo y genera otra cabecera (HTTP_X_OPERAMINI_PHONE_UA) en donde especifica el agente de usuario original, para ver un poco mas sobre esto visitar este link http://www.tera-wurfl.com/Tera-Wurfl_Doc/TeraWurfl/WurflSupport.html

Fuentes:

Pagina principal de WURFL: http://wurfl.sourceforge.net/

Grupo de Facebook de WURFL http://www.facebook.com/group.php?gid=91445168918

Grupo de Yahoo de WURFL http://tech.groups.yahoo.com/group/wmlprogramming/

Página principal de tera-WURFL: http://www.tera-wurfl.com/wiki/index.php/

Introducción a tera-WURFL: http://pointbeing.net/weblog/2008/03/introduction-to-tera-wurfl.html

WURFL Api: http://pointbeing.net/weblog/2009/04/a-first-look-at-the-new-wurfl-api-for-php.html

Otras ligas relacionadas:

Artículo sobre Detección de navegadores: http://www.jibbering.com/faq/notes/detect-browser/

Open Mobile Alliance http://www.openmobilealliance.org/

Opera Mini request headers http://dev.opera.com/articles/view/opera-mini-request-headers/

Tips a tomar en cuenta para diseñar aplicaciones móviles: http://labs.thesedays.com/2010/07/16/10-tips-for-designing-mobile-websites/

Ligas para desarrollo orientado a iPhone http://www.juan-anzaldo.com/2010/iphone/iphoneDev.html

WALL for PHP http://wall.laacz.lv/

Para usar tera-WURFL sin necesidad de instalarlo: http://wurfl.thesedays.com/

A %d blogueros les gusta esto: