Según su redacción “centrada principalmente en el diseño móvil (web)”, voy a tomar eso como que quiere decir un “primer enfoque móvil”, ¿verdad?
Hay una serie de soluciones que harán que sus páginas web respondan, pero los dispositivos móviles primero implican que está priorizando en gran medida el rendimiento (y las características) para los dispositivos móviles. En ese contexto, pude ver un par de formas de hacer girar esto.
No importa qué camino elija, Mobile Boilerplate es un buen punto de partida y relativamente agnóstico. Su archivo .htaccess es uno de los mejores en el negocio. Lo trajeron las personas que crearon HTML5 Boilerplate. Sus valores predeterminados del servidor web y los valores predeterminados de CSS son realmente amigables para dispositivos móviles.
- Aplicación móvil vs. Web móvil, ¿quién ganará en el futuro?
- ¿Cuáles son los beneficios de tener una aplicación en lugar de un sitio web móvil bien optimizado?
- ¿Por qué Facebook y Twitter no usan un diseño web receptivo?
- ¿Cuál es la mejor manera de hacer que su sitio web sea amigable con el navegador móvil?
- ¿Cuál es la diferencia entre crear una aplicación móvil y un sitio web?
Algunos otros beneficios de Mobile Boilerplate (demasiados para enumerar)
- Resuelve errores de renderizado específicos de dispositivos móviles que la mayoría de los sistemas de cuadrícula (¿todos?) No abordan.
- Problemas de representación de fuentes mitigadas (en Mobile IE, por supuesto)
- Proporción de píxeles gestionada en dispositivos de alta resolución
- Polyfill sus consultas de medios con JS si es necesario para garantizar que su diseño receptivo sea compatible con varios navegadores (esto resuelve un problema real)
Lea la lista completa de características aquí. https://github.com/h5bp/mobile-b…
Es posible que no pueda integrar todo Mobile Boilerplate en su solución, pero aún así debe mirar los vacíos que existen en su solución y usar Mobile Boilerplate para llenar esos vacíos.
Entonces, en combinación con Mobile Boilerplate, aquí hay tres opciones que le brindarán la grilla de respuesta súper genial que está buscando …
Opción 1: utilice un sistema de cuadrícula barebone integrado en consultas de medios polivinilos
Compatibilidad con un sistema de cuadrícula sensible a CSS que utiliza consultas de medios (polifundido para navegadores antiguos): por ejemplo, http://framelessgrid.com/. Este es el sucesor del sistema de cuadrícula Less CSS y parece realmente prometedor. Puede descargarlo en una gran cantidad de formatos e incluso viene con plantillas PSD.
Opción 2: utilice el sistema de cuadrícula 960 con Adaptive.js
Aprenda sobre esto aquí: sistema de cuadrícula 960 (http://960.gs) en conjunto con adapt.js (http://adapt.960.gs/). Javascrip carga una hoja de estilo diferente en función de cada tamaño de pantalla, por lo que no carga CSS innecesario. También puede descargar plantillas PSD para esto como solución.
Opción 3: use Twitter Bootstrap o partes de él
Use Twitter Bootstrap y llame a responsive.less en bootstrap.less. Si no está familiarizado con Less CSS, tómese un momento para aprenderlo (o Sass), cambiará la forma en que escribe CSS. http://lesscss.org/.
– La ventaja es que Bootstrap es una interfaz de usuario muy madura.
– La desventaja es que terminas precargando muchos elementos que ralentizarán tu rendimiento. Por ejemplo, si está enfocado en un enfoque de ‘móvil primero’, puede encontrarse eliminando estados de desplazamiento y otros estilos que no tienen sentido en una interfaz táctil. Creo que Andy Clark, autor de Hardboiled Web Design, ha comenzado este camino con su renovada base de código 320 y Up http://stuffandnonsense.co.uk/pr….
Vea el despojado Bootstrap de Andy aquí: http://stuffandnonsense.co.uk/pr…
– Plantillas para Bootstrap
Hay plantillas Omnigraffle para Bootstrap en graffletopia.
Existe esta plantilla de IU de PSD: http://www.bentdesignstudio.com/… (No he comprobado si incluye plantillas de cuadrícula)
También hay una plantilla de cuadrícula Boostrap disponible para Illustrator aquí: http://www.aaronkwhite.com/2012/….
Una nota sobre estas opciones:
No hay bala de plata. El contexto es clave, pero estas son las tres opciones que consideraría en mi flujo de trabajo de diseño / desarrollo. También intentaría portar todo el CSS a Sass o Less, y todo el HTML a HAML si es posible.
Reacciones de la industria al diseño web receptivo
Algunas personas piensan que responder es ‘oro de tontos’. Creo que el tiempo ya cuenta una historia diferente. Una cosa es segura: el trabajo de Ethan Marcotte en diseño receptivo abrió un mundo completamente nuevo de posibilidades en diseño y desarrollo web. En mi opinión, el diseño web receptivo ganó mucha credibilidad callejera con el relanzamiento del sitio web del Boston Globe (Ethan también participó en ese proyecto).
Los dos problemas principales que debe tener en cuenta al diseñar un sitio web receptivo son:
1. Rendimiento : debe asegurarse de optimizar sus activos para dispositivos móviles (y conexiones), ya que no es compatible con dispositivos móviles si está ocultando / apilando elementos, pero aún carga una página web de escritorio completa. Adherirse a un enfoque de Mobile First debería contribuir en gran medida a mitigar los problemas de rendimiento.
2. Experiencia del usuario : algunos argumentan que no se puede diseñar una experiencia de usuario única para todos. En esa línea de pensamiento: las características deben ser contextuales para el dispositivo, por ejemplo, su objetivo para una aplicación de productividad puede cambiar significativamente si está accediendo a él desde un dispositivo móvil mientras viaja mientras está frente a un monitor de 24 “en la comodidad de su silla de oficina de cuero. Desafortunadamente, incluso un primer enfoque móvil no resolverá este problema, por lo que (si los recursos lo permiten) considere cuidadosamente si realmente necesita ambos: un sitio móvil específico (o aplicación nativa) Y un sitio web más general.
¡Buena suerte con tu desarrollo receptivo!
