Anatomía completa — Canvas Page Template, todos los slots activos
Una solución estructural para el único paradigma que Redwood no tenía: los visual builders. Entregado en un ciclo de diseño. Adoptado por 7+ equipos de producto en el ecosistema enterprise de Oracle.
Redwood tenía una biblioteca madura de page templates. Todos compartían el mismo supuesto de base: los usuarios organizan datos en listas, editan items, rastrean estados. Era el paradigma correcto para la mayoría de los productos de Oracle.
Pero cuando varios equipos comenzaron a migrar a Redwood, algo no encajaba. Estaban construyendo productos de una naturaleza completamente diferente: editores de email, constructores de sitios, flujos de automatización, workflows agénticos. Ningún template existente les servía.
El patrón se volvió visible al analizar los requests en paralelo: distintos equipos, distintos productos, pero el mismo problema de fondo. No necesitaban datos en listas. Necesitaban una superficie donde sus usuarios pudieran construir cosas visualmente.
El reto tenía dos dimensiones: capacidades visuales — drag & drop, edición contextual, zoom y navegación espacial — y configuración flexible para 7+ equipos de producto sin reconstruir desde cero cada vez.
Antes de diseñar cualquier layout, necesitaba entender el modelo mental correcto para este tipo de interfaz. Hice un benchmark propio — revisando productos, probando funcionalidades y mapeando los patrones — no para imitar lo que ya existía, sino para justificar las decisiones de diseño con evidencia concreta en lugar de solo seguir el patrón obvio del visual builder.
El ejercicio reveló una metáfora que unificaba todos los casos: la mesa de paste-up — el espacio de trabajo del diseñador editorial antes de la digitalización. Una superficie donde cualquier elemento podía colocarse, moverse y recomponerse libremente, sin la restricción de una estructura predefinida. Es exactamente el modelo mental detrás de Figma, Miro y Salesforce Flow. Nombrar esa metáfora desde el inicio alineó al equipo y a los stakeholders antes de la primera propuesta.
Cinco patrones aparecen de forma consistente en Figma, Canva, Google Slides, Mailchimp y Draw.io — sin importar qué construye el producto.
Chrome mínimo. Solo el espacio necesario para información esencial — dejando la pantalla para el canvas.
Controles de modo. Acciones que cambian cómo el canvas responde al input del usuario.
Configuración a nivel de elemento. El patrón más recurrente: seleccionar algo y editar sus propiedades.
Colapsar chrome, ocultar paneles, entrar a un estado limpio para revisión y presentación.
Atajos de interacción. Acceso rápido a acciones sin abrir un panel completo.
Al revisar los casos de uso de los equipos que solicitaban el template, los agrupé inicialmente como una sola categoría. El benchmark reveló algo más preciso — las herramientas de referencia no eran genéricas, cada una estaba enfocada en uno de dos paradigmas distintos.
Canvas infinito, nodos conectados, navegación por pan & zoom. Los usuarios construyen flujos y relaciones. La lógica espacial es relacional — los elementos existen en referencia a otros.
Canvas acotado, drag & drop de módulos desde un panel, propiedades en panel lateral. Los usuarios ensamblan contenido en un espacio definido. La lógica espacial es composicional — los elementos existen dentro de un contenedor fijo.
No fueron declaraciones decorativas. Cada uno resolvió una tensión real que surgió durante el diseño y las revisiones con stakeholders.
Los principios compartidos le dieron al equipo un lenguaje común para evaluar trade-offs — y a los equipos de producto una razón clara de qué acomodaría el template y qué no.
Cada slot de la pantalla tiene un significado específico. La UI se organiza de forma consistente — sin ambigüedad sobre qué zona hace qué. Cada área gana su espacio.
El canvas es el protagonista. Toolbar y header son deliberadamente delgados — cediendo la mayor parte del espacio de pantalla al área de construcción.
El template soporta distintos casos de uso y define un camino claro de evolución para flujos más complejos — sin requerir una reconstrucción para cada nuevo producto.
El layout se construyó de forma acumulativa — añadiendo cada zona solo cuando su función quedaba clara. Esta secuencia se convirtió en parte de cómo se documentó y comunicó el template a los equipos adoptantes.
Una versión ligera del header estándar de Redwood. Contiene el título de la página, un badge de estado y las acciones primarias (Cancel, Save, Publish). Nada más. Cualquier elemento adicional compite con el canvas.
Dividida en dos zonas con lógicas distintas. La zona izquierda tiene hasta 8 slots de acciones configurables por el equipo adoptante — lo que sea relevante para su producto. La zona derecha es fija: viewport toggle (Web/Mobile), nivel de zoom, expand a pantalla completa. Siempre en el mismo lugar, visibles u ocultos según lo que el producto necesite.
Panel colapsable con tabs verticales en modo ícono. Esta es la zona de origen — donde el usuario selecciona o arrastra elementos para colocarlos en el canvas. Al colapsar, los íconos permanecen visibles como referencia sin ocupar espacio.
Edición contextual cuando un elemento del canvas está seleccionado. A diferencia del panel izquierdo, no es colapsable — es cerrable. Desaparece cuando no hay nada seleccionado y vuelve a invocarse al seleccionar un elemento. Los tabs horizontales soportan múltiples categorías de propiedades sin abrumar al usuario.
El área donde ocurre la construcción visual. El espacio más grande de la pantalla — y la razón de existir de todos los demás slots.
Los paneles laterales son útiles cuando el usuario los necesita. Son obstáculos cuando no. La solución: un modelo de visibilidad por demanda. El usuario puede colapsar el panel izquierdo y cerrar el panel de propiedades, maximizando el canvas. Los paneles se invocan solo cuando hay una acción específica que realizar.
Este comportamiento fue el que más negociación requirió con los equipos de producto. La conversación cambió cuando lo posicioné como una ventaja del template: los slots están definidos, las reglas son claras, y dentro de esos límites hay margen de configuración. Lo que ceden en especificidad de layout, lo ganan en velocidad de adopción y consistencia cross-producto.
"El diseño de templates es en parte diseño de sistemas
y en parte diplomacia."
El comportamiento responsivo no es solo reducir tamaños — es definir qué priorizar cuando el espacio se comprime. El canvas es siempre lo último en ceder espacio.
En breakpoints medianos (768px), el toolbar derecho consolida viewport toggle y zoom en un menú desplegable único. En breakpoints pequeños (600px), los paneles laterales ceden completamente espacio al canvas — la construcción se simplifica, pero el canvas permanece funcional.
Documentar esto con precisión fue parte del entregable hacia los equipos de producto: no solo el diseño del estado ideal, sino el comportamiento en condiciones reales.
El proceso de alineación con los equipos de producto fue tan parte del trabajo como el diseño mismo. Cada equipo llegaba con sus propios requerimientos, sus propias ideas sobre cómo debían verse sus paneles y qué acciones debía tener su toolbar.
La clave fue justificar cada slot con su función, no con una preferencia estética. Cuando los equipos entendían el por qué de cada zona del layout — por qué el header es slim, por qué el toolbar tiene dos zonas, por qué el panel de propiedades es cerrable pero no colapsable — la negociación cambiaba de tono.
Dejó de ser "así lo diseñé yo" y se convirtió en "así funciona el paradigma, y dentro de él tienen espacio para configurar lo que necesitan."
En ningún caso un equipo perdió funcionalidades que necesitaba. Lo que cedieron fue especificidad de layout. Lo que ganaron fue velocidad de adopción y coherencia con el resto de la plataforma.
El Canvas Page Template creó un lenguaje compartido para visual builders en Oracle — una baseline que demostró que el paradigma funciona dentro de Redwood.
Los equipos ya no empiezan de cero. Los slots están definidos, las reglas son claras, y hay margen de configuración dentro de un sistema coherente — email marketing, automation flows, site building y agentic workflow design, todos bajo la misma lógica estructural.
Trabajar con este nivel de page template — en contacto directo con múltiples equipos de producto con requerimientos distintos — me enseñó algo que no esperaba. La habilidad más valiosa no fue definir la anatomía. Fue aprender a hacer que distintos equipos reconocieran sus casos de uso dentro de una propuesta común — y a ayudarlos a entender que lo que cedían en especificidad lo ganaban en velocidad y coherencia.
Documentaría la distinción Diagramas vs. Builders como una decisión de arquitectura de templates desde el inicio, con sus propias guías de uso. Actualmente conviven dentro del mismo template como sub-patrones — lo cual funciona, pero no está lo suficientemente explícito para que los equipos adoptantes sepan cuál aplica a su caso sin consultar.
El modelo actual define zonas fijas — panel izquierdo, panel derecho, toolbar. Pero hay una categoría de productos más complejos donde los usuarios necesitan controlar su propio workspace: paneles flotantes, paneles apilables, configuraciones personalizadas que persisten entre sesiones.
Esa es la dirección natural de evolución. El Canvas Page Template actual es la baseline — el punto de partida que demuestra que el paradigma funciona dentro de Redwood. La siguiente conversación es hasta dónde puede flexibilizarse sin perder la coherencia que lo hace adoptable en primer lugar.