OmbuShop Crea Tu Tienda Online

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!

SASS y otros preprocesadores de CSS

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

Los preprocesadores de CSS han llegado para quedarse. Son tecnologías que nos permiten escribir código CSS de forma optimizada, agregando funcinalidades tales como variables, mixins y cálculos al universo de las hojas de estilo!

Como sabemos, el desarrollo web front-end utiliza tres tecnologías básicas a saber:

  • HTML para el marcado semántico del contenido.
  • CSS para la presentación de dichos contenidos (el diseño).
  • JavaScript para la programación del comportamiento de dicho contenido diseñado.

Si bien CSS siempre fue una tecnología elegante, que basa parte de su belleza en el minimalismo de sus features y sintaxis, es evidente que el agregado de algunas funcionalidades no vendría mal.

Por ejemplo: todo diseñador sabe que trabajar con una paleta cromática controlada es clave. Consecuentemente, muchos elementos de un sitio web comparten los mismos colores. Es muy probable que el diseñador haya elegido 5 colores básicos, y que luego cientos de elementos en un sitio web se construyan combinando dichos colores.

Ahora bien, el resultado técnico de esta situación es la repetición en tantísimas ocasiones del mismo código de color en la hoja de estilos. Si el diseño es sistemático, lo mismo ocurrirá con medidas y otros valores en el código CSS.

Bondades de los preprocesadores

Sass and Less

Los preprocesadores como SASS o Less, vienen a solucionar este tipo de problemas, agregando funcionalidad al código CSS. Daremos ejemplos utilizando SASS, pero Less tiene características similares.

Variables

El concepto de variables es el mismo que conocemos para JavaScript y otros lenguajes de programación. Permite guardar momentáneamente cierto valor, para ser utilizado luego.

En el caso de CSS, nos permite por un lado evitar la repetición de valores (por ejemplo un color, una familia tipográfica o una medida), y por otro centralizar dicho dato de forma tal que para su modificación haya que cambiar el valor una sola vez.

Aquí un ejemplo:


$color_principal: #fff;
$color_secundario: #2BA47D;
$tamano_texto: 30px;

body {
color: $color_principal;
background: $color_secundario;
font-size: $tamano_texto;
}

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

Cálculos

La posibilidad de realizar cálculos también agiliza el trabajo. Podemos sumar (+), restar (-), multiplicar (+) y dividir (/).

Los cálculos pueden realizarse entre números o entre variables que contengan información numérica.


$ancho_total: 600px;
$ancho_principal: 400px;
$calle: 20px;
#contenedor {
width: $ancho_total;
background: #000;
padding: $calle;
font-family: Helvetica, Arial, sans-serif;
overflow: auto;
}
#principal {
float: left;
width: $ancho_principal;
background: #2BA47D;
}
#secundario {
float: right;
width: $ancho_total – $ancho_principal – $calle;
background: #ffffdf;
}

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

Nesting

Teniendo en cuenta la naturaleza de un elemento dentro de otro en el HTML, es muy común que los selectores de CSS se vuelvan algo así muy pronto:


ul {
font-family: sans-serif;
background: #000;
color: #fff;
margin: 20px 0;
padding: 5px;
}
ul li {
margin: 5px;
padding: 10px;
background: #444;
}
ul li a {
display: block;
color: inherit;
text-decoration: none;
}

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

SASS permite introducir un elemento dentro de otro tal como hacemos en el código HTML. Esto facilita el trabajo generando una situación análoga a la que tenemos en el marcado semántico:


ul {
font-family: sans-serif;
background: #000;
color: #fff;
margin: 20px 0;
padding: 5px;
li {
margin: 5px;
padding: 10px;
background: #444;
a {
display: block;
color: inherit;
text-decoration: none;
}
}
}

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

Mixins

En ciertas ocasiones el código a repetir en un archivo CSS es más que simplemente un valor. Los mixins nos permiten centralizar la escritura de varios renglones de CSS, para luego insertarlo donde queramos.


@mixin lato_light {
font-family: &#x27;Lato&#x27;, sans-serif;
font-weight: 300;
}
p {
@include lato_light;
}

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

Los mixins también permiten la inclusión de parámetros, de forma que no siempre el código generado es idéntico.


@mixin open_sans_light($size){
font-family: &#x27;Open Sans&#x27;, sans-serif;
font-weight: 300;
font-size: $size;
}
p {
@include open_sans_light(20px);
}

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

Herencia

SASS también permite que ciertos elementos “hereden” el estilo de otros, la sintaxis es la siguiente:


.boton {
font-family: sans-serif;
border-radius: 3px;
padding: 8px;
display: inline-block;
text-decoration: none;
padding: 10px;
color: #000;
}
.boton-importante {
@extend .boton;
background: #f00;
}

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

De esta manera, la clase boton-importante recibe todas las características de la clase boton.

Import

Otra posibilidad es la de dividir en diferentes archivos para organizar el código. Podemos tener un archivo estilos.scss, y luego otro llamado _reset.scss; el guión bajo al principio del nombre indica que se trata de un “partial”, un archivo parcial que luego será importado dentro de otro.

_reset.scss


/* Archivo: _reset.scss */
* {
margin: 0;
padding: 0;
}

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

estilos.scss


/* Archivo: estilos.scss */
@import &#x27;reset&#x27;;

p {
font-family: &#x27;Lato&#x27;, sans-serif;
}

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

El archivo resultante estilos.css, tendrá el código de estilos.scss, con el código de _reset.scss importado en el lugar indicado.

Pero ¿cómo funciona en los navegadores?

El código SASS, aunque muy parecido al de CSS nativo, no puede ser interpretado por los navegadores.

El código sirve para el desarrollo, pero luego debe ser compilado por estos pre-procesadores, transformándolo en CSS estándar.

Con cada cambio que hace el diseñador/desarrollador al código SASS, los preprocesadores generan automáticamente la versión CSS. Por lo general ocurre en tiempo real y de forma automática en el entorno de desarrollo.

Para más información al respecto, no dejen de visitar el sitio web oficial de SASS!

¡A continuar diseñando tiendas increíbles!