Los riesgos de la programación de los sitios con jQuery Mobile?

Question

El equipo de jQuery ha lanzado recientemente http://jquerymobile.com/ con la intención de crear una interfaz de usuario biblioteca para dispositivos móviles.

  

Nuestro objetivo es proporcionar herramientas para construir   interfaces táctiles dinámicas que voluntad   adaptarse con gracia a una gama de dispositivo   factores de forma. El sistema incluirá   ambos de disposiciones (listas, paneles de detalle,   superposiciones) y un rico conjunto de formulario   controles y widgets de interfaz de usuario (Alterna,   deslizadores, lengüetas).

En general, parece apoyo al marco es muy bajo porque la mayoría de los teléfonos se envían con navegadores de mierda. Mi pregunta, se divide en dos partes. ¿Es mejor para apoyar unos navegadores con una experiencia más rica o darle a tantos usuarios como sea posible una experiencia simplemente promedio? Esto es similar a la cuestión de apoyar IE porque la pregunta es ¿cuánto nos preocupamos por los usuarios con navegadores peores?

Más importante aún, ¿cuánto tiempo de desarrollo es lo que realmente vale la pena construir una versión móvil de un sitio que no es principalmente para el usuario móvil?

Answer 1

Bueno, es 1.0 Alpha 1, así que diría que los riesgos son:

1. Es ampliamente probada, por lo que probablemente se encuentra con errores desconocidos o no resueltas como a forjar un nuevo camino.
2. Existe un gran potencial para el cambio en una pronta liberación, por lo que puede que tenga que actualizar grandes franjas de su sitio, es decir. cuando los elementos de datos de espacio de nombres bajo "ui".

También es importante tener en cuenta el razonamiento detrás de esos grados:

  

¿Qué significan los grados medio? Los grados son una combinación de la calidad del navegador combinado con la relevancia del navegador en el mercado de telefonía móvil más grande.

Un grado "A" es una indicación de las características del navegador, no cualquier compatibilidad actual o futura con jQuery Mobile.

Si desea contribuir al desarrollo de una nueva pieza de software, comience a usar jQuery Mobile, y contribuir comentarios, informes de errores, código, o todo lo anterior. Si no, el equipo espera para ver una versión 1.0 en enero de 2011, que está a la vuelta de la esquina.

La teoría alrededor de jQuery Mobile está proporcionando una experiencia rica para navegadores ricos, y una experiencia funcional para los navegadores más básicos. Creo que esto es razonable, especialmente teniendo en cuenta la rapidez con jQuery Mobile se puede obtener en marcha con una muy buena interfaz de usuario móvil.

Me gustaría saber qué quiere decir con "un sitio que no es principalmente para el usuario móvil." Hay sitios que están optimizadas para móviles, y hay sitios que todavía no están optimizados para móviles. Sólo algunos sitios de nicho muy específicos no requieren una experiencia móvil.

Answer 2

Como seguimiento hasta Silvo, me gustaría añadir que la respuesta más útil a su pregunta requiere una comprensión de su base de usuarios de destino. Por ejemplo, si su público objetivo no suelen utilizar los navegadores móviles, entonces usted puede ser mejor dirigidas a un móvil específico del navegador y dejar que esas partes interesadas toman esa ruta. Sin embargo, si los usuarios desean el servicio móvil navegador para ser la interfaz principal, entonces es probable que desee una gama más amplia de opciones del navegador funcionales.

Como caso-en-punto, tome todas las viejas aplicaciones web que se utilizan para requerir el uso de IE, simplemente porque ellos (los desarrolladores (s)) no querían o no podían garantizar el buen funcionamiento de otros navegadores. Si el público objetivo de esta aplicación era usuarios de negocios, que suelen utilizar (d), es decir de todos modos, a continuación, esto no habría sido una limitación perceptible. Sin embargo, en una aplicación más general web (web-mail, etc.), entonces la restricción de todos los usuarios a un solo navegador podría ser agobiante en un entorno competitivo.

Sin embargo, voy a decir que cualquiera de la dirección que toma, seguir el consejo de Silvo trata de garantizar la funcionalidad, incluso sin JavaScript. Muchas empresas, bibliotecas, etc. todavía limitan la funcionalidad de JavaScript.

Answer 3

Lo que usted debe tratar de hacer es proporcionar una experiencia rica, pero al mismo tiempo garantizar que toda su funcionalidad del núcleo funciona incluso cuando no está presente el javascript en el cliente (o se apaga). Stackoverflow es un buen ejemplo de un sitio que se encuentra un buen equilibrio entre estos dos enfoques.