Aller au contenu principal

Navigation

Version : 1.0

Statut : Architecture cible

1. Objectif​

Ce document définit les principes de navigation de DMV Mobile.

La navigation ne consiste pas uniquement à passer d'un écran à un autre.

Elle constitue l'un des éléments centraux de l'expérience utilisateur.

Chaque utilisateur doit toujours savoir :

  • où il se trouve ;
  • où il peut aller ;
  • comment revenir.

La navigation doit rester simple, prévisible et cohérente sur Android comme sur iOS.

2. Principes fondamentaux​

Les principes suivants sont considérés comme figés.

Une seule application​

L'utilisateur n'utilise jamais plusieurs applications.

Même lorsqu'il passe du Public au Workspace, il reste dans DMV.

Aucune rupture visuelle ne doit donner l'impression de changer d'application.

Une seule navigation​

Il n'existe qu'un seul système de navigation.

Les deux applications embarquées utilisent les mêmes principes.

La navigation doit suivre les besoins de l'utilisateur.

Jamais l'organisation technique.

Exemple :

L'utilisateur ouvre une commune.

Il ne doit pas savoir :

  • quel service répond ;
  • quelle API est utilisée ;
  • quelle application React est chargée.

3. Les espaces​

DMV Mobile est constitué de deux espaces.

Public​

Accessible :

  • visiteurs
  • utilisateurs

Il contient :

  • Mur
  • Recherche
  • Commune
  • Agenda
  • Acteurs
  • Publications
  • Mon Espace

Workspace​

Accessible uniquement aux utilisateurs autorisés.

Il permet :

  • gérer un acteur
  • gérer une mairie
  • publier
  • consulter les statistiques
  • modifier les paramètres

Le passage du Public au Workspace doit être transparent.

4. Navigation principale​

La navigation principale est assurée par une barre inférieure.

Cette barre constitue le point d'entrée principal de l'application.

Exemple de structure cible :

Accueil

Recherche

Agenda

Mon Espace

Menu

Cette structure pourra évoluer sans remettre en cause les principes de navigation.

5. Navigation contextuelle​

Chaque écran peut proposer une navigation secondaire.

Exemples :

Commune

↓

Services

↓

Collectes

↓

Élus

↓

Actualités

Acteur

↓

Présentation

↓

Publications

↓

Agenda

↓

Informations

Cette navigation reste propre au contexte courant.

6. Navigation hiérarchique​

Chaque écran possède un parent logique.

Exemple :

Accueil

↓

Commune

↓

Publication

↓

Auteur

Le bouton Retour doit toujours remonter cette hiérarchie.

7. Navigation transversale​

Certains contenus peuvent être atteints depuis plusieurs endroits.

Exemple :

Une publication peut être ouverte :

  • depuis le Mur
  • depuis un acteur
  • depuis une commune
  • depuis une notification
  • depuis une recherche

Une fois ouverte, l'expérience doit être identique.

Chaque ressource importante possède une adresse canonique et, lorsque nécessaire, une route interne mobile.

Rôles respectifs :

  • URL HTTPS : lien public, partageable et indexable, par exemple https://www.dansmonvillage.fr/bessan.
  • Universal Link iOS : association d'une URL HTTPS au lancement de l'app installée sur iPhone.
  • Android App Link : association équivalente côté Android.
  • Schéma dmv:// : route interne contrôlée par l'application, utile pour notifications, widgets ou intégrations natives.

Exemples de routes internes :

dmv://commune/bessan

dmv://acteur/club-foot

dmv://publication/123

dmv://agenda

dmv://workspace/acteur/club-foot

Cette architecture permet :

  • les notifications ;
  • les widgets ;
  • les QR Codes ;
  • les liens externes ;
  • la compatibilité web lorsque l'application n'est pas installée.

9. Notifications​

Une notification ne doit jamais ouvrir l'accueil.

Elle ouvre directement la ressource concernée.

Exemple :

Nouvelle publication

↓

Ouverture directe de la publication

Nouvel événement

↓

Ouverture de l'événement

Nouvelle alerte mairie

↓

Ouverture de l'alerte

10. Retour Android​

Le bouton Retour Android suit les règles suivantes.

Cas normal​

Retour à l'écran précédent.

Racine​

Lorsque l'utilisateur est déjà sur l'écran principal :

Retour

↓

Réduction de l'application

Pas fermeture brutale.

Workspace​

Si l'utilisateur quitte un écran Workspace :

Retour

↓

Workspace précédent

Jamais retour automatique dans le Public.

11. Navigation iOS​

Sous iOS :

Le swipe retour doit fonctionner partout où cela est cohérent.

Les animations doivent respecter les conventions Apple.

12. Changement Public ↔ Workspace​

Le passage entre les deux espaces doit être fluide.

Exemple :

Profil Acteur

↓

Modifier

↓

Workspace

↓

Enregistrer

↓

Retour Profil Acteur

L'utilisateur ne doit jamais avoir l'impression d'avoir quitté l'application.

13. Gestion de la connexion​

Si une action nécessite une authentification :

Utilisateur

↓

Action protégée

↓

Connexion

↓

Retour automatique

↓

Action initiale

L'utilisateur reprend exactement là où il s'était arrêté.

14. Changement de rôle​

Un utilisateur peut gérer plusieurs espaces.

Exemple :

  • Association A
  • Association B
  • Commune
  • Entreprise

Le changement d'espace ne change jamais d'application.

Seul le contexte change.

15. Navigation Offline​

Si le réseau disparaît :

Les écrans déjà disponibles restent consultables.

Les éléments indisponibles affichent un état explicite.

Jamais une erreur technique.

Exemple :

Connexion perdue

↓

Les dernières données disponibles sont affichées.

↓

Synchronisation dès le retour du réseau.

16. Ouverture externe​

Les liens externes utilisent le navigateur système.

Exemples :

  • Facebook
  • Instagram
  • Site web
  • Billetterie
  • Service externe

DMV reste ouvert en arrière-plan.

17. Multi-fenêtres​

L'application doit supporter :

Android :

  • écran partagé

iPad :

  • Split View
  • Stage Manager

La navigation ne doit jamais dépendre d'une taille d'écran fixe.

18. Accessibilité​

La navigation doit rester utilisable :

  • au clavier
  • avec VoiceOver
  • avec TalkBack
  • avec une grande taille de texte

Toutes les actions importantes doivent rester accessibles.

19. Erreurs​

Une erreur de navigation ne doit jamais bloquer l'utilisateur.

Exemple :

Publication supprimée.

↓

Message explicite.

↓

Retour automatique à l'écran précédent.

Jamais une page blanche.

20. Décisions d'architecture​

Les décisions suivantes sont considérées comme figées.

✅ Une seule navigation.

✅ Une seule application.

✅ Public et Workspace cohabitent.

✅ Navigation basée sur le contexte utilisateur.

✅ Toutes les ressources possèdent un Deep Link.

✅ Les notifications ouvrent directement la ressource.

✅ Le bouton Retour respecte les conventions Android et iOS.

✅ Le contexte utilisateur est toujours conservé.

Conclusion​

La navigation constitue l'un des piliers de DMV Mobile.

Elle ne doit jamais refléter l'organisation technique de la plateforme.

L'utilisateur ne navigue pas entre des applications.

Il navigue simplement dans son expérience DMV.

Les composants techniques (Capacitor, dmv-public, dmv-workspace, API...) restent invisibles et transparents.