Café Arona: un sitio Shopify para una empresa familiar

Una familia de Sherbrooke me contrató para trabajar en el sitio web de Café Arona, una empresa que busca dar a conocer el café camerunés en Quebec. El proyecto ya tenía una historia, una identidad visual y un equipo. El encargo consiste en darles un lugar claro en la web y una estructura de contenido que el equipo pueda administrar.

El sitio presenta la historia de la empresa, sus valores, su equipo y los artículos aportados por el cliente. El tema también incluye componentes de catálogo: colecciones, fichas de producto, selección de opciones, búsqueda y carrito. Los textos y las imágenes se organizan en secciones previstas para editarse desde Shopify.

Mi trabajo incluye la migración del sitio existente en Webflow a Shopify, la organización de los contenidos y el desarrollo del tema. En su estado actual, Café Arona es un sitio informativo en desarrollo, sin apertura de ventas ni entrega de Shopify al cliente. Esto es lo que está construido, cómo funcionan sus partes y los principios para administrarlas.

Presentar a las personas detrás del café#

La historia de Café Arona une a Camerún y Quebec a través de las personas que están construyendo la empresa. Por eso, las páginas de historia, valores y equipo tienen un lugar importante dentro del sitio.

Organicé estos contenidos en formatos con propósitos distintos. Una página cuenta cómo nació el proyecto. Otra presenta sus valores. La página del equipo reúne una foto de grupo, retratos y textos de presentación. El blog ofrece un espacio para los artículos que aporta el cliente y complementa las páginas de contenido más permanente.

Así, cada visitante puede conocer quiénes están detrás de la empresa antes de explorar sus productos. Puede leer un artículo con calma o encontrar cómo comunicarse con el equipo. Ese recorrido tiene una utilidad propia: presentar al negocio y su contexto antes de abrir las ventas en línea.

Una identidad existente, contenidos editables#

Los colores, las fotografías y la tipografía existentes sirven como punto de partida. La migración lleva esa identidad a un tema de Shopify, con páginas que el cliente podrá actualizar desde su administración.

La relación entre presentación y administración guía el trabajo. Un título necesita un lugar en el diseño y un sitio fácil de reconocer donde se pueda editar. Una fotografía debe funcionar en una pantalla pequeña y poder reemplazarse sin reconstruir la página. Una ficha debe presentar los datos del café y leerlos desde campos que puedan mantenerse al día.

Shopify reúne esas necesidades de contenido con las funciones previstas para la futura tienda. El tema ya incluye colecciones, fichas de producto, búsqueda y carrito. Su existencia describe el trabajo construido; no significa que el catálogo definitivo esté cargado ni que las ventas estén abiertas.

Las secciones desplegables permiten elegir el nivel de detalle. Cada una explica una parte del sitio: su propósito, cómo funciona y qué se debe revisar al modificarla.

Lo que está construido y lo que sigue#

Café Arona cuenta con un sitio de desarrollo, páginas de presentación y un tema que relaciona contenidos editables, fichas, variantes y una estructura bilingüe. Las decisiones técnicas sirven para tareas concretas: saber dónde cambiar un dato, dónde se refleja y qué revisar después.

La siguiente etapa contempla integrar el catálogo definitivo, validar los recorridos destinados a la venta y entregar el sitio con su documentación y capacitación. Esas incorporaciones utilizarán la estructura que ya está construida.

El sitio utiliza un tema Liquid de Shopify, desarrollado a partir de la base Skeleton. Liquid combina los contenidos administrados por Shopify con los elementos del tema. El navegador recibe una página HTML, su presentación en CSS y los comportamientos necesarios en JavaScript. Esta organización responde al encargo: un sitio informativo cuyos contenidos y futuro catálogo se administran desde el mismo lugar.

El tema tiene varios niveles. Una estructura común ubica el encabezado, el contenido principal y el pie de página. Las plantillas JSON indican qué secciones componen una familia de páginas. Las secciones contienen elementos visibles, como el banner de inicio o la presentación del equipo. Otros componentes pequeños y reutilizables se encargan de detalles compartidos, como un botón o un precio.

Cada nivel tiene una responsabilidad. Cambiar el estilo de un botón compartido puede afectar varias páginas. Cambiar el texto de un botón dentro de una sección modifica el contenido de esa sección. Confundir las dos cosas llevaría a acumular excepciones en el código o a necesitar desarrollo para corregir una frase.

Lo que el editor permite modificar#

Las secciones declaran su configuración: textos, imágenes, enlaces y opciones previstas por el tema. El siguiente ejemplo mínimo fue escrito para este artículo y es distinto del código del proyecto. Representa un título y una dirección que se quieren hacer editables:

{
  "name": "Introduction",
  "settings": [
    { "type": "text", "id": "intro_title", "label": "Titre" },
    { "type": "url", "id": "intro_destination", "label": "Lien" }
  ]
}

En el ejemplo, intro_title e intro_destination son identificadores estables. El cliente trabaja con las etiquetas visibles del editor. Puede cambiar el contenido sin tener que encontrar una línea de HTML.

La estructura visual sigue definida por el tema. Agregar una interacción nueva o una nueva familia de páginas requiere desarrollo. La autonomía prevista corresponde a tareas reconocibles: corregir una frase, reemplazar una imagen, actualizar una presentación o cambiar el destino de un enlace.

Cuando una plantilla es compartida#

Si dos páginas usan la misma plantilla, cambiar su composición puede afectar a ambas. Antes de editar, hay que distinguir el contenido propio de cada página de la estructura compartida. La documentación de entrega debe explicar ese alcance.

Un mapa breve de edición ayuda a hacerlo concreto: biografías en la sección del equipo, artículos en el blog y datos del café en el catálogo y sus campos personalizados. El lugar correcto depende del tipo de información, no solamente de dónde aparece en la pantalla.

Un catálogo no se reduce a una serie de tarjetas con nombres y precios. Cada objeto necesita una definición clara. Un producto reúne una presentación común. Una variante identifica una combinación específica de opciones seleccionables. Una colección agrupa productos para la navegación. Un campo personalizado describe una característica adicional.

En Café Arona, la estructura de colecciones contempla café verde, café tostado y mercancía. Esa organización les da un lugar a las categorías del proyecto; no anuncia que todos esos productos estén disponibles. El contenido definitivo y su estado de publicación deben corresponder a las decisiones confirmadas del cliente.

¿Descripción, opción o dato de inventario?#

El origen y las notas de sabor describen el producto. Una presentación o preparación puede distinguir una variante. La cantidad disponible corresponde a unidades específicas. Mezclar estos datos en un solo párrafo puede hacer que la página parezca completa mientras la información necesaria para administrarla sigue incompleta.

El tema tiene una ficha que muestra campos personalizados y trata de manera distinta los valores individuales y las listas. Las notas de sabor pueden aparecer como varios elementos. Este ejemplo en Liquid es independiente del código del proyecto:

{% for tasting_note in coffee_notes %}
  <span>{{ tasting_note | escape }}</span>
{% endfor %}

Aquí, coffee_notes representa una lista y tasting_note una nota a la vez. El filtro escape muestra cada valor como texto y no como código HTML. El ejemplo explica cómo una misma presentación puede recibir información distinta. No decide cuáles sabores describen el café: esos valores deben venir de productos confirmados y textos aprobados.

No todos los campos están destinados al público. La información que se mostrará debe separarse de las notas internas de trabajo. Por eso, la incorporación del catálogo debe revisar lo que realmente aparece en la ficha, además del formulario utilizado para ingresar los datos.

Un ejemplo de combinaciones#

Tomemos un caso ficticio, sin relación con las presentaciones definitivas de Café Arona: dos tamaños, A y B, y dos preparaciones, en grano o molida. Eso da 2 × 2 = 4 combinaciones posibles. Si solo tres están aprobadas, la cuarta no debe aparecer como una variante que simplemente está agotada. Todavía no es una oferta confirmada.

La diferencia también importa para las imágenes y los precios. Cada selección debe conservar el identificador correcto de la variante, mostrar sus datos y evitar reutilizar silenciosamente los de otra opción. La cantidad del carrito corresponde a la variante elegida, no al nombre general del café.

Esta estructura separa los componentes ya construidos de los datos que muestran. Se puede incorporar un catálogo confirmado sin reconstruir la presentación de cada ficha. El esquema de edición se mantiene, mientras los valores y las variantes corresponden a cada producto.

Una colección vacía es distinta de una búsqueda sin resultados#

Una colección organiza el acceso a los productos. Su plantilla presenta una cuadrícula, controles de filtrado y paginación cuando hace falta. También contempla dos situaciones que pueden verse parecidas, pero necesitan explicaciones distintas: la colección no tiene productos o los filtros elegidos no producen resultados.

En el primer caso, la persona necesita entender para qué sirve esa sección y dónde puede continuar. En el segundo, debe comprender que su selección limita los resultados y poder modificarla. Utilizar el mismo mensaje en ambos casos podría sugerir que un filtro hizo desaparecer el catálogo o que una sección vacía se soluciona cambiando opciones.

El tema representa esa diferencia mediante mensajes de estado compartidos. Su estructura visual se mantiene, mientras el título, la explicación y la acción corresponden a cada situación. Es una reutilización útil: el componente maneja la presentación y los datos de la colección determinan el sentido del mensaje.

La revisión de una colección incluye entonces su presentación normal, la paginación y los estados sin contenido. También debe revisar los enlaces a las fichas. La persona recorre varias vistas del mismo catálogo; la coherencia va más allá de una tarjeta de producto aislada.

Un producto visible no necesariamente se puede comprar. Una ficha puede presentar una oferta futura. Una variante puede existir sin estar disponible. Una cantidad puede ser insuficiente para la solicitud. Esas situaciones requieren mensajes y acciones diferentes.

El tema prepara un estado inicial del lado de Shopify cuando se genera la página. Después, el JavaScript del navegador responde a la selección de opciones: busca la variante correspondiente y actualiza la información visible. Lo importante es mantener la coherencia entre esos dos momentos. Una regla aplicada al cargar la página debe seguir aplicándose después de cambiar la selección.

Expresar la regla con claridad#

El siguiente modelo fue escrito para el artículo y explica esa diferencia. Representa una regla que debe verificarse antes de abrir las ventas; no es el código desplegado del proyecto:

function purchaseState({ salesEnabled, productApproved, variant }) {
  if (!salesEnabled || !productApproved) return "information";
  if (!variant) return "unavailable";
  return variant.available ? "available" : "sold_out";
}

El modelo revisa primero si las ventas y el producto están autorizados, después si la variante existe y, por último, si está disponible. Los identificadores son ilustrativos. Lo importante es el orden del razonamiento: tener inventario disponible no debe anular la decisión de presentar un producto únicamente como información.

Cuatro situaciones producen expectativas distintas:

• Ventas sin abrir: la página puede informar sin ofrecer la compra.
• Producto confirmado y combinación inexistente: explicar que esa selección no se ofrece.
• Variante existente pero no disponible: comunicar ese estado sin presentarlo como un error del sitio.
• Variante disponible dentro de un recorrido de venta autorizado: permitir continuar, sujeto a la validación final del carrito.

Para verificar este comportamiento, hay que revisar las mismas reglas en la presentación inicial, al cambiar una opción y al solicitar agregar al carrito. Un botón desactivado en una captura no demuestra todo ese recorrido. El escenario útil es una selección que cambia: el mensaje, la variante y la acción permitida deben seguir siendo coherentes.

La solicitud y su respuesta#

El navegador envía una solicitud para agregar al carrito y recibe una respuesta de Shopify. Mientras llega esa respuesta, la interfaz debe distinguir una solicitud en curso de una adición confirmada. Un rechazo por cantidad y un problema de red necesitan explicaciones diferentes.

También hay que diferenciar la adición del producto de la actualización visual del carrito. Si la primera funciona, pero el contador no se actualiza, repetir automáticamente la solicitud podría agregar el producto dos veces. La respuesta visual debe seguir lo que el sistema realmente confirmó.

Esto vuelve concreta la validación: probar un cambio de variante, una combinación ausente, una cantidad rechazada y una respuesta lenta. Esos comportamientos no se comprueban mirando solamente la página en su estado normal.

La disponibilidad mostrada también corresponde a un momento. El inventario puede cambiar mientras la persona elige las opciones. La validación del navegador ayuda a orientar esa selección, pero una solicitud rechazada por el servicio sigue rechazada aunque el botón estuviera activo un instante antes. El mensaje debe permitir retomar el recorrido sin presentar la información anterior como una confirmación de pedido.

El tema puede mostrar un precio, disponibilidad y varias opciones. Para que esos elementos tengan sentido, sus datos deben describir la misma variante y el mismo estado del producto. La pregunta va más allá de la apariencia: qué se cuenta, quién confirma la información y cuál dato se utiliza para mostrarla.

Un conteo de unidades físicas, una cantidad reservada y la disponibilidad no son intercambiables. Una descripción y una fotografía aprobadas no reemplazan un conteo. Del mismo modo, una cantidad disponible no confirma el texto comercial ni las condiciones de envío.

La ficha de recepción del catálogo#

El modelo de recepción del catálogo contempla una fila por variante destinada a la venta. Esa fila debe relacionar nombre, opciones, presentación, precio aprobado, imagen, cantidad y estado. También debe permitir identificar quién confirmó la información. Los ejemplos de este artículo no incluyen datos operativos del cliente.

Un dato ausente sigue pendiente de confirmación. Reemplazarlo por un valor que parezca razonable borraría la diferencia entre un ejemplo de diseño y una oferta real. La misma regla aplica a las traducciones y a las descripciones de sabor.

Un cálculo ficticio para entender el control#

Imaginemos, únicamente para ilustrar el método, 40 unidades terminadas contadas físicamente, entre ellas 6 reservadas y 2 que no se pueden vender. Si esas categorías son distintas y están incluidas en las 40 iniciales, quedarían 40 − 6 − 2 = 32. Este cálculo no describe ningún inventario de Café Arona.

El propósito del ejemplo es precisar las definiciones. Si un sistema ya informa la cantidad disponible después de las reservas, restar nuevamente las seis unidades introduciría un error. Antes de comparar una hoja de cálculo con Shopify, hay que verificar qué cuenta cada columna, a cuál variante corresponde y cuándo se hizo el registro.

Integrar por etapas controladas#

El catálogo puede incorporarse primero con un conjunto pequeño y representativo: una ficha con sus opciones, campos, imágenes y traducciones. La vista previa permitirá revisar lo que realmente produce esa estructura. Una vez confirmado el modelo de ingreso, las demás fichas podrán seguir el mismo esquema.

Este método se refiere a la calidad de los datos recibidos. La arquitectura de presentación ya está construida; la revisión sigue las relaciones entre productos, colecciones, variantes y cantidades. Permite comprobar el resultado de un registro sin confundir su apariencia con su validez.

El francés es el idioma principal del proyecto. El tema también incluye archivos de idioma y un mecanismo para cambiar a inglés. Esa base prepara el uso bilingüe, pero varias clases de contenido deben conservar su coherencia.

Los textos de interfaz incluyen etiquetas de navegación, botones y mensajes de resultado o error. Los contenidos editoriales incluyen presentaciones, biografías y artículos. Los datos de producto abarcan descripciones, nombres de opciones y valores de campos personalizados. Actualizar una de estas familias no actualiza automáticamente las demás.

El selector del tema utiliza el formulario de localización de Shopify. Su función es solicitar un cambio entre los idiomas disponibles. Las direcciones de las páginas y las acciones del sitio deben continuar después en el idioma correspondiente. Un botón traducido que lleve al recorrido equivocado dejaría el trabajo incompleto.

Partir de un cambio de contenido#

Si el cliente modifica una descripción en francés, la revisión del inglés debe comprobar la misma información, no solamente que la frase suene natural. Una nota de sabor retirada, una presentación modificada o una condición de disponibilidad revisada necesitan un equivalente preciso.

También hay que diferenciar la etiqueta de un campo de su valor. Traducir «origen» no traduce necesariamente el contenido que aparece después. El tema lee datos que Shopify puede localizar; por eso, la edición debe revisar tanto el nombre que ve la persona como el valor mostrado.

Revisar un recorrido completo#

La revisión prevista sigue una página en ambos idiomas, después sus enlaces, mensajes y estados menos frecuentes. Incluye los contenidos largos que alteran la presentación y los errores que no aparecen al cargar inicialmente la página.

Este enfoque define la entrega bilingüe mediante contenidos y recorridos revisados. La existencia de archivos en inglés en el repositorio no demuestra que todas las actualizaciones del cliente estén traducidas. La administración bilingüe relaciona el contenido modificado, su traducción y el recorrido donde aparece.

La identidad de Café Arona utiliza contrastes de color, una tipografía marcada, fotografías y un banner de video. El trabajo consiste en conservar esa presencia y dar espacio al contenido y a las interacciones.

La página del equipo es un buen ejemplo. La fotografía grupal presenta a las personas en conjunto. Los retratos permiten seleccionar una presentación individual. En una pantalla estrecha, la composición debe seguir siendo legible sin exigir recorrer una cuadrícula pensada solamente para un monitor grande.

El tema tiene un comportamiento compartido para las interfaces de pestañas del equipo y los valores. Relaciona el elemento seleccionado con su panel de contenido y maneja comandos de teclado. La reutilización corresponde a un comportamiento común; las dos secciones conservan su propio contenido y presentación.

El foco también forma parte del recorrido#

Ver un retrato seleccionado y saber dónde está el foco del teclado son datos distintos. Las flechas, el inicio y el final de la lista y la visibilidad del panel deben funcionar de forma coherente. Las pruebas de lógica del proyecto cubren, entre otras reglas, el desplazamiento entre índices y la interpretación de teclas. No reemplazan el uso real de la página con teclado.

Lo mismo ocurre con un mensaje de error. Debe aparecer en el lugar adecuado y ser perceptible para alguien que no sigue solamente los cambios visuales. El tema incluye zonas de anuncio, pero hay que revisarlas junto con el comportamiento completo.

Imágenes, video y peso de la página#

Las imágenes principales y las miniaturas tienen funciones distintas. El tema solicita tamaños adecuados y reserva algunas dimensiones de presentación. El video del banner tiene una imagen de espera y su comportamiento tiene en cuenta la preferencia de reducir el movimiento. Esos mecanismos están en el código; su existencia no demuestra por sí sola un resultado de rendimiento medido.

Una imagen nítida en una pantalla grande puede ser más pesada de lo necesario. Un recorte que funciona en escritorio puede cortar un rostro en móvil. La revisión debe considerar el contenido realmente visible, los tamaños descargados y el comportamiento del navegador.

Las dos vistas de inicio seleccionadas para esta presentación provienen del navegador en el sitio de desarrollo. La vista móvil representa un ancho de navegador, no una prueba en un teléfono físico. Documentan la interfaz en esta etapa. No demuestran la validación de todos los tamaños de pantalla ni de todas las páginas.

Para que el cliente pueda mantener el sitio, necesita saber qué está cambiando y qué debe revisar después. Reemplazar una fotografía, modificar una estructura compartida y agregar una variante tienen alcances diferentes.

El flujo de entrega propuesto empieza por identificar el contenido, la persona que lo aprueba y el resultado esperado. Para cambios de presentación, una copia del tema permite preparar una vista previa antes de publicar. En un producto o artículo también hay que gestionar el contenido: copiar el tema no duplica automáticamente todos los datos de la tienda.

Ejemplo: reemplazar una fotografía del equipo#

La tarea no termina al seleccionar el archivo. Hay que confirmar la imagen correcta, el derecho a usarla, el texto alternativo y el recorte del sujeto. Luego se revisa la página completa: fotografía grupal, retratos, textos cercanos y presentación estrecha. Si cambia la leyenda, su versión en inglés entra en la misma revisión.

Este recorrido muestra la utilidad de campos bien definidos. Quien edita debe poder cambiar el contenido correspondiente sin tocar el comportamiento de las pestañas. El desarrollo interviene cuando la solicitud cambia la estructura o la interacción.

Ejemplo: preparar una ficha de producto#

Una ficha representativa permite recorrer el ciclo: datos confirmados, ingreso, presentación de campos, selección de opciones, idioma y disponibilidad. Una opción ausente debe producir el resultado previsto. Una imagen faltante no debería pasar inadvertida solo porque el resto de la página funciona.

Las pruebas automatizadas del proyecto cubren algunas funciones del carrito y de la navegación por pestañas. Ayudan a verificar reglas precisas, como el tratamiento de un índice o la clasificación de un error. No demuestran que las fotografías, los datos, las traducciones y todos los recorridos funcionen correctamente en conjunto.

Un retorno que corresponda al cambio#

Conservar la versión anterior del tema ofrece un punto de retorno para un cambio al tema. Ante una descripción o cantidad equivocada, volver al tema anterior no restablece automáticamente el dato. El procedimiento debe conservar lo que realmente se modificó.

La entrega debe incluir un ejercicio de este tipo con el cliente: hacer un cambio sencillo, verlo en la vista previa, pedir su revisión y encontrar los pasos de recuperación si el resultado no es el esperado. El ejercicio verifica una capacidad concreta de administración, más allá de que exista un botón para editar.

El resultado esperado de la entrega es un sitio que el cliente pueda administrar dentro del alcance acordado. Los accesos no bastan. También se necesitan contenidos confirmados, un mapa de responsabilidades y tareas de mantenimiento comprensibles.

El cliente conserva las decisiones sobre productos, precios, cantidades y textos. Una persona puede encargarse de las actualizaciones habituales y otra aprobarlas. Los cambios de código, los comportamientos nuevos y las intervenciones estructurales necesitan una responsabilidad técnica distinta. Un acuerdo de soporte debe definir el alcance de las intervenciones y la responsabilidad de cada persona.

Propiedad y continuidad#

El inventario de entrega debe cubrir la tienda, el dominio, los accesos necesarios, los contenidos, los medios, las traducciones, las aplicaciones y la documentación. Debe quedar claro quién posee las cuentas, quién puede recuperar un acceso y quién aprueba un cambio importante. No hace falta mostrar credenciales ni datos privados en un estudio de caso para explicar esa necesidad.

El procedimiento de Shopify depende del tipo exacto de tienda y de su situación al momento de la entrega. El nombre de un entorno de desarrollo no determina qué se puede transferir. Esa verificación forma parte de preparar la transferencia o, si hace falta, una migración autorizada. La verificación corresponde a la propiedad real y los permisos de las cuentas, no a sus nombres.

Un mantenimiento proporcionado#

El mantenimiento habitual puede reunir contenidos desactualizados, imágenes por reemplazar, enlaces por verificar y traducciones por revisar. Se necesitará una revisión técnica después de cambios que afecten al tema o a las aplicaciones. La frecuencia debe corresponder a la actividad real y al acuerdo de soporte.

Para cada intervención sirve un registro breve: qué cambió, por qué, quién lo aprobó y qué se verificó. Ese registro facilita que otra persona retome el sitio y evita que el conocimiento dependa únicamente de la memoria del desarrollador.