Manuel
108 lines
4.8 KiB
Markdown
108 lines
4.8 KiB
Markdown
# MNQ Critical Fixes Design
|
|
|
|
## Goal
|
|
Corregir los problemas críticos visibles del sitio actual de MNQ Catering y Evento sin introducir todavía CMS, base de datos, chatbot ni backend temporal innecesario.
|
|
|
|
## Context
|
|
El proyecto ya cuenta con Astro 5 SSR, layout compartido, páginas aprobadas y sistema CSS base. Sin embargo, hoy está en fase skeleton: el número de WhatsApp está hardcodeado con un placeholder, el formulario de contacto no es funcional y la Home/Contacto todavía no sostienen una narrativa comercial premium completa.
|
|
|
|
## Scope for This Phase
|
|
|
|
### Included
|
|
- Centralizar el número de WhatsApp y los mensajes base en una sola fuente de configuración.
|
|
- Reemplazar el placeholder actual en header/footer/botón flotante/CTAs.
|
|
- Mantener el formulario de contacto visible.
|
|
- Hacer que el submit del formulario muestre feedback elegante de “próximamente disponible” y redireccione la intención al CTA principal de WhatsApp.
|
|
- Reforzar la Home con secciones editoriales mínimas pero reales.
|
|
- Reforzar Contacto para que WhatsApp sea la acción primaria y el formulario la secundaria.
|
|
- Agregar mejoras base de accesibilidad y metadata mínima de layout.
|
|
|
|
### Explicitly Excluded
|
|
- Strapi 5.44.
|
|
- PostgreSQL 17, pgvector o RAG.
|
|
- Chatbot.
|
|
- Integración con Groq, Ollama o embeddings.
|
|
- Endpoint temporal para formulario.
|
|
- Modelado de contenido dinámico.
|
|
|
|
## Approach Options Considered
|
|
|
|
### Option A — Minimal Smart Fixes (chosen)
|
|
Resolver solo lo crítico visible, dejando el sitio comercialmente más creíble y técnicamente preparado para una fase 2 más seria.
|
|
|
|
### Option B — Broader Commercial Expansion
|
|
Además de lo crítico, expandir ya las páginas de servicio con más contenido editorial y bloques de valor.
|
|
|
|
### Option C — Early Future Architecture
|
|
Introducir desde ahora contratos y preparación para CMS/chatbot, aun sin backend real.
|
|
|
|
## Why Option A
|
|
Es la mejor relación impacto/costo. El problema actual no es sofisticación arquitectónica sino credibilidad comercial y coherencia UX. Meter estructura futura ahora sería sobreingeniería prematura.
|
|
|
|
## Functional Design
|
|
|
|
### WhatsApp Configuration
|
|
Se definirá una única fuente compartida para:
|
|
- número de WhatsApp
|
|
- URL base `wa.me`
|
|
- mensajes por contexto si hace falta
|
|
|
|
Esto evita repetir strings en páginas y componentes, y deja el sitio listo para conectar luego con CMS o variables de entorno.
|
|
|
|
### Contact Form Behavior
|
|
El formulario seguirá visible como señal de producto serio, pero no prometerá una integración inexistente.
|
|
|
|
Comportamiento:
|
|
- validación básica de campos requeridos en frontend
|
|
- al enviar, no habrá request real
|
|
- se mostrará mensaje claro y elegante del tipo: “Próximamente disponible. Mientras tanto, escribinos por WhatsApp para una respuesta más rápida.”
|
|
- se conservará CTA inmediato a WhatsApp en la misma página
|
|
|
|
Esto protege la confianza del usuario: la interfaz no miente y tampoco se rompe.
|
|
|
|
### Home Content Expansion
|
|
La Home dejará de ser solo un hero. Debe sumar 2 o 3 bloques concretos:
|
|
- servicios destacados
|
|
- propuesta de valor / por qué elegir MNQ
|
|
- cierre comercial con CTA principal
|
|
|
|
No hace falta construir una mega landing todavía. Hace falta que la Home parezca un negocio real, no una maqueta.
|
|
|
|
### Contact Page Structure
|
|
La página de contacto debe mostrar una jerarquía clara:
|
|
1. WhatsApp como acción principal
|
|
2. datos/contexto de respuesta
|
|
3. formulario secundario visible
|
|
4. feedback elegante de “próximamente” al enviar
|
|
|
|
## UX and Accessibility Design
|
|
Se incorporarán mejoras base, sin entrar en una auditoría exhaustiva:
|
|
- skip link hacia contenido principal
|
|
- estados visibles de `:focus-visible`
|
|
- revisión de jerarquía de headings en Home y Contacto
|
|
- copy de CTA más específico cuando corresponda
|
|
|
|
## Metadata / SEO
|
|
Se añadirá metadata mínima útil en el layout:
|
|
- descripción
|
|
- canonical básica si aplica
|
|
- Open Graph esencial
|
|
- `theme-color`
|
|
|
|
## Future Compatibility
|
|
Esta fase no implementa CMS ni chatbot, pero deja una dirección correcta para fase 2:
|
|
- configuración centralizable
|
|
- componentes menos acoplados a strings hardcodeados
|
|
- formulario visible, listo para luego conectarse a Strapi o a otro flujo
|
|
|
|
## Risks
|
|
- Si el número real de WhatsApp todavía no está definido, habrá que esperar ese dato antes de ejecutar el reemplazo final.
|
|
- El formulario visible pero no conectado exige un mensaje muy bien escrito para no generar frustración.
|
|
- Si la Home crece demasiado ahora, se puede perder foco y abrir trabajo de copy innecesario antes del CMS.
|
|
|
|
## Success Criteria
|
|
- No queda ningún placeholder de WhatsApp en producción.
|
|
- El formulario visible no rompe ni promete envío real.
|
|
- Home y Contacto transmiten más confianza comercial.
|
|
- Mejoran accesibilidad base y metadata del layout.
|
|
- El alcance queda contenido y no invade la fase 2. |