Vanguardia

2015-08-04

Movilización de un sitio web existente

Dino Esposito Se trata de una situación común. Llega a un hotel, a un aeropuerto o a otro espacio público. Se conecta a la red inalámbrica local y se lo envía a una página de inicio de sesión para que introduzca sus credenciales. La página de inicio de sesión de su dispositivo móvil es diminuta. Simplemente puede pellizcar para acercar la pantalla, llevar el formulario de entrada a un tamaño razonable y escribir sus credenciales.

Esta es una experiencia molesta; sin embargo sucede con mucha frecuencia. Y no se trata simplemente de una molestia. El futuro de los sitios web que no se visualizan bien en todos los dispositivos es nefasto. No ofrecer a los usuarios móviles una buena experiencia puede dar reducir los beneficios comerciales al alejar a los usuarios del sitio y acercarlos al de los competidores.

La varita mágica a la que recurren muchos desarrolladores para hechizar la web es el diseño web dinámico (RWD, por sus siglas en inglés). El RWD es definitivamente una opción, pero al igual que el resto, tienen sus pros y sus contras. El problema con el RWD es, en su mayor parte, que requiere un proyecto nuevo.

El concepto básico de RWD es que todo es fluido. Ningún elemento será más ancho que la pantalla. Por lo tanto, por definición, el diseño web dinámico se adapta a una cantidad infinita de anchos de pantalla. El objetivo de RWD es crear un nuevo sitio web inspirado en una nueva idea de contenido y abordar una cantidad fija y más pequeña de puntos de interrupción. La inserción de RWD o de una biblioteca como Twitter Bootstrap en un sitio web existente diseñado para el escritorio es una opción poco viable.

Además, vender el enfoque RWD es muy fácil. Hay un sitio, una marca y una base de código que funciona con varias IU. Implementar RWD es menos sencillo y cambia la experiencia de desarrollo web. Se necesita una visión clara y sólida sobre la forma en que el sitio presentará la información. RWD puede ser fácil de vender, pero no admite improvisación. La adaptación de contenido no es mágica. Proviene de una planificación cuidadosa y diligente.

RWD también cambia las reglas consolidadas de gestión de proyectos y generalmente termina costando más que el desarrollo de un sitio común no dinámico. El seguimiento del proceso de los diagramas de Gantt tienen poco sentido ya que todo paso nuevo requiere que los miembros del equipo midan los efectos en el espectro completo de vistas compatibles. A fin de cuentas, cuando contar con un sitio web más dinámico no es una opción, ¿qué puede hacer para satisfacer las expectativas delos clientes y hacerles la vida más fácil?

Agregar un sitio móvil conectado

Si su sitio web ayuda a la empresa a mantener los negocios y juega un papel fundamental en atraer, mantener y atender a los clientes, entonces ofrecer una experiencia específica móvil es fundamental para lograr que esos clientes regresen. El enfoque más simple que no requiere reescribir todo el sitio y no alterará ninguna de las características existentes, es crear un sitio aparte específico para la audiencia móvil. A este enfoque se lo denomina como construcción de un sitio m.

Un sitio m, al igual que una aplicación nativa, probablemente formen parte del consumo de usuarios que viajan, personas que se encuentran activas, apuradas, ocupadas, o esperando en línea. Los usuarios que desean conectarse a un sitio bajo estas condiciones y usar un dispositivo diminuto realmente esperan obtener algunos beneficios del sitio. Por lo tanto, el sitio debe ser directo, conciso, preciso y debe ser rápido a la hora de cargarse y de responder.

Adoptar el enfoque del sitio m puede ser poco económico por dos motivos. Se trata de un proyecto nuevo, pero se espera que herede los principales servicios del sitio existente. Con mucha frecuencia, hereda grandes cantidades de lógica comercial, lo que no significa que duplica la base de código. Por otra parte, un sitio m implementa la regla 80/20. Generalmente no admite más del 20% de las características disponibles en el sitio completo. Sin embargo, la selección del 20% de las características no es una tarea fácil de realizar.

Al planificar un sitio m, se debe tener en cuenta al usuario itinerante del sitio. ¿Qué información realmente espera consumir del sitio un usuario itinerante? ¿Qué funciones espera ejecutar el usuario? ¿Qué puede hacer para facilitar y agilizar la interacción en la medida de lo posible? Este último punto implica usar al máximo las características de HTML5.

En un sitio que se sabe se utilizará en dispositivos móviles, es difícil no establecer el tipo de atributo de un elemento de entrada en un número o fecha, si se esperan números o fechas. Esto simplificaría enormemente la escritura. Con el mismo token, es posible que se introduzcan nuevos casos de uso además de la lógica comercial similar para facilitarle la vida a los usuarios móviles y hacérselas más agradable.

Acceso a su sitio m

Dado que un sitio m es un sitio web discreto, ¿qué URL deben usar los visitantes? ¿Es un subdominio del tipo m.suservidor.com la mejor opción? ¿Funcionaría mejor un nombre de dominio de nivel superior .mobi o un subdirectorio /mobile en el equipo de escritorio? Un subdominio m. es más fácil de administrar que un dominio .mobi, simplemente proque se trata de un subdominio y no de un nombre de dominio nuevo. Un directorio es probablemente más propenso a errores, ya que significa que el sitio móvil se alojará bajo la misma aplicación que el escritorio. Esto puede hacer que toda la solución sea más precaria.

El enfoque más simple es usar un subdominio m. con alguna lógica de redireccionamiento que envíe a los usuarios móviles directamente al sitio m.suservidor.com. Esta solución es buena para los usuarios ya que pueden usar el subdominio m. y la URL canónica. Sin embargo, para los desarrolladores, presenta la desventaja de requerir la lógica de detección tanto en el escritorio como en el sitio móvil.

Implementación de redireccionamiento del sitio

Cuando hay dos sitios vigentes y funcionan bajo la misma URL, se debe procesar el nombre de host y decidir qué hacer para cada solicitud. Si el nombre de host pertenece al sitio del escritorio y se detecta que el explorador que realiza la solicitud es un explorador de escritorio, entonces todo funciona según lo previsto.

De lo contrario, el usuario debería ver una página de aterrizaje y se le debería informar que está tratando de acceder a un sitio de escritorio con un dispositivo móvil. Entonces, tendrán la oportunidad de guardar sus preferencias para situaciones similares en el futuro. Esa preferencia se almacena en una cookie que se comprueba luego. Si la solicitud hace referencia a una URL en el sitio móvil y el usuario parecer tener un explorador de escritorio, considere mostrar otra página de aterrizaje, o simplemente dejar que la solicitud se curse como siempre. Por último, si se realiza una solicitud desde un dispositivo móvil a un sitio móvil, todo funcionará según se espera. Puede hacer que su sitio busque entre las capacidades del dispositivo y determine cuál es la vista más apropiada. La Figura 1 presenta un diagrama del algoritmo.

Figura 1 El algoritmo de cambio de vista de escritorio/móvil

En ASP.NET puede implementar el algoritmo de enrutamiento como un módulo HTTP y registrarlo tanto en el sitio de escritorio como en el sitio móvil. El módulo captura el evento BeginRequest y utiliza un redireccionamiento simple o, si es posible, reescribe la URL para cambiar la página de destino, según corresponda, como se muestra en la Figura 2.

Figura 2 Implementación de un módulo HTTP de enrutador móvil

public class MobileRouter : IHttpModule
{
  private const String FullSiteModeCookie = "FullSiteMode";
  public void Dispose()
  {
  }
  public void Init(HttpApplication context)
  {
    context.BeginRequest += OnBeginRequest;
  }
  private static void OnBeginRequest(Object sender, EventArgs e)
  {
    var app = sender as HttpApplication;
    if (app == null)
      throw new ArgumentNullException("sender");
    var isMobileDevice = app.Context.Request.IsMobileDevice();
    // Mobile on desktop site, but FULL-SITE flag on the query string
    if (isMobileDevice && HasFullSiteFlag(app))
    {
      app.Response.AppendCookie(new HttpCookie(FullSiteModeCookie));
      return;
    }
    // Mobile on desktop site, but FULL-SITE cookie
    if (isMobileDevice && HasFullSiteCookie(app))
      return;
    // Mobile on desktop site => landing page
    if (isMobileDevice)
      ToMobileLandingPage(app);
  }
  private static Boolean HasFullSiteFlag(HttpApplication app)
  {
    var fullSiteFlag = app.Context.Request.QueryString["m"];
    if (!String.IsNullOrEmpty(fullSiteFlag))
      return String.Equals(fullSiteFlag, "f");
    return false;
  }
  private static Boolean HasFullSiteCookie(HttpApplication app)
  {
    var cookie = app.Context.Request.Cookies[FullSiteModeCookie];
    return cookie != null;
  }
  private static void ToMobileLandingPage(HttpApplication app)
  {
    var landingPage =
      ConfigurationManager.AppSettings["MobileLandingPage"];
    if (!String.IsNullOrEmpty(landingPage))
      app.Context.Response.Redirect(landingPage);
  }
}

Una vez instalado en el sitio de escritorio, este módulo HTTP captura todas las solicitudes y comprueba el explorador que realiza la solicitud. Si el explorador se está ejecutando dentro de un dispositivo móvil, el módulo redirecciona a la página de aterrizaje especificada. La página de aterrizaje será una página móvil optimizada que ofrece un par de enlaces al sitio de escritorio y al sitio móvil.

¿Dónde coloca la página de aterrizaje para que los usuarios móviles puedan decidir qué hacer? Generalmente no importa. Sin embargo, si la coloca en un sitio móvil, puede implementar el sitio móvil con toda la lógica de enrutamiento requerida sin tocar la base de código del sitio de escritorio. Los cambios en el sitio de escritorio se limitan a configurar el módulo HTTP en el archivo web.config.

¿Qué significa móvil realmente?

El mundo web móvil no se divide simplemente en dos campos, por un lado los equipos de escritorio y luego el resto. Móvil comprende smartphones y tabletas, como mínimo. Es posible que un sitio m destinado a smartphones no funcione eficazmente en tabletas y viceversa. Proveer páginas optimizadas para smartphones a tabletas va en contra de las expectativas comunes del usuario de obtener una experiencia similar a la de escritorio.

¿Se debería tener otro sitio t para tabletas y un sitio para dispositivos heredados y quizás uno para dispositivos portátiles? En general, los smartphones merecen una experiencia ad-hoc y un sitio dedicado. Las tabletas pueden representar tranquilamente el mismo contenido que los equipos de escritorio con ajustes menores, por ejemplo un conjunto diferente de archivos CSS con más margen y fuentes más grandes y cierta compatibilidad con las consultas de medios cuando la orientación cambia a horizontal o vertical. Estos ajustes requieren cambios en la base de código del sitio de escritorio existente. Sin embargo, no se trata de un cambio intrusivo.

El problema continúa siendo cómo detectar smartphones y qué definición de smartphone se ajusta a su escenario empresarial.

Herramienta de detección de dispositivos

No hay una definición común de un smartphone. Un smartphone no es un atributo físico como un número de versión de SO. Cuando los exploradores solicitan una página, envían la cadena del agente de usuario, lo que significa que cierto código del servidor debe procesar la cadena del agente de usuario y determinar si el dispositivo es una tableta, un smartphone u otro dispositivo.

La detección de dispositivos requiere herramientas de colaboración, que cuenta con variados niveles de fiabilidad y exactitud. Por ejemplo, puede usar algunos complementos Modernizr o rutinas comunes para comprobar subcadenas conocidas de los agentes de usuario. Esto puede funcionar de forma lo suficientemente confiable si todo lo que desea hacer es separar los equipos de escritorio del resto.

En este contexto, detectar algo como un SO de Android le indica al explorador que no se trata de un escritorio. Sin embargo, detectar Android no ayuda a determinar si se trata de un smartphone o una tableta. El marco WURFL (wurfl.sourceforge.net) es una opción popular con herramientas que funcionan localmente, en el nivel de nube e incluso en el nivel servidor web (no código, simplemente configuración) en ISS y otros entornos.

Si opta por construir un sitio m que tenga efecto sobre el contenido ad hoc de los usuarios móviles, debe ser claro en cuanto a qué dispositivos entran dentro de la jurisdicción del sitio m (al elegir entre smartphones, tabletas y más) y cómo detectar dispositivos, de modo que los usuarios cuenten con una sola URL para acceder al sitio, independientemente del dispositivo.

Resumen

Los usuarios esperan usar las páginas web sin problemas en sus smartphones y tabletas, al igual que lo hace en los equipos de escritorio. La capacidad de procesamiento o el tamaño de caché son limitados en los dispositivos móviles, pero eso no puede ser una excusa para ocuparse de las páginas que requieren zoom y que tardan segundos en cargarse. Separar el escritorio de todo lo demás no es una opción práctica tampoco. Se requiere cierto nivel de detección de dispositivos para brindar un buen servicio. Cuando se trata de la detección de dispositivos y de los factores de forma, crece la complejidad y aumentan los costos de desarrollo.

Muchas compañías creen que el RWD es el clásico huevo de Colón, una solución obviamente simple y brillante a un problema espinoso. Los sitios web dinámicos son más complejos y costos de crear que lo que se reconoce comúnmente. Lo que es más importante, un enfoque de RDW funciona en sitios nuevos o significativamente modificados. No puede simplemente agregar RWD para movilizar un sitio existente que fue creado para el escritorio. Sin embargo, abordar las necesidades del público móvil es una necesidad comercial. Y cuanto antes lo haga, mucho mejor.

Dino Esposito es el coautor de “Microsoft .NET: Architecting Applications for the Enterprise” (Microsoft Press, 2014) y “Programming ASP.NET MVC 5” (Microsoft Press, 2014). Esposito, evangelizador técnico para las plataformas Android y Microsoft .NET Framework en JetBrains, diserta con frecuencia en eventos del sector en todo el mundo, comparte su visión de software en software2cents.wordpress.com y en Twitter en twitter.com/despos.

Gracias al siguiente experto técnico por su ayuda en la revisión de este artículo: Jon Arne Saeteras

Compartir a través de