Probando la beta pública de Abstract (minitutorial)
La verdad es que tenía muchas, muchas ganas de probar Abstract, realmente había hype, y hoy por fin ha salido la beta pública y había que echarle un vistazo.
Pero lo primero de todo y por si no aún lo sabes, ¿qué es esto de Abstract?
Básicamente es algo que los diseñadores de producto deberíamos de haber tenido hace mucho tiempo: Un software que nos permite hacer control de versiones y que imita el comportamiento y las funcionalidades de Git (crear y mergear ramas, hacer commits, etc)
Y seguro que algunos os preguntaréis:
¿y qué es eso de Git?
(A partir de aquí, si algún desarrollador lee esto, que perdone todas mis meteduras de pata e imprecisiones porque, por un lado no soy un experto, ni Abstract funciona exactamente como Git)
¿Y tan útil es? Una búsqueda rápida en google nos devuelve un montón de resultados como este en el que se habla de porqué los diseñadores deberíamos haber estado usando git desde hace tiempo. El problema es que es algo engorroso y la experiencia dejaba bastante que desear pero desde luego, sí, es muy útil.
Pero sigamos. Si te sabes esta parte, pasa un par de párrafos :) Según wikipedia Git (pronunciado “guit”) es Un software de control de versiones diseñado por Linus Torvalds, pensando en la eficiencia y la confiabilidad del mantenimiento de versiones de aplicaciones cuando éstas tienen un gran número de archivos de código fuente.
Dicho así no parece que vaya a ser algo interesante para los diseñadores pero básicamente lo que permite Abstract, emulando a Git, y que a nosotros nos interesa es que varios diseñadores van a poder trabajar en paralelo usando copias de un archivo fuente de Sketch (por ahora, sólo sketch) llamadas ramas (branch) Esas ramas, en la práctica funcionan como instancias de Sketch en las que se puede trabajar de forma normal usando arboards, páginas, símbolos, etc. Una vez que hayamos terminado nuestra sesión de trabajo o acabado un componente o hecho los cambios que toquen en una rama, se va a poder pegar o fusionar al archivo maestro todo lo que hemos hecho con una acción llamada “merge” lo que nos va a permitir tener en activo diferentes partes de un diseño y juntarlas a nuestra voluntad en el momento que queramos.
Además, cada uno de estos cambios van a estar registrados y van a poder revertirse si así lo deseamos.
Así que tendremos uno o varios archivos maestros sobre los que podremos trabajar en paralelo y actualizar con nuestros cambios una vez nos hallamos quedado satisfechos con el resultado, acabando de un plumazo con esos:
- Oye, ¿has subido al servidor la última versión de la app?
- El muy #¢$##^* de Joselito se ha ido de vacaciones y no ha subido los últimos cambios. Lo estoy llamando y no coge el teléfono, mira entre los 5.879 iconos del escritorio a ver si encuentras algo…
- ¿Pero que haces usando el archivo “V34_definitivofinal _finalísimo_deverdad”? Ahora el que vale es el “V34_definitivofinal_finalísimo_deverdad_perodeverdadelabuena”
Si aún no lo ves claro, sigue leyendo y verás como funciona Abstract con un minitutorial que muestra un ejemplo muy sencillo.
Una pequeña prueba
Descarga y onboarding
Aunque no es el objetivo de lo que quería escribir, comentar que tras crear la cuenta y descargar la app para Mac (en la versión web no se pueden crear o editar proyectos) nos encontramos con que el onboarding es bastante deficiente y cuando abres la app por primera vez, te sueltan en una pantalla en blanco sin ningún tipo de contenido y sin ninguna pista para poder comenzar.
Vale que es una beta, pero esas cosas habría que cuidarlas un poco más.
Creando un proyecto
Lo primero será crear un proyecto. Con la versión gratis tienes proyectos ilimitados con total funcionalidad. Esta gente monetiza los usuarios y no el número de proyectos así que para probarlo está genial.
No voy a entrar a analizar la interfaz pero sí comentar algunas cosas un poco peliagudas como esta: Asegúrate que en la app estás en el dashboard de tu cuenta personal. Si no, no podrás crear proyectos. Te indico dónde en la siguiente imagen.
Una vez creado el proyecto he hecho una primera prueba muy sencilla que consiste en crear un archivo maestro de Sketch, a partir de él crear dos ramas, editarlas y hacer merge con el archivo maestro original.
Archivo maestro
Lo he creado directamente en Sketch y esta formado por:
- Dos símbolos diferentes (aunque tengan el mismo color) con un círculo y un texto*
- Dos símbolos diferentes (aunque tengan el mismo color) con un un cuadrado y un texto*
*Los textos están añadidos porque queremos probar como Abstract gestiona los cambios en los overrides de los símbolos.
Creando el proyecto
Lo primero es crear un proyecto, algo bastante sencillo. Ponemos un nombre, una descripción e importamos el archivo maestro de Sketch
Vista general del proyecto
Vista de la página del archivo maestro
Creando Ramas (Branches)
Lo siguiente es crear las ramas.
Básicamente, una rama es una copia del archivo maestro que podremos editar de forma independiente.
Las ramas se crean fácilmente desde la vista general del proyecto. Puedes echar un vistazo para verlo en la imagen de la sección anterior.
Sólo hay que darle al botón y rellenar un pequeño formulario con el nombre y descripción. Una vez creadas la visión general del proyecto es la siguiente
Las distintas ramas se navegan fácilmente a través de unas breadcrums en la parte superior izquierda. Ten esto muy en cuenta porque va a ser importante tener claro en qué página te encuentras, tanto usando la app como para seguir este mini tutorial. Tras crearlas, pasamos a editarlas. Para ello, elegimos la rama que queremos editar.
Fíjate como en la rama se muestra el contenido tal y como está en el archivo maestro ya que no lo hemos editado aún. Haciendo click en “Edit in sketch”, será el propio Abstract el que se encargue de abrir los archivos creando una nueva instancia.
Una vez hecho esto, trabajamos cuanto queramos. Cada vez que salvemos con un cmd+s, un diálogo en la parte inferior de Sketch nos indicará que estamos listos par hacer “Commit”, es decir actualizar esos cambios dentro de la rama de Abstract. Hasta que no hagamos esto podemos estar trabajando en nuestro diseño sin problemas que ningún cambio se hará efectivo.
(Una cosa que no he probado es que pasa con el autosave de sketch y si sigue funcionando mientras trabajamos en este modo.)
Una vez pulsado el botón para hacer el commit nos encontramos con lo siguiente
En esta pantalla nos encontraremos de inicio con el botón de “commit changes” desactivado. Yo he tardado un par de minutos en darme cuenta de que el título del commit que es obligatorio y que ya ves relleno en la imagen de arriba es el que limita el funcionamiento del botón.
Una pista más evidente no habría estado mal :)
Como se puede ver en la imagen anterior, el resumen muestra el cambio en el símbolo y también en el override del segundo círculo en el que hemos cambiado “hola” por “hello”, aunque no se detallan los cambios en los overrides en esta preview y eso puede despistar, además no he comprobado como funciona con símbolos anidados… Lo dejamos para la próxima :)
Al hacer el commit de los cambios nos encontramos con que la rama se ha actualizado
Ahora toca hacer lo mismo con los cuadrados para obtener el siguiente resultado:
El resultado es que tenemos dos ramas con dos cambios distintos aplicados de forma individual, lo que puede representar dos líneas de trabajo en paralelo que podrían haber sido hechas por dos personas en dos máquinas distintas en cualquier parte del mundo. Definitivamente, ¡mola!
A juntarlo todo
Lo que toca ahora es añadir esos cambios al archivo maestro del que hemos partido. Esta acción se denomina Merge y no dudes de que muy pronto acabarás diciendo algo así como hey tío, voy a mergear esa rama :)
Pero vayamos por orden y supongamos que la persona trabajando en los cuadrados es muy eficaz, acaba antes su trabajo y entra en la rama cuadrados para hacer el primer merge.
Es tan sencillo como clicar en el icono de “merge branch” que se encuentra en la esquina superior derecha dentro de cada rama.
Una vez hecho esto, la rama se archiva y el master se modifica pasando a ser:
Master + Cambios cuadrados
Cómo puedes ver a continuación, el master se ha actualizado y se ha añadido la acción correspondiente en el sidebar izquierdo
Esta acción va a condicionar a la persona dos, encargada de los círculos, porque después de acabar su edición, al ir a hacer el merge de su rama se va a encontrar con que el archivo master actual es diferente al archivo master inicial del que partió.
Esto es algo bastante habitual y más en equipos grandes con mucha gente trabajando a la vez. Abstract lo gestiona de la siguiente manera:
Lo primero que vemos es que al entrar en la rama círculos, en vez del icono de “merge branch”, nos vamos a encontrar con un icono que dice “Update from master”
Una vez que le damos al botón se nos van a presentar dos opciones:
- Actualizar nuestra rama con los cambios del merge anterior (de ahí el nombre update from master)
- No actualizar nuestra rama con los cambios del merge anterior.
Esto, lógicamente, afectará al resultado final del archivo fuente y elegiremos una u otra opción dependiendo del momento y de lo que nos interese.
En este caso vamos a actualizar los cambios para tener un master final con todos los cambios aplicados. Al hacerlo llegamos a:
En esta pantalla se nos muestra la opción para elegir los dos caminos. Al hacer click en el botón de Pick Artboard de la izquierda (archivo master) actualizaremos nuestra rama con el merge anterior obteniendo:
Cuidado, porque podría parecer que ya lo tenemos hecho, Nuestra rama círculos contiene los dos cambios que queríamos hacer pero como vemos en la imagen anterior, la rama aún no la hemos mergeado (el icono así lo indica) y si vamos al master veremos que nos encontramos con que sólo tiene los cambios del primer merge
Cómo decía antes, con la acción anterior sólo hemos actualizado los cambios del master que había cambiado a nuestra rama círculos y es ahora, volviendo a la página de la rama, cuando repetimos el proceso del “merge branch” y finalmente obtenemos un archivo master que tiene los dos cambios hechos con lo que el trabajo estaría acabado.
Una vez más, se puede comprobar en el sidebar lateral como los dos merges han sido realizados.
Conclusion
Que este tipo de workflow funciona se encargan de demostrarlo a diario los miles de equipos de desarrollo que hoy día usan Git a lo largo de todo el mundo. Eso sí, a mí me surgen dudas sobre cómo va a ser capaz de gestionar Abstract un documento que contenga cientos de símbolos, símbolos anidados con un montón de overrides distintos etcétera. No tanto a nivel de funcionalidad sino para mostrar de forma clara y visual qué cosas son las que han cambiado.
Habrá que ver como integrar Abstract en los workflows actuales y que tal funciona Craft y la sincronización con Invision
Por otra parte, hoy mismo he tenido muchos problemas con este mini ejemplo ya que lo había hecho de primeras sólo con shapes y no con símbolos y el update from master no funcionaba.
Si todo ha de ser un símbolo para que esto funcione correctamente va a ser bastante tedioso la gestión de los archivos porque aunque está genial ser ordenado y tenerlo todo componentizado a veces, trabajando con prisas, no puedes ser todo lo cuidadoso que te gustaría o simplemente puede olvidársete crear algún símbolo y que esos cambios no se apliquen como me ha pasado antes. Si no hay una forma eficiente de controlar esas cosas, en archivos muy grandes puede ser todo un engorro.
De cualquier modo el software está en beta pública todavía y parece ser que esto se trata de un bug. Habrá que ver cómo van gestionándolo.
La idea, desde luego, parece más que prometedora pero yo me atrevería a implantarla en un proyecto real por el momento hasta que veamos el músculo que realmente tiene para lidiar con el mundo real.
De cualquier modo, un 10 para esta gente. Da gusto, de verdad, ser diseñador en estos tiempos en los que cada semana tenemos algo nuevo que hace que nuestro trabajo sea mejor y más eficaz.
