responsive-design - left - foundation text

zurb foundation 4 mobile vs desktop content (2)

Soy un gran admirador de la Fundación Zurb. Acaban de lanzar la Zurb Foundation 4, que fue rediseñada para ser móvil primero. Soy bastante nuevo en el diseño receptivo teniendo en cuenta las experiencias de escritorio móvil, tableta y tradicional. Estoy tratando de entender cómo administrar el contenido de mi sitio para estos diferentes dispositivos. Con Zurb Foundation 4, puede ocultar o mostrar contenido basado en tamaños de dispositivos pequeños, medianos o grandes. Por lo tanto, parece que con el enfoque de Zurb soltarás todo el contenido al dispositivo y dejarás que CSS decida qué contenido mostrar dependiendo del dispositivo (este es un diseño receptivo).

Mi pregunta es ¿por qué tenemos que dejar todo el contenido en el dispositivo? Esto parece una pérdida de procesamiento en el servidor, una pérdida de ancho de banda, una experiencia más lenta ya que el navegador maneja el contenido, algunos de los cuales quizás nunca se muestren al usuario debido al dispositivo que están usando. ¿Me estoy perdiendo de algo? ¿No sería mejor volver al servidor y dejar que envíe contenido al cliente que sea apropiado para el tipo de dispositivo? ¿No deberíamos preocuparnos por los planes de datos del usuario móvil y no enviar contenido que no sea apropiado para su tipo de dispositivo? Todos los ejemplos que he visto sobre diseño receptivo tienen contenido para escritorio y dispositivo móvil / tableta descargado al cliente que parece ser un desperdicio.

Estoy desarrollando una aplicación de entrada de tiempo que tiene una experiencia de usuario diferente según el tipo de dispositivo. Los equipos de escritorio (cuando están en pantalla completa) tienen una experiencia de ingreso de datos más detallada, mientras que los dispositivos móviles / tabletas tienen una experiencia diferente debido a que el dispositivo es más pequeño. Estoy desarrollando la aplicación de modo que cuando el navegador de escritorio se redimensiona a algo más pequeño que 768px de ancho, jQuery realiza una llamada al servidor para cambiar la interfaz de usuario de la versión "más pequeña" de la versión móvil / tableta. ¿Es esto apropiado? Ciertamente no quiero descargar 2 versiones de la aplicación y ocultar una u otra dependiendo del ancho del dispositivo.

¿Estoy en el camino correcto con mi enfoque jQuery? ¿Me estoy perdiendo algo con respecto al diseño receptivo y la necesidad de adaptar el contenido al dispositivo? Cualquier idea, sugerencia y guía es apreciada. Gracias.

Mobile First con la Fundación Zurb es básicamente un cambio de filosofía por parte del equipo de Zurb y si desea desarrollar un sitio receptivo y no adoptar un enfoque de Mobile First, le sugiero que utilice Foundation 3, que todavía está disponible y es fantástico. Hay un libro que estoy leyendo que ofrece una excelente presentación para Mobile First, llamado Mobile First por Luke Wroblewski, quien también figura como asesor de Zurb.

aquí hay un artículo del mismo autor que podría ser interesante:

http://www.netmagazine.com/interviews/luke-wroblewski-mobile-first

Básicamente: la premisa es que comiences tu desarrollo y diseño para un dispositivo móvil, lo que significa básicamente un navegador de estilo iOS o Android y luego agregues funciones.

Por lo tanto, en lugar de comenzar con una experiencia de escritorio / tableta y eliminar cosas como se hacía comúnmente con las clases .hide en Foundation 3 y aún así implementarse de esta manera con Foundation 4, sugieren usar clases .show para agregar contenido adicional.

Esto se puede tomar más lejos usando Compass y Sass Mixins. No hay una gran cantidad de documentación sobre cómo hacer esto, pero básicamente puedes mantener tu marcado semántico, aplicar una identificación en lugar de una clase y usar los mixins para aplicarlo a esa identificación. Aquí hay ventajas en la velocidad que atraviesa el dom para un id vs. una clase, por lo que puede ser un buen camino a seguir.

Nota: Foundation 4 está usando el reemplazo en reemplazo (hay algunas limitaciones) para jQuery llamado Zepto. Puedes reemplazar Zepto con jQuery si realmente lo necesitas en Foundation 4 o usa Foundation 3 en su lugar. Zepto es mucho más liviano y, por lo tanto, se adapta bien para dispositivos móviles.

En cuanto a que sea más rápido al usar jQuery para cargar de forma asíncrona los datos (supongo) en función del tamaño del navegador, esa es una forma de hacerlo. No estoy seguro de si vas a tener un aumento de velocidad enorme aquí. Hay muchas estrategias, paginación, asincronización cargando más datos sobre la marcha, y depende de cómo organices UX / UI alrededor de esos datos.

También hay muchos otros problemas, como los recursos de almacenamiento en caché, CDN, etc. que son típicos en la ingeniería de front-end que pueden dar un tiempo de carga más rápido. Un recurso que puede consultar relacionado con esto es ySlow.

También hay muchos patrones de diseño, como diapositivas fuera de lienzo, la línea 3 (menú de hamburguesas), la carga de más datos en desplazamiento, aplicaciones sin estado, que pueden permitirle tener la misma funcionalidad en una aplicación móvil. Si se queda sin estado, después de la carga de la página inicial, otras páginas deberían parecer casi instantáneas.

Creo que la pregunta aquí es más filosófica, en qué necesitas todas las características, que es una cosa a la que creo que está intentando abordar el enfoque de Mobile First.

Otra cosa en que pensar es el tiempo de carga percibido. Creo que leí acerca de esto es Seductive UX (otra gran lectura), pero cuanto más rápido se puede subir la página con un cargador o un girador, más rápido se percibe que se está cargando, incluso cuando en realidad se puede cargar más lento.

Como nota final, si planea usar Foundation, puede buscar usar jQuery / Zepto con Modernizr para extraer de las mismas consultas de medios que la fundación está usando. De esta forma no duplicas o creas algo que es inconsistente con el resto de la capacidad de respuesta.

Estoy desarrollando la aplicación de modo que cuando el navegador de escritorio se redimensiona a algo más pequeño que 768px de ancho, jQuery realiza una llamada al servidor para cambiar la interfaz de usuario para la versión "más pequeña" de la versión móvil / tableta. ¿Es esto apropiado?

No suena como un buen enfoque ¿tomas orientaciónCambiar a la cuenta?

Ciertamente no quiero descargar 2 versiones de la aplicación y ocultar una u otra dependiendo del ancho del dispositivo.

Si está en la mayoría de las tabletas que visitan el sitio web en vertical y cambian a horizontal, tendrá que descargar la interfaz de usuario> 768px después de haber descargado la interfaz de usuario <768px.

El primer acercamiento móvil en zb4 (con consultas de medios) le permite evitar que cosas que pertenecen a dispositivos grandes se descarguen en dispositivos pequeños. Básicamente, comienzas con estilos móviles y si el dispositivo cumple con las condiciones que estableces en tus consultas (puedes tener muchos más puntos de interrupción de los que el marco zf4 te da de forma predeterminada), la siguiente regla salta.

He trabajado en varios proyectos "receptivos" incluso en los días previos a la mediación en los que usaba javascript para medir Windowsize

En cuanto a javascript y como @ powjames3 dijo que zepto es mucho más liviano / rápido que jquery y que si pudieras escribir tus propias funciones de javacript sería mucho mejor que usar una biblioteca exagerada.

Hoy en día utilizo aplicaciones móviles Webapps y sitios web que utilizan una mezcla de sniffing de agente de usuario (a veces para decidir qué sistema de imagen o script / style src entregar), a pesar de la decisión de las pruebas de agente de usuario, siempre presento primero mediaqueries móviles y contenido condicionalmente cargado .

"Como señalaron acertadamente Ethan Marcote (y John Allsopp antes que él), la flexibilidad inherente de la web es una característica, no un error".

Aquí hay algunos recursos que pueden ponerlo en el camino correcto:

Análisis y detección del agente de usuario: http://mobiledetect.net/

Tutorial http://www.html5rocks.com/en/mobile/responsivedesign/ que cubre:

Por qué necesitamos crear experiencias móviles, receptivas y adaptativas primero
Cómo estructurar HTML para un sitio adaptable a fin de optimizar el rendimiento y - priorizar la flexibilidad
Cómo escribir CSS que define estilos compartidos primero, crea estilos para pantallas más grandes con consultas de medios y usa unidades relativas
Cómo escribir JavaScript discreto para cargar de forma condicional fragmentos de contenido, aprovechar eventos táctiles y geolocalización
Qué podemos hacer para mejorar aún más nuestra experiencia de adaptación

Espero eso ayude