Skip to main content

Events Wizard – Disseny funcional

Aquest document descriu la idea de l’assistent d’alta/edició d’esdeveniments (“Events Wizard”) per a la Line Dance Platform (LDP).

Objectiu: oferir un flux clar i guiats per crear o editar events (socials, festivals, workshops…) sense perdre’s en formularis llargs.

1. Objectius del wizard​

  • Simplificar l’alta d’un event complet:
    • metadades bàsiques (nom, dates, tipus),
    • venue i location,
    • programa (sessions / classes / socials),
    • enllaços (web, xarxes, entrades),
    • opcionalment, balls destacats.
  • Reduir errors de dades:
    • dates incoherents,
    • venues duplicats,
    • ubicacions incompletes.
  • Preparar el model per a:
    • futurs events recurrents,
    • integració amb calendaris externs.

2. Rols i punts d’entrada​

2.1. Rols que poden crear/editar events​

  • ADMIN
    • pot crear/editar qualsevol event.
  • TEACHER / ORGANIZER (segons model de rols definit)
    • pot crear/editar només events dels quals és responsable (regla a definir).

2.2. Punts d’entrada​

  • Botó “Nou event” a la llista d’events (/events).
  • Acció “Editar” a la fitxa d’un event existent.

Tots dos obren el mateix wizard, amb dades buides o preomplertes.

3. Estructura de passos​

Proposta inicial de passos (pot ajustar-se en funció de l’UX):

  1. Metadades bàsiques
  2. Venue i ubicació
  3. Dates i horaris / sessions
  4. Programa i balls destacats (opcional)
  5. Enllaços i informació pública
  6. Revisió i confirmació

Pas 1 – Metadades bàsiques​

Camps:

  • name (obligatori)
  • event_type (social, festival, workshop, class night…)
  • description (rich text simple)
  • organizer_name (text lliure o referència futura a una entitat)
  • Idioma principal (opcional)

Validacions:

  • name no buit.
  • event_type requerit.

Pas 2 – Venue i ubicació​

Opcions:

  • Seleccionar venue existent (selector amb cerca per nom, ciutat, país).
  • Crear nou venue des d’aquest mateix pas (dialeg o subformulari embegut).

Camps clau:

  • location (country, city, state/region),
  • venue (name, address, notes),
  • opcionalment coordenades (lat, lng).

Validacions:

  • No permetre guardar l’event sense tenir com a mínim location bàsica i un venue associat.
  • Evitar duplicats:
    • suggerir venues existents quan es detecta un nom semblant a la ciutat indicada.

Pas 3 – Dates i horaris / sessions​

L’event pot tenir:

  • dates d’inici i fi generals (start_at, end_at),
  • o bé una llista de sessions (per socials, workshops, etc.).

Model proposat:

  • event.start_at, event.end_at (franja global).
  • Taula event_sessions (o equivalent) a futur:
    • event_id,
    • name (p. ex. “Friday Social”, “Workshop A”),
    • start_at, end_at,
    • room (si el venue te múltiples sales).

En el wizard:

  • Si només hi ha una franja simple:
    • formulari senzill d’inici/fi.
  • Si hi ha múltiples sessions:
    • UI tipus taula amb “Afegir sessió”.

Validacions bàsiques:

  • start_at < end_at.
  • Cap sessió amb dates fora del rang global de l’event (si es defineix).

Pas 4 – Programa i balls destacats (opcional)​

En aquesta fase es poden associar:

  • dances destacats que se sap que es ballaran,
  • line-up de coreògrafs, DJs, instructors (segons model d’identitat).

A nivell MVP:

  • Pot ser només un camp de text lliure (“notes del programa”).
  • A futur:
    • llistes estructurades de dances,
    • enllaç amb sessions concretes.

Pas 5 – Enllaços i informació pública​

Camps:

  • website_url
  • tickets_url
  • facebook_event_url
  • instagram, etc.
  • Política bàsica de fotos/vídeo (text opcional).

Validacions:

  • Formats bàsics d’URL.
  • Possibilitat de marcar un enllaç com “oficial”.

Pas 6 – Revisió i confirmació​

Resum en mode “read-only” de tots els passos previs:

  • Metadades,
  • Venue + location,
  • Dates / sessions,
  • Programa (si n’hi ha),
  • Enllaços.

Accions:

  • Guardar borrador (status = DRAFT).
  • Publicar (status = PUBLISHED).
  • Tornar a passos anteriors per corregir.

4. Integració amb el backend​

4.1. DTO de treball​

Es pot utilitzar un únic DTO CreateOrUpdateEventRequest que contingui:

  • camps d’event (bàsics),
  • bloc venue (existent o nou),
  • bloc sessions (llista),
  • blocs d’enllaços.

El frontend envia aquest DTO a:

  • POST /api/events per crear,
  • PUT /api/events/{id} per actualitzar.

4.2. Persistència​

El servei de backend ha de:

  1. Crear o reutilitzar location i venue.
  2. Crear/actualitzar l’event.
  3. Crear/actualitzar les sessions (si n’hi ha).
  4. Gestionar les relacions amb balls/coreògrafs quan estiguin definides.

Els detalls de model de dades es documenten a architecture/db-redesign-plan.md.

5. Validació i UX​

  • Mostrar errors per pas (no globals) per no saturar l’usuari.
  • Permetre guardar com a borrador en qualsevol moment.
  • En cas d’error al backend:
    • mostrar missatge clar amb camp afectat (si es pot),
    • no perdre el que l’usuari ja ha omplert.

6. Properes decisions​

  • Definir exactament el model event_sessions.
  • Decidir política per events recurrents (setmanals/mensuals).
  • Decidir nivell de detall del programa (balls per sessió vs notes generals).
  • Dissenyar diagrama de flux específic a architecture/diagrams.md (Mermaid/Draw.io).

Aquest document és una guia de disseny; la implementació concreta pot anar-se afinant a mesura que es protegeixi amb el model de dades i l’UX real.