Creación de prototipos en el navegador | Programar Plus

La creación de prototipos de animaciones e interacciones es vital por varias razones: pueden hacer que su interfaz se sienta engañosamente rápida, pueden ayudar a enfocar al usuario en una tarea específica y pueden proporcionar una mejor idea del estado actual de su aplicación. ¿Se están cargando datos? ¿Hay algo ahora en el que no se puede hacer clic? ¿Cuánto tiempo tienen que esperar hasta que puedan realizar una acción?

En Gusto, he estado trabajando en muchos pequeños detalles de interacción y prototipos últimamente por estas mismas razones; lamentablemente, no hay mucho que pueda mostrarles en detalle todavía. Pero, creo que el proceso de cómo estoy haciendo esto es mucho más interesante que en lo que realmente estoy trabajando, así que eso es lo que voy a compartir aquí.

El problema al que me he enfrentado con la creación de prototipos de animaciones se reduce a las herramientas porque, en última instancia, me parecen restrictivas. Siempre que he experimentado con ellos en el pasado, siento que una mano siempre está atada a la espalda. Es muy posible que no los esté usando correctamente, pero creo que ninguno de ellos realmente imita el comportamiento del navegador correctamente y, aunque me ha fascinado ver cómo las herramientas como Framer, Marvel, Zeplin y Principle ganan terreno, no creas que son para mí. Al menos no todavía.

En mi opinión, la mejor manera de crear prototipos de muchas interacciones sigue siendo con HTML, CSS y (¡jadeo!) Una pizca de jQuery cuando lo necesito.

Cómo estoy haciendo prototipos hoy

Con mi proyecto reciente, decidí invertir un poco de tiempo en CodePen para ayudar a nuestro equipo de diseño a crear prototipos rápidamente. Esto es lo que construí:

Vea el prototipo de Pen Gusto: encabezado de Robin Rendle (@robinrendle) en CodePen.

No, de verdad, eso es todo. Es solo un prototipo simple que se parece a nuestra aplicación.

Es un bolígrafo con todo el HTML para la navegación de la aplicación, y también contiene todo el CSS. De esta manera, un diseñador de Gusto puede bifurcar ese lápiz y comenzar a escribir HTML y CSS para experimentar con una parte específica de la interfaz de usuario sin toda la presión adicional de tener que escribir código de producción. Es importante tener en cuenta que este prototipo no es para descubrir UX, ya que herramientas como Figma y Sketch hacen un trabajo mucho mejor en eso. Los prototipos como este son en su mayoría útiles para descubrir interacciones meticulosas de la interfaz de usuario, como tablas, hojas de cálculo y menús desplegables, componentes que pueden complicarse muy rápido.

Para hacer este prototipo, simplemente copié y pegué todo el HTML y CSS de nuestra aplicación web en un nuevo lápiz. (En el futuro, probablemente deberíamos tener un sistema en el que siempre estemos creando prototipos con el último código actualizado de nuestra aplicación, pero, por ahora, creo que este es un buen punto de partida). Este bolígrafo contiene todos los elementos del menú y de navegación que necesitamos para que se parezca a la aplicación Gusto. Tenemos un lápiz separado para el pie de página que cierra todos los divs que abrimos en el encabezado. Por último, tenemos un bolígrafo más que importa esos otros dos bolígrafos así:

<!-- HEADER -->
[[[http://codepen.io/robinrendle/pen/481a88853820067752e28cdb479c91f3]]]

<!-- HTML GOES HERE -->
<h1>App Prototype</h1>
<p>You can fork this pen and write all the HTML and CSS you need to prototype interactions and explore ideas right here in your browser.</p>

<!-- FOOTER -->
[[[http://codepen.io/robinrendle/pen/0dcaa93954f06f4d03b7e23e8ea54cac]]]

Vea el prototipo de Pen Gusto: completo de Robin Rendle (@robinrendle) en CodePen.

¿Qué es esa sintaxis extraña con todos los [[[ ]]]? Esa es la sintaxis de inclusión de HTML para CodePen. Si colocamos la URL de un bolígrafo entre esos corchetes, CodePen obtendrá el código de ese bolígrafo y lo colocará directamente en este nuevo bolígrafo. ¡Eso es! Bastante dulce, ¿verdad?

Para terminar, quería tomar algunas notas sobre lo que aprendí con esta nueva configuración.

Lección 1: Los prototipos deberían ser muy fáciles de compartir

Idealmente, los prototipos son fáciles de compartir con otros diseñadores e ingenieros, excepcionalmente rápidos de configurar y no requieren capacitación o experiencia previa, y Codepen es perfecto para eso. Me gusta esta configuración por varias razones. Por un lado, no tenemos que enseñar a los diseñadores CoffeeScript como tenemos que hacerlo con Framer y no tenemos que ejecutar talleres de React o Vue para ponerlos en funcionamiento con una aplicación de creación de prototipos compleja.

Sí, la gente necesita aprender cómo funcionan HTML y CSS para hacer prototipos como este, pero creo que aprender los conceptos básicos de esos dos lenguajes es vital para un diseñador que trabaja en la web de todos modos.

Lección 2: El código incorrecto está bien

Aquí hay otra cosa que aprendí recientemente mientras hacía prototipos: mal código está bien En este punto. De hecho, deberíamos estar escribiendo un código terrible e imperdonable al hacer prototipos en el navegador. Deberíamos escribir el tipo de CSS y HTML que mantendría a Harry Roberts despierto por la noche porque el código limpio y mantenible se interpone en el proceso de diseño cuando el enfoque debería estar en iterar lo más rápido posible.

Para ser honesto, no me preocupan las mejores prácticas de front-end cuando hago estos prototipos; no pienso en BEM, HTML semántico o incluso en rendimiento. Ah, y ciertamente no me importa la forma más competente de renderizar una cosa de React.

Mientras descartemos todo ese código prototipo y comencemos de cero más tarde, y siempre que haya un paso para dividir el diseño en componentes y asegurarnos de que esas piezas de lego se puedan mantener, estén bien documentadas y tengan un alto rendimiento en nuestro entorno de producción, entonces yo Creemos que escribir mal no solo debería permitirse, sino fomentarse activamente.

Esto me lleva a mi conclusión final.

Lección 3: los diseñadores y desarrolladores siempre deben traducir su código

Creo que la primera vez que un diseñador y / o desarrollador de aplicaciones para el usuario escribe código, nunca debería estar en un entorno de producción. Tener el margen y la libertad de volverse loco con el código en un entorno seguro centra su atención en el diseño y hacerlo compatible con las limitaciones de un navegador. Después de esto, puede pensar en preparar el código de un montón de basura caliente y humeante en una poesía encantadora, impecable y lista para la producción. Traducir las maquetas estáticas en un prototipo interactivo es el primer paso, pero es vital tener un próximo paso para hacer cumplir los estándares de su código.

¿Su aplicación utiliza BEM? ¿Cómo debe abstraer cada uno de estos componentes en archivos separados? ¿Cómo llama a todos estos nuevos componentes que está introduciendo en el sistema de diseño?

Creo que todas estas preguntas son más fáciles de responder una vez que tenga ese prototipo interactivo. Y recomendaría encarecidamente que tanto los diseñadores como los ingenieros de front-end experimenten creando pequeñas herramientas como esta. Puede parecer un poco extraño al principio, pero prometo que producirá un trabajo mucho mejor a largo plazo.