OmbuShop Crea Tu Tienda Online

Git para diseñadores

  • Facebook
  • Twitter
  • LinkedIn
  • StumbleUpon
  • Email
  • RSS

¿Qué es Git?

Git es una herramienta que nos permite controlar versiones de nuestros proyectos y trabajar de forma colaborativa y descentralizada. Es particularmente relevante para diseñadores web, ya que es en esta área donde los diseñadores trabajamos con código.

Lidiamos con muchos archivos de texto plano escritos en lenguajes formales como HTML, CSS y JavaScript, que en muchos casos están siendo modificados por varias personas al mismo tiempo: diseñadores, programadores y  editores de contenidos.

Hoy en día la mayoría de los diseñadores y desarrolladores web utilizamos Github como servidor para guardar nuestros repositorios. Recomiendo que se suscriban a dicho sitio para dar los primeros pasos.

Otra alternativa es BitBucket, que incluso te permitirá tener repositorios privados en su plan gratuito.

¿Cómo instalar Git?

Interfaz gráfica de usuario (modo amigable)

Una vez creada la cuenta en  Github, podremos descargar la aplicación amigable con interfaz gráfica de usuario para Mac y para Windows, Esta aplicación nos permite el uso de Git sin mayores inconvenientes, a la manera que estamos acostumbrados a utilizar nuestras aplicaciones hoy en día: ventanas, botones, cursor, etc.

Línea de comandos (modo geek)

Por lo general, a medida que uno se vaya acostumbrando, es más práctico manejar Git desde la línea de comandos. A pesar de lo complejo que esto pueda parecer, su utilización es muy rápida y sencilla, a continuación los links con los instaladores de línea de comando para cada plataforma:

Una vez instalada la app para el manejo de Git desde línea de comandos, no tenemos más que abrir una sesión de la línea de comandos y escribir los comandos correspondientes a Git. Aquí hay una buena guía en español de los comandos de Git.

Configuración inicial

La configuración inicial es muy sencilla desde la web de Github o desde la aplicación nativa. Vamos a concentrarnos en cómo crear un repositorio desde la línea de comandos, que es lo que puede resultar más complejo para quien no está acostumbrado a ejecutar comandos desde allí.

Luego de abrir la línea de comandos, podremos configurar Git siguiendo los siguientes pasos. Lo primero es indicar el nombre de usuario, como sigue:

git config --global user.name "Tu Nombre Aquí"

Lo siguiente será configurar el email (el mismo que utilizamos para la cuenta de GitHub), también es muy sencillo:

git config --global user.email "your_email@example.com"

Si necesitas más detalles para los pasos, puedes ver esta guía para el seteo de Git.

Creación de tu primer repositorio

Cuando trabajamos un proyecto con Github, dicho proyecto estará alojado en lo que llamamos repositorio. Un nuevo repositorio puede crearse desde la web de Github, desde la aplicación gráfica, o bien desde la línea de comando. Una vez hecho el repositorio, habrá una relación entre una carpeta local en tu disco rígido y el repositorio online en Github.

Por lo general, se clona el repositorio remoto en la computadora local. Trabajamos sobre la versión clonada local, y luego podremos empujar los cambios hacia el repositorio remoto cuando sea necesario.

Modificaciones en tu proyecto

Cuando trabajes en tu proyecto localmente, puede ser que necesites agregar nuevos archivos o sub-carpetas. Para eso existe el comando add:

git add <archivo o carpeta>

Por otro lado, también tenemos la posibilidad de confirmar una instantánea, una “foto” del proyecto en cierto momento puntual. De esa forma confirmas las modificaciones que hayas hecho sobre los archivos que estuviste trabajando. Esto se realiza con el comando commit:

git commit -m "Mensaje descriptivo de la modificación que has hecho."

El comando permite la inclusión de un mensaje que describe qué cambios fueron realizados al proyecto. De esta forma tendrás documentado qué archivos fueron modificados, exactamente en qué renglones y con qué objetivo (el mensaje).

Por último, status te permite verificar el estado de un proyecto, si ya has confirmado los cambios por medio de un commit, o no, etc.:

git status

Sincronizar con el repositorio remoto

Para mantener siempre una copia de seguridad en el repositorio remoto, conviene sincronizar para mantener los archivos actualizados. De la misma forma, si se trabaja en equipo, varios usuarios podrán trabajar de forma centralizada sincronizando sus cambios con el repositorio remoto.

Descargando desde el repositorio

Para descargar los últimos cambios que pueda tener el repositorio remoto (por ejemplo, cambios realizados por otros colegas), se puede utilizar el comando pull. A continuación lo estamos usando para que descargue los últimos cambios que se encuentren en el repositorio, desde el origen “master” (en este caso, la branch sobre la cual se está trabajando):

git pull origin master

Las branches (“ramas”, en inglés), son diferentes versiones de un mismo software, que pueden ir en palalelo. De forma tal que un grupo de personas pueda trabajar sin afectar al código principal en el cual sigue trabajando otra parte del equipo.

Subiendo cambios al repositorio

Para publicar los cambios que tenemos en nuestro entorno de trabajo local y subirlo al repositorio remoto, utilizamos el comando push, como sigue (también aclaramos que queremos subir los cambios al origen llamado “master”, en este caso):

git push origin master

Resumen

Luego de hacer los commit en nuestro entorno local, entonces, podemos hacer un pull —para descargar los últimos cambios que pueda haber hecho otra persona al repositorio remoto— y luego un push, para subir nuestros cambios locales al repositorio remoto —de forma tal que luego nuestros colegas puedan hacer pull de nuestros cambios hacia sus respectivos entornos locales—.

Esperamos que todo esto les sirva para hacer más y mejores tiendas online con OmbuShop!

Personalización de emails automáticos

  • Facebook
  • Twitter
  • LinkedIn
  • StumbleUpon
  • Email
  • RSS

Una funcionalidad que muchas tiendas nos han pedido es la posibilidad de enviar emails personalizados cuando un cliente realiza una compra. Hoy lanzamos esta nueva función.

A continuación, les explico cómo configurar los emails personalizados de su tienda:

  • En el panel de administracion de la tienda, ingresar a la pestaña Diseño y luego hacer click en la opción Personalizar.
Menu del panel de administración

Menu del panel de administración

  • En la columna HTML, buscar la sección denominada Email Templates.
Selección de email template

Selección de email template

  • En esta sección, veremos que hay cuatro opciones disponibles. Cada una de estas contiene una descripción explicando cuándo se envía el email al cliente.
  • Por ejemplo, si queremos modificar el email que se envía cuando se marca el envío como enviado, tenemos que editar shipped_email.liquid
  • Una vez elegido el email a editar, se abrirá una nueva ventana mostrando el email con formato Liquid para que podamos editar libremente.
Editar email personalizado

Editar email personalizado

  • Finalmente, hacemos click en Guardar y volver para guardar los cambios. En este caso, cuando un cliente compre uno de nuestros productos y lo enviemos, el email que personalizamos será el que se le envíe.

A partir de hoy puedes personalizar los siguientes emails:

  • Email de confirmación de compra con pago online: Este email se envía cuando un cliente realiza una compra utilizando un gateway de pagos online.
  • Email de confirmación de pedido con pago offline: Este email se envía cuando un cliente realiza un pedido con pago en efectivo o contra entrega (offline)
  • Email de confirmación de envío: Este email se envía cuando envías el pedido a tu cliente, luego de confirmar el pago. Le avisa a tu cliente que el pedido ya está en camino.
  • Email de cancelación de pedido: Este email se envía cuando cancelas un pedido. Puede ser que ya no tengas stock o que el cliente se haya arrepentido de concretar la compra.

Usabilidad vs UX

  • Facebook
  • Twitter
  • LinkedIn
  • StumbleUpon
  • Email
  • RSS

Existe una confusión muy difundida en el rubro acerca de lo que significan los términos Usabilidad y UX. La gran mayoría de los profesionales los utilizan de forma indistinta, como si fueran sinónimos, cuando no lo son.

Ambos términos determinan la calidad de una interfaz. Los usuarios interactúan diariamente con nuestras interfaces y están a merced de nuestras decisiones de diseño. En muchos casos logran sus objetivos, en otros no. A veces disfrutan el uso de nuestras interfaces, a veces no.

Definiremos a continuación qué significa cada uno de estos términos, para evitar confusiones futuras y comprender en mayor profundidad la problemática de la interacción.

Usabilidad

Veamos las definiciones oficiales que promueve ISO:

  • “La usabilidad se refiere a la capacidad de un software de ser comprendido, aprendido, usado y ser atractivo para el usuario, en condiciones específicas de uso”
  • “Usabilidad es la eficacia, eficiencia y satisfacción con la que un producto permite alcanzar objetivos específicos a usuarios específicos en un contexto de uso específico”

En ambos casos, hablamos de la posibilidad de uso. Hablamos de la funcionalidad del producto. ¿Puede un usuario cumplir sus objetivos, utilizando el producto en cierto contexto real específico? ¿Cuán ardua es la curva de aprendizaje? ¿Pudo concluir la tarea satisfactoriamente?

La eficacia se corresponde con la capacidad de alcanzar el objetivo esperado, mientras que la eficiencia tiene que ver con el esfuerzo necesario para alcanzar dicho objetivo: la idea es cumplir un objetivo con el mínimo de recursos disponibles y en un tiempo razonable.

UX – User eXperience

La experiencia de usuario, por otro lado, radica en la percepción —positiva o negativa— que se tiene del producto durante y después de su uso. Esto va más allá de si el usuario pudo completar el objetivo propuesto o no.

Lo ideal es lograr que el usuario termine los objetivos, pero además se lleve una percepción positiva con respecto al uso del producto, lo que sin dudas ayudará a que lo vuelva a elegir o usar en situaciones futuras.

El uso de nuestros productos —en nuestro caso particular se trata de sitios web, aplicaciones web y tiendas online— debe ser grato. Queremos que nuestros usuarios tengan un recuerdo positivo de su experiencia.

Los invitamos a tener en cuenta tanto la Usabilidad como la UX de sus sitios y tiendas online! Por clientes felices!

Tipografía y diagramación responsive con CSS

  • Facebook
  • Twitter
  • LinkedIn
  • StumbleUpon
  • Email
  • RSS

Que el diseño web ha cambiado mucho en los últimos años no es novedad. La aparición de dispositivos de diversos tamaños capaces de navegar la web, obligó a cambiar el paradigma de diseño de páginas. Nuestras herramientas gráficas como grillas y niveles de lectura, entre otras, deben ser actualizadas.

Tradición gráfica

La diagramación básica de los sitios web que utilizamos aún hoy, viene de una larga tradición gráfica que data de los tiempos de Gutenberg, e incluso más atrás en el tiempo.

Gutenberg Bible

El concepto de una grilla que sostiene la estructura de la página —márgenes, columnas, calles— nos precede. Ya incluso Gutenberg y sus seguidores imitaron los incunables que realizaban los copistas previos a la utilización de prensas con tipos móviles.

Muchos siglos después, cuando los diseñadores gráficos comenzamos a trabajar en este nuevo medio llamado World Wide Web, utilizamos las mismas convenciones gráficas para el diseño de páginas web. Creamos grillas utilizando ciertas medidas, múltiplos y submúltiplos para poder armar el layout de nuestras páginas según la mejor tradición gráfica que todo lector estaba acostumbrado a interpretar.

El desafío

Una de las problemáticas gráficas a resolver en cuanto a la diagramación de páginas web fue la falta de un formato fijo: es decir, dimensiones de ancho y alto fijas para el plano en el que debíamos trabajar.

La solución que se extendió fue la de “simular” una página tangible dentro del navegador web. Por medio de etiquetas de HTML se definía un área, que luego se diseñaba con CSS para mantener ciertas medidas fijas de ancho y alto, de forma tal que el diseñador pudiese trabajar como siempre: sobre una hoja. Incluso la apariencia de dicha área dentro del navegador en muchos casos se asimilaba a la de una hoja que descansaba sobre un fondo (en muchos casos con una textura, como si se tratara de una hoja blanca sobre un escritorio).

Este punto fue el origen del mal: convirtió al HTML —que era responsive por naturaleza— en un formato fijo que simulaba las características del mundo tangible.

Browser fixed width

¿Cuál es el problema con esta solución a la falta de dimensiones para trabajar? Mientras utilizábamos computadoras de escritorio con monitores de tamaños más o menos estandarizados, ninguno. El problema empezó cuando aparecieron los dispositivos móviles con pantallas de tamaños muy diversos: en muchos casos esta “hoja” ficticia a la cual asignábamos un tamaño fijo ya no entraba en las dimensiones de la pantalla, por lo que el usuario estaba obligado a hacer scroll hacia los costados para leer cada una de las líneas de un párrafo.

Situación actual

Hoy en día, que una página web sea responsive —es decir, que su diagramación y el tamaño de sus elementos responda al tamaño de la ventana del navegador o dispositivo en cuestión— dejó de ser una opción; se trata de una necesidad.

Los sitios web que diseñamos deben verse bien en monitores grandes, medianos, pequeños, tabletas, celulares y cuanto dispositivo ande dando vueltas por el mundo.

Esto nos obliga a repensar la situación de la “hoja” ficticia y volver a las bases: una página web como formato que nos permite un diseño que se adapte a las necesidades de cada usuario.

Medidas absolutas no, proporciones sí

La forma en la que tradicionalmente armábamos el layout, con diferentes columnas y áreas de contenidos era a través de medidas absolutas expresadas en pixels. Por lo general se trataba de los anchos de las cajas (width).

Si queremos que nuestro layout sea responsive por completo, debemos comenzar a expresar las medidas como proporciones relativas, antes que como medidas absolutas. A continuación, en ejemplo que muestra la manera de expresar dos columnas paralelas sin especificar ninguna medida de forma absoluta.


#contenedor {
margin: 20px auto;
width: 80%;
background: #000;
padding: 20px;
font-family: Helvetica, Arial, sans-serif;
overflow: auto;
}

#principal {
float: left;
width: 70%;
background: #2BA47D;
}

#secundario {
float: right;
width: 28%;
margin-left: 2%;
background: #ffffdf;
}
See the Pen <a href=’http://codepen.io/lucasmourelle/pen/wiIfs/’>wiIfs</a> by Lucas Mourelle (<a href=’http://codepen.io/lucasmourelle’>@lucasmourelle</a>) on <a href=’http://codepen.io’>CodePen</a>.

Media Queries

Cuando se utilizan medidas en porcentaje, se definen proporciones que pueden quedar mal en casos límite como monitores muy pequeños (o muy grandes). La forma de evitar estos problemas es a través de la tecnología de CSS llamada Media Queries, que nos permite definir ciertas reglas siempre y cuando se cumpla una condición (por ejemplo de tamaño del monitor):


#contenedor {
margin: 20px auto;
width: 80%;
background: #000;
padding: 20px;
font-family: Helvetica, Arial, sans-serif;
overflow: auto;
}

#principal {
float: left;
width: 70%;
background: #2BA47D;
}

#secundario {
float: right;
width: 28%;
margin-left: 2%;
background: #ffffdf;
}

@media screen and (max-width: 500px) {
#principal {
float: none;
width: 100%;
margin-bottom: 20px;
}

#secundario {
float: none;
width: 100%;
margin-left: 0;
}
}

See the Pen <a href=’http://codepen.io/lucasmourelle/pen/ljBFi/’>ljBFi</a> by Lucas Mourelle (<a href=’http://codepen.io/lucasmourelle’>@lucasmourelle</a>) on <a href=’http://codepen.io’>CodePen</a>.

En el ejemplo se ve cómo al achicar la ventana del navegador a una situación posiblemente problemática, las columnas dejan de estar una al lado de la otra y pasan a ocupar todo el ancho disponible.

Cuerpo tipográfico relativo

Para poder controlar de forma relativa y fácilmente el tamaño del texto —es decir: el cuerpo tipográfico— lo que podemos hacer es definir una medida base, en pixels, para la etiqueta body, y luego indicar el font-size de cada uno de los elementos de la página de forma relativa a dicha medida. Para esto, podemos expresar las medidas subsiguientes en la unidad de medida llamada em.


h1, h2, h3 {
font-weight: bold;
font-size: inherit; /* reset browser sizes */
}
body {
font-family: Helvetica, Arial, sans-serif;
font-size: 16px;
line-height: 1.4;
}
h1 {
font-size: 2em; /* 32px */
}
h2 {
font-size: 1.5em; /* 24px */
}
h3 {
font-size: 1.25em; /* 20px */
}
p {
font-size: 1em; /* 16px */
}

See the Pen <a href=’http://codepen.io/lucasmourelle/pen/miaks/’>miaks</a> by Lucas Mourelle (<a href=’http://codepen.io/lucasmourelle’>@lucasmourelle</a>) on <a href=’http://codepen.io’>CodePen</a>.

Los invitamos a realizar maravillosas tiendas responsive en OmbuShop!

CSS Atómico

  • Facebook
  • Twitter
  • LinkedIn
  • StumbleUpon
  • Email
  • RSS

¿Cómo mejorar la organización de código y archivos CSS siguiendo el paradigma orientado a objetos?

Hablamos en posts anteriores acerca de CSS Orientado a Objetos  —una manera de organizar el código CSS— y de pre-procesadores, haciendo especial hincapié en SASS —una tecnología que extiende las posibilidades del CSS estándar—.

Además de una organización del código que entiende a los elementos de diseño como objetos, la posibilidad de fragmentar el código en diferentes archivos nos presenta un nuevo desafío. ¿Con qué criterio hacer esta división? ¿Cómo optimizar los tiempos de mantenimiento a futuro?

Diseño Atómico

En su artículo Atomic Design, Brad Frost nos propone una manera posible de entender el diseño de un sitio web.

La idea se basa en comprender al diseño web como la confección de sistemas de diseño, antes que páginas diseñadas. Brad Frost entiende a cada página web como un conjunto de organismos que interactúan entre sí, a su vez conformados por unidades más pequeñas.

Guiado por esta mirada particular, decide utilizar la metáfora de la química molecular para la organización de organismos, aprovechando la posibilidad de SASS de separar el código en distintos archivos. Plantea 5 carpetas organizadoras:

  1. Átomos
  2. Moléculas
  3. Organismos
  4. Plantillas
  5. Páginas

Inspirado en esta idea, Robin Rendle realiza algunas modificaciones sobre este modelo, continuando la misma lógica.

Robin realiza una división distinta, acorde a su flujo de trabajo y expone la siguiente variación:

  1. Utilidades
  2. Quarks
  3. Átomos
  4. Moléculas

Como verán, la idea es la misma, con algunos cambios de acuerdo a su gusto y mecánica de trabajo.

OmbuShop’s way

También en OmbuShop estuvimos trabajando con una visión orientada a objetos para el manejo de CSS, y comenzamos a utilizar un ordenamiento atómico propio para nuestras hojas de estilo SASS.

Nuestra síntesis incorpora elementos de ambas variaciones, a saber:

  1. Utilidades (utilities)
  2. Quarks
  3. Átomos (atoms)
  4. Moléculas (molecules)
  5. Páginas (pages)
  6. Vendor

¿Qué incluimos en cada una?

A continuación, una breve descripción de qué fragmentos del diseño se corresponden por cada una.

Por lo general, escribimos en inglés lo relacionado con código, por lo que listaré las carpetas in english. Asímismo, incluimos números al comienzo del nombre de cada carpeta, de forma que siempre se mantengan ordenadas de menor a mayor complejidad.

1-utilities

En esta carpeta incluiremos código genérico que será utilizado por los demás archivos. Definición de variables, mixins, el código básico para el body, grillas para el layout, etc.

2-quarks

Aquí estará el código que da estilo a unidades mínimas: cuestiones tipográficas como párrafos, títulos, listas, links, etc.

Por lo general los selectores en este nivel se refieren a etiquetas de HTML de forma genérica.

3-atoms

En este nivel los elementos diseñados empiezan a ganar complejidad.

Se trata de estilar elementos pequeños pero específicos: botones, formularios, elementos tipográficos más complejos, etc.

4-molecules

Las moléculas son elementos de mayor complejidad, conformados por unidades más pequeñas.

Algunos ejemplos pueden ser un cuadro de diálogo, una botonera de navegación o el footer de un sitio.

En este caso, cada archivo podría tener varios elementos (que son los constitutivos de la molécula total. Aquí es imprescindible hacer uso de la capacidad de nesting de SASS, si queremos mantener ese diseño encapsulado sin afectar a terceros.

5-pages

En este nivel se puede incluir código particular que afecta y varía el diseño de una página a otra de un sitio.

Cuando se trata de una modificación transversal, que incluso puede afectar a las moléculas anteriores.

Un cambio de paleta cromática de acuerdo a la sección del sitio, por ejemplo.

vendor

Siempre es útil reservar una carpeta con archivos SASS y CSS que sean de terceros. Por ejemplo librerías que han sido descargadas, frameworks, grillas, etc.

Si utilizas bootstrap, por ejemplo, puedes crear una carpeta bootstrap dentro de vendor.

Moraleja

Conviene tener un archivo SASS por fuera de estas carpetas, que se encargue de importar cada uno de los archivos que está en su interior, algo así:


// Vendor
@import &quot;vendor/bootstrap/bootstrap&quot;;

// 1-UTILITIES
@import &quot;1-utilities/variables&quot;;
@import &quot;1-utilities/basic&quot;;
@import &quot;1-utilities/grid&quot;;

// 2-QUARKS
@import &quot;2-quarks/typography&quot;;
@import &quot;2-quarks/links&quot;;
@import &quot;2-quarks/icons&quot;;

// 3-ATOMS
@import &quot;3-atoms/buttons&quot;;
@import &quot;3-atoms/forms&quot;;

// 4-MOLECULES
@import &quot;4-molecules/header&quot;;
@import &quot;4-molecules/footer&quot;;
@import &quot;4-molecules/floors&quot;;
@import &quot;4-molecules/quotes&quot;;
@import &quot;4-molecules/popups&quot;;

// 5-PAGES
@import &quot;5-pages/contact_page&quot;;

See the Pen <a href=’http://codepen.io/lucasmourelle/pen/DEquG/’>DEquG</a> by Lucas Mourelle (<a href=’http://codepen.io/lucasmourelle’>@lucasmourelle</a>) on <a href=’http://codepen.io’>CodePen</a>.

Dominado el lenguaje CSS para el estilado de sitios web y habiendo comenzado a utilizar pre-procesadores, la preocupación principal de todo frontender profesional actual es cómo organizar el código para que sea future-proof y de fácil mantenimiento.

¡A darle átomos!