• Artículo

Este artículo proviene de un motor de traducción automática.

Exploración móvil

Genere una mejor experiencia en exploración móvil

Steven Sanderson

¿Quién tiene acceso a la Web a través de un dispositivo móvil estos días? En 2005, habría representado el usuario promedio de Internet móvil como un occidental geeky, Rico, probablemente un desarrollador de software, que llevaría a la hora de conectar su celular voluminoso a una red de datos lenta para soportar una experiencia de navegación dolorosamente limitada — y pagar top de dólares por el privilegio. En otras palabras, un caso de borde.

Ahora acceso Web móvil se ha disparado en la corriente mundial. Y digo no solo los adolescentes, estudiantes y ex amigos entre sí mostrando sus dispositivos smartphone y tablet en cada tienda de café en Europa y América del Norte. Hoy en día hay alrededor de 1 millones suscripciones activas de banda ancha móviles, basta con que uno de cada siete personas en el planeta (y sólo dos en siete utilizan regularmente Internet por cualquier medio). Dispositivos móviles van camino de ser la manera más común de acceso a la Web dentro de cinco años. Ya, en algunos de los países de más rápido crecimiento, especialmente India, móviles son la única forma de que muchas personas a obtener en línea. Incluso en Estados Unidos, 25 por ciento de los usuarios de Web móviles decir que "nunca" o "frecuentemente" acceden a la Web usando un PC tradicional. (Para fuentes de información, consulte "Acceso Web móvil.")

Claramente, si crea un sitio Web público, debe pensar en apoyar los navegadores móviles.

¿Por qué la navegación móvil es diferente

Como ustedes saben, casi cada explorador móvil admite algún tipo de HTML. Muchos, especialmente en los dispositivos high-end, como iPhones y Windows Phone 7, compatibles con los estándares más recientes de HTML, CSS y JavaScript y hacen copias pixelada perfecta de lo que se ve en un navegador de PC tradicional.

La opción más barata para soportar los navegadores móviles, entonces, es no hacer nada. Sólo puede servir a las mismas páginas orientadas en el escritorio para todos los dispositivos y confiar en los exploradores móviles para manejarlos. Pero elegir esta opción lleva a una muy mala experiencia de navegación móvil, por varias razones:

  • Pantallas de teléfono móvil son pequeñas. Algunos exploradores móviles, como Opera Mini, controlen escritorio ancho páginas dinámicamente a formatear el diseño de página y estilos. Rara vez el aspecto resultante es lo que el diseñador tenía en mente. Otros navegadores móviles, como Safari para iPhone o Internet Explorer para Windows Phone 7, representan las páginas de ancho de escritorio y, a continuación, obligan al usuario a acercar y alejar y pan alrededor de leer el texto. Esta es una prueba de paciencia de los visitantes.
  • Redes de datos móviles a menudo son lentas. No suponga que los visitantes tengan el mismo ancho de banda como usuarios de banda ancha fijos. Incluso puede estar pagando por megabyte, por lo sitios de peso pesado no será populares.
  • Dispositivos móviles a menudo no tienen un teclado o ratón. Mecanismos de interacción del usuario desktop-familiar no siempre tienen sentido en dispositivos móviles. Por ejemplo, haciendo clic en vínculos pequeños o botones puede ser difícil y propensas a errores en dispositivos de toque, y el concepto de "rondando" incluso puede no existir.

Así, si desea proporcionar una excelente experiencia de navegación móvil, que es el momento para aplicar sus conocimientos de ingeniería y las diferencias entre los tipos de dispositivos principales.

Soporte móvil en ASP.NET

Hay dos aspectos principales a apoyar a los exploradores móviles:

  1. Detectar qué tipo de dispositivo que está utilizando un determinado visitante. ASP.NET dispone de compatibilidad integrada para la detección de navegador. En la siguiente sección lo examino este mecanismo, y cómo puede personalizar y ampliar.
  2. La producción de salida que funciona correctamente en el dispositivo detectado. Si digitaliza a través de la anterior lista de desafíos, obtendrá que estas no son las cosas que puede manejar automáticamente su tecnología 
platform. Apoyo móvil es principalmente una cuestión de diseño de la experiencia (UX) de usuario, no principalmente una cuestión de marca. Más adelante en este artículo describiré los medios técnicos para producir diferentes salidas para diferentes dispositivos, pero es todavía de usted para diseñar e implementar diferentes diseños y flujos de trabajo de usuario para móviles.

Tenga en cuenta que alrededor de ASP.NET 2.0, lanzado en 2005, producción de salida para trabajar en dispositivos móviles es una cuestión de marcado, porque utilizan dispositivos comunes en ese momento especialista protocolos y lenguajes de marcado, WAP, WML y cHTML. ASP.NET 2.0 figuran "Controles móviles" para apoyar esos formatos. Sin embargo, esos formatos ahora son completamente obsoletos, porque todos los principales navegadores ahora utilizan HTML, por lo que el ASP.Controles de red móviles también son obsoletos.

Detección de navegador

El núcleo ASP.Plataforma NET, que es la base de formularios Web Forms y modelo vista controlador (MVC), tiene soporte incorporado para la detección de explorador. Puede averiguar si un visitante es utilizando un explorador móvil mediante la propiedad Request.Browser.IsMobileDevice Boolean. Sin embargo, debe saber cómo funciona esta detección a ser conscientes de las limitaciones de precisión que pueden afectarle.

ASP.NET determina qué tipo de navegador hace una solicitud y qué capacidades ese navegador tiene (tamaño de pantalla, compatible con JavaScript, etc.) mediante la comparación de la cadena de encabezado de userAgent solicitud entrante contra una serie de expresiones regulares en los archivos XML que describen los navegadores comunes.

Estas expresiones regulares e información sobre las capacidades del dispositivo correspondiente, se almacenan en un conjunto de archivos .browser de la carpeta C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config\Browsers (o el equivalente de la instalación). Por ejemplo, el archivo iphone.browser estándar incluye el código mostrado en figura 1.

Figura 1 el archivo iphone.browser

<browsers>
  <!-- Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ 
       (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3 -->
  <gateway id="IPhone" parentID="Safari">
    <identification>
      <userAgent match="iPhone" />
    </identification>
    <capabilities>
      <capability name="mobileDeviceModel" value="IPhone" />
      <capability name="mobileDeviceManufacturer" value="Apple" />
      <capability name="isMobileDevice" value="true" />
      <capability name="canInitiateVoiceCall" value="true" />
    </capabilities>
  </gateway>
  ...
</browsers>

En el archivo, el siguiente elemento define la expresión regular que se compara con cadenas de encabezado userAgent entrantes:

<userAgent match="iPhone" />

Una vez que el sistema encuentra una expresión regular de userAgent coincidente, el resto de los datos XML especifica el tipo y las capacidades de ese dispositivo.

La limitación de este sistema es clara: sólo puede detectar dispositivos móviles que se han conocido y descrito en estos archivos al ASP.NET 4.0 fue lanzada. Lamentablemente, esto no incluye los navegadores modernos comunes tales como Opera Mobile o el explorador predeterminado para Google Android. Request.Browser.IsMobileDevice incorrectamente se establecerá en false para los exploradores.

Personalizar y mejorar la detección de navegador

Tienes dos opciones principales para superar las limitaciones de la instalación de detección de explorador predeterminado:

  1. Puede proporcionar sus propios archivos .browser para representar los dispositivos más recientes.
  2. Puede utilizar una biblioteca de detección de explorador de terceros.

Para tomar la primera opción, haga clic en el nombre del proyecto en el explorador de soluciones de Visual Studio y seleccione Agregar | Agregar ASP.Carpeta de NET | App_Browsers. A continuación, puede agregar archivos .browser a esa carpeta; por ejemplo, al copiar un archivo existente de la carpeta C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config\Browsers y, a continuación, editar su identificación regular expression y dispositivo capacidad descripción para representar el navegador deseado.

Si no desea ser responsable de seguimiento todos los centenares de recién lanzado exploradores móviles y mantener los archivos .browser actualizado, puede tomar la segunda opción y usar una biblioteca de detección de explorador de terceros.

Actualmente, la que recomiendo es 51degrees.Mobi Foundation, una biblioteca de código abierto (licencia MPL) alojada en CodePlex en 51degrees.codeplex.com. Esta biblioteca no utiliza archivos .browser. En su lugar, identifica los dispositivos emparejando les contra la base de datos del archivo de recurso Universal Wireless (opinion), que puede ser aplicaciones gratis utilizadas de forma gratuita en tanto comerciales y no comerciales. Para obtener más información acerca de WURFL, consulte wurfl.sourceforge.net.

La forma más sencilla de instalar 51degrees.Fundación mobi en proyectos de formularios Web Forms o MVC es utilizando el administrador de paquetes de NuGet. Si ejecuta ASP.NET MVC 3, ya tiene NuGet. Si no es así, puede utilizar Visual Studio Extension Manager (es en el menú Herramientas) para buscar e instalar NuGet. Una vez NuGet, vaya a herramientas | Administrador de paquetes de biblioteca | Consola del administrador de paquetes y, a continuación, ejecute el siguiente comando en la consola:

Paquete de instalación 51Degrees.mobi

Esto se agrega al proyecto:

  • Una copia reciente de la base de datos WURFL para su proyecto en /App_Data/wurfl.xml.gz
  • Una referencia a FiftyOne.Foundation.dll, ensamblado principal de la biblioteca
  • Entradas de Web.config para habilitar 51degrees.Fundación mobi

51degrees.Fundación mobi se conecta a y mejora el ASP.NET Request.Browser estándar API. Sólo por tener instalado el paquete, obtendrá resultados más precisos de Request.Browser.IsMobileDevice, porque las versiones recientes de la base de datos WURFL pueden detectar exploradores móviles común de hoy, incluyendo la Opera Mobile y el navegador de Google Android.

Tenga en cuenta que la 51degrees por defecto.Configuración de Web.config de Fundación mobi también configura todas las peticiones de los navegadores móviles a la dirección URL ~ / Mobile/Default.aspx. En muchos casos — y especialmente para ASP.Aplicaciones NET MVC — que no será el comportamiento que desee. Puede desactivar el redireccionamiento comentando out o eliminar el <redirect/> elemento que el paquete se agrega al archivo Web.config y, a continuación, también puede eliminar el archivo /Mobile/Default.aspx si desea.

Diseño para móviles

Ahora que tiene una idea de cómo detectar navegadores de teléfono móvil de forma fiable, te voy a mostrar una forma clave para controlar cómo se representan las páginas por los exploradores móviles. Después de eso, describiré algunas opciones de arquitectura para variar el marcado representado por tipo de dispositivo.

Muchos navegadores móviles modernos, incluyendo Safari para iOS y Internet Explorer para Windows Phone 7, intentan hacer procesado páginas mirada como se hace en un explorador de escritorio. Ellos saben que la mayoría de las páginas está diseñada para pantallas alrededor de 1.000 píxeles de ancho y el diseñador más probable es que no cuenta mucho menor ancho.

Para resolver esto, suelen procesar la página en un lienzo virtual conocido como una "ventanilla", generalmente alrededor de 1.000 virtuales píxeles de ancho. El explorador puede luego escalar la presentación visual de ese lienzo virtual arbitrariamente, pudiendo acercar y alejar y pan alrededor. Este arreglo se ilustra en la figura 2.

A Mobile Browser Rendering a Desktop-Width Page onto a Virtual Viewport

Figura 2 explorador móvil a procesar una página de ancho de escritorio en un punto de visión Virtual

Esto permite la página representar como el diseñador destinado, sufre la desventaja de usabilidad importantes que cuando el usuario se acerca lo suficiente para leer el texto, no puede ver el ancho completo de la página y debe desplazarse horizontalmente para hacerlo.

Controlar el ancho del área de visualización

Si realmente ha diseñado páginas para la pequeña pantalla, que no desea que ser establecidos en un punto de visión virtual alrededor de 1.000 píxeles de ancho. En cambio, le gustará a sus páginas a ser establecidos en un punto de visión que es el mismo ancho que la pantalla actual, para que ajuste perfectamente horizontal con ningún zoom necesario.

Muchos de los navegadores más populares de móviles apoyan una etiqueta meta no estándar "punto de visión" que le permite controlar el ancho del área de visualización virtual. Por ejemplo, si agrega la siguiente a la página <head> sección, el navegador sentará la página en un punto de visión 320 píxeles de ancho:

    <meta name="viewport" content="width=320"/>

Suele ser un mucho mejor ajuste para teléfonos móviles.

Tenga en cuenta que algunos dispositivos móviles tienen pantallas con mayor resolución horizontal. Por ejemplo, el iPhone 4 tiene 640 píxeles físicos por fila. Sin embargo, todavía tiene sentido usar un punto de visión virtual de alrededor de 320 píxeles; de lo contrario, el texto resultante será demasiado pequeño para leer sin acercar.

Si lo desea, puede hacer que el punto de visión virtual varían en tamaño de acuerdo con el dispositivo utilizado, utilizando la sintaxis siguiente:

    <meta name="viewport" content="width=device-width"/>

Tenga en cuenta que algunos dispositivos móviles no dan una anchura de dispositivo literal. Interpretan "ancho del dispositivo" en el sentido de "el ancho de la ventanilla virtual que piensa que el fabricante da el resultado más agradable". Así, por ejemplo, iPhone 4 define ancho dispositivo como 320 píxeles, a pesar de su mayor resolución física.

Recomendaciones de marcado

Cuando esté diseñando páginas para navegadores de teléfono móvil:

  • Utilice la etiqueta meta de ventanilla para ajustar el punto de visión el ancho horizontal de la pantalla.
  • Ajuste sus diseños de página, estilos CSS y similares para tener en cuenta este ancho estrecho. Si los visitantes no necesitan zoom o desplazarse horizontalmente, la página siente más como una aplicación nativa para su dispositivo: una experiencia mucho mejor.
  • Asegúrese de que sus enlaces y botones son lo suficientemente grandes como para ser aprovechado impreciso. Alcance es mucho más grandes que la punta del puntero del mouse.
  • Minimiza los requerimientos de ancho de banda al no utilizar imágenes de alta resolución o archivos de JavaScript masivos.

Opciones de arquitectura

Ha visto cómo detectar navegadores de teléfono móvil, y he proporcionado algunas recomendaciones para el marcado que mejor les convenga. Ahora describiré tres opciones sencillas para estructurar la aplicación para producir diferentes tipos de explorador diferente:

  1. Mostrar y ocultar secciones de marca de acuerdo con el tipo de navegador.
  2. Cambiar las páginas principales de acuerdo al tipo de navegador.
  3. Presentación de contenido totalmente diferente según tipo de navegador.

Cada una de ellas tiene sus ventajas y limitaciones, por lo que es a usted a elegir un enfoque que se adapte a sus necesidades.

Mostrar y ocultar marcas

Si sólo necesita incluir o excluir etiquetas meta y referencias de archivo CSS segun el tipo de navegador, esto es extremadamente simple. Por ejemplo, en una página maestra de formularios Web Forms, puede agregar una instrucción "if" dentro de su <head> Sección:

    <head runat="server">
      <title>My site</title>
      <link href="~/Styles/Site.css" rel="stylesheet" type="text/css" />
    
      <% if (Request.Browser.IsMobileDevice) { %>
        <meta name="viewport" content="width=device-width"/>
        <link href="~/Styles/MobileSite.css" rel="stylesheet" type="text/css" />
      <% } %>
    </head>

El equivalente de un diseño de afeitar para una aplicación ASP.NET MVC 3 aplicación tiene el siguiente aspecto:

    <head>
      <title>@ViewBag.Title</title>
      <link href="@Url.Content(
        "~/Content/Site.css")" rel="stylesheet" type="text/css" />
      @if (Request.Browser.IsMobileDevice) {
        <meta name="viewport" content="width=device-width"/>
        <link href="@Url.Content(
          "~/Styles/MobileSite.css")" rel="stylesheet" type="text/css" />
        }
    </head>

Esta es una técnica muy básica, pero puede ser adecuada si se puede adaptar el código existente para adaptarse a la pequeña pantalla puramente agregando reglas adicionales de CSS en un archivo independiente de MobileStyles.css. Por supuesto, puede utilizar el mismo mecanismo en sus páginas maestras y vistas para modificar la salida por el tipo de navegador.

Esta técnica funciona mejor si se está creando un nuevo sitio Web y puede diseñar su marca para que se adapte a las pantallas móviles y de escritorio dependiendo sólo de la CSS utilizado. En ese caso, el esfuerzo de desarrollo adicionales es muy bajo. Para muchos sitios esta técnica simple no será suficiente, pero hay dos alternativas: la página principal de conmutación o presentar contenido diferente.

Páginas principales de conmutación

Puede mantener sus páginas de contenido existentes sin cambios y simplemente adaptar el diseño para la pequeña pantalla con una página maestra diferente o diseño. Por ejemplo, si crea una aplicación de formularios Web Forms, puede definir una clase base de página estándar que cambia dinámicamente la página principal:

public class PageBase : Page
    {
      protected override void OnPreInit(EventArgs e)
      {
        if (Request.Browser.IsMobileDevice)
            MasterPageFile = "~/Mobile.Master";
      }
    }

A continuación, para cualquier página cuyo diseño debe varían según el tipo de dispositivo, establezca su clase de código subyacente para heredar de PageBase en lugar de la habitual System.Web.UI.Page. Se puede crear una página principal en /Mobile.Master cuyo diseño y CSS de estilo están optimizados para móviles devicess.

Es más fácil para ASP.NET MVC 3 desarrolladores mediante diseños de afeitar — hacer a todas las composiciones de conmutador vistas dinámicamente editando el archivo /Views/Shared/_Layout.cshtml para contener los datos siguientes:

@{
  Layout = Request.Browser.IsMobileDevice 
             ? "
~/Views/Shared/_MobileLayout.cshtml"
             : "~/Views/Shared/_Layout.cshtml";
}

A continuación, agregar un nuevo archivo de diseño de navaja en /Views/Shared/_MobileLayout.cshtml y modificar su estructura y estilos CSS para el dispositivo móvil como desee.

Esto da más flexibilidad que la técnica anterior de variación de CSS y segmentos de ocasionales marcado por sí solo, pero todavía tiene la limitación que tanto páginas de escritorio y móviles deben mostrar esencialmente la misma información y utilizar los mismos mecanismos de interacción.

Presentación de contenido diferente

Para algunas aplicaciones, no podrá adaptar sus páginas desktop para dispositivos móviles simplemente usar CSS diferente o páginas maestras y diseños porque:

  • Requerimientos de su negocio podrían ser demasiado exigente. Si desea una experiencia móvil verdaderamente slick, puede que necesite mostrar diferente (quizás menos) información para dispositivos móviles y posiblemente guía al usuario a través de diferentes flujos de trabajo. Por ejemplo, el proceso de registro de usuario puede tener menos pasos y recoger menos información para los visitantes móviles. Esto es más que una cuestión de CSS.
  • Usted puede trabajar con código heredado que no es susceptible de cambio. Por ejemplo, el código existente puede contener estilos y tamaños de elemento codificados. Esta modificación mediante CSS o una página maestra diferente podría ser imposible o podría hacer las cosas más complicadas y menos fácil de mantener.

En cualquier caso, la solución es utilizar lógica completamente separada y marcado para distintos tipos de dispositivos. El inconveniente es que, a continuación, tiene dos versiones para mantener, pero el beneficio clave es que el comportamiento de los dos puede variar de forma independiente en cualquier forma que desee. Para los desarrolladores de formularios Web Forms, la aplicación generalmente es un conjunto de páginas ASPX de móviles específicos y para los desarrolladores MVC, normalmente significa crear una nueva área de vistas y controladores específicos de mobile. En cualquier caso, necesitará cierta lógica para redirigir los visitantes a la página correcta según el tipo de dispositivo.

Para mostrar formas de implementar la lógica de redirección de una manera que sea compatible con ambos caché y forma de autenticación de formularios Web Forms y MVC muestras de código, consulte el documento en bit.ly/gHT3Ap.

Conclusiones y recomendaciones finales

En este artículo, que ha aprendido acerca de:

  • ¿Por qué exploradores móviles son cada vez más importantes.
  • ¿Por qué gran apoyo móvil es principalmente una cuestión de diseño UX, marcado no sólo diferente.
  • ¿Cómo el núcleo ASP.Plataforma NET detecta exploradores móviles por defecto.
  • Cómo el enfoque de detección de navegador predeterminado es limitado, y cómo se puede ampliar o reemplazarlo.
  • Cómo móviles navegadores Mostrar escritorio tamaño páginas en pantallas pequeñas, y cómo puede influir.
  • Opciones de arquitectura para enviar salidas diferentes tipos de explorador diferente.

Al seleccionar una combinación de técnicas que mejor se adapten a su aplicación y los usuarios finales, son mis recomendaciones principales priorizarusabilidad y prueba. No tiene sentido aplicar soporte móvil si termina dando a los usuarios un peor experiencia de navegación! Aquí están algunas cosas a tener en cuenta:

Usuarios móviles ofrecen una forma de cambiar a la vista de escritorio normal. Normalmente, esto significa colocar un vínculo en la parte superior de las páginas diciendo "Cambiar a la vista del escritorio." La forma que se aplica el conmutador depende de su arquitectura; simplemente puede vincular a la versión de escritorio de una dirección URL determinada, o puede establecer una cookie que reemplaza su mecanismo de detección de navegador normal.

Este servicio es especialmente importante si las páginas móviles mostrarán menos información que las páginas de escritorio, porque los usuarios avanzados será frustrados si no pueden acceder a información o características que saben que deben estar ahí.

No perder información al redireccionar a una vista móvil. En algunos sitios Web, visitantes móviles entrantes se redirigen a la página principal móvil, sin importar qué página solicitan. Esto es enormemente frustrante para los usuarios y esencialmente rompe casi cada enlace entrante. Si no tienes una versión móvil de la página solicitada, sólo mostrar la versión de escritorio de la misma.

Validar la implementación utilizando dispositivos reales o emuladores. Las composiciones de mobile-friendly, CSS y meta tags no pueden manejarse como esperar por todos los dispositivos. Se debe probar en dispositivos reales o emuladores. Para una lista de emuladores de dispositivos móviles populares, consulte asp.net/mobile/device-simulators.

Está bien para iniciar pequeñas. No tiene que crear una versión móvil optimizada de cada página y su función en el sitio todo a la vez. Para muchas empresas, la mayoría del valor vendrá de tener una página Web móvil habilitado y quizás algunos otros flujos de clave de usuario trabajo tales como el registro y la navegación por el catálogo.

Para algunas aplicaciones de intranet, nunca puede ser relevante soportar los dispositivos móviles. Pero para cualquier sitio público de Internet, seguramente necesitará considerar exploradores móviles si estás siguen siendo pertinentes en los próximos años.

Nota: Como alternativa a la 51degrees.Fundación mobi, otra opción para utilizar datos de opinion en ASP.NET es a través de la opinion oficial.API de red, disponible en http://wurfl.sourceforge.net/dotNet y en NuGet como un paquete llamado "wurfl_official_api".

Que la API está disponible bajo licencias comerciales y AGPL (véase http://www.scientiamobile.com).

Steven Sanderson trabaja para Microsoft como administrador de programas en el equipo que le ofrece ASP.NET MVC, formularios Web Forms, NuGet y otros bondad relacionadas con la Web.

Gracias a los siguiente experto técnico para revisar este artículo: Scott Hunter