47 lines
2.3 KiB
Markdown
47 lines
2.3 KiB
Markdown
---
|
||
issueRef: "#202"
|
||
version: 4
|
||
updatedBy: {"kind":"agent","agent_id":"a6c6ea12-bfc6-4bdc-8031-324102dfa34d"}
|
||
updatedAt: 1786750786970
|
||
---
|
||
2026-08-14 — Ouverture du chantier de refonte web UI/UX.
|
||
|
||
Demande utilisateur:
|
||
- Refonte totale de l’UI/UX de la version web d’IdeA.
|
||
- Desktop PC: viser une forte parité avec l’AppImage.
|
||
- Toutes les features actuelles doivent être exposées.
|
||
- Les fenêtres flottantes AppImage devraient idéalement devenir des onglets/fenêtres navigateur.
|
||
- Mobile téléphone: UX dédiée, pensée spécifiquement pour ce format.
|
||
|
||
Cadrage UX reçu:
|
||
- Ne pas faire un simple responsive du desktop vers mobile.
|
||
- Deux produits UX dans un même client web: `desktop-parity workspace` et `mobile task-flow`.
|
||
- Desktop: shell avec top bar, rail primaire, canevas central, rail secondaire, vues détachables, persistance par projet.
|
||
- Mobile: navigation focalisée, mono-tâche visible, priorisation des usages courts/décisionnels.
|
||
- Exposition des features par intention utilisateur, pas par module technique.
|
||
|
||
Cadrage architecture reçu:
|
||
- Introduire une abstraction de `surface adressable` au-dessus des composants.
|
||
- Conserver `LayoutTree` pour le canevas central uniquement; ne pas lui faire porter tabs/fenêtres/sheets du shell web.
|
||
- Ajouter un `SurfaceCatalog`, un `WorkspaceSession` desktop, un `TaskFlowSession` mobile et une synchro cross-window/tab.
|
||
- Chaque surface doit supporter une présentation parmi `inPlace | tab | window | sheet` selon son contrat.
|
||
- Conserver les gateways métier existants; ne pas dupliquer la logique par shell.
|
||
|
||
Découpage recommandé:
|
||
- A0 inventaire complet des features/surfaces.
|
||
- A1 noyau surfaces + routage/ouverture.
|
||
- A2 shell desktop web.
|
||
- A3 détachement onglet/fenêtre.
|
||
- A4 persistance/restauration/synchro.
|
||
- A5 migration progressive des features.
|
||
- A6 shell mobile dédié.
|
||
- A7 hardening QA.
|
||
|
||
Risque principal:
|
||
- Copier visuellement l’AppImage sans transposer correctement les contraintes du navigateur.
|
||
- Faire du mobile un desktop rétréci.
|
||
- Mélanger état de shell, état local de vue et données métier.
|
||
|
||
Décision Main:
|
||
- Traiter #202 comme un programme de refonte structuré, pas comme un ticket de skinning.
|
||
- Demander ensuite un éclatement en sous-tickets d’implémentation avant toute phase dev/QA massive. |