Déployer une application d'orientation en réalité augmentée, c'est bien plus que mettre un plan dans une application. La qualité du résultat tient surtout à deux choses : le travail accompli avant qu'un seul visiteur n'ouvre l'application, et les ajustements qui se poursuivent une fois qu'elle est entre les mains du public.
Étude de cas Eurêka!
Cet article s'attarde sur notre processus, les raisons pour lesquelles nous procédons de cette façon, et l'impact sur l'expérience du visiteur. Le site Glen du Centre universitaire de santé McGill (CUSM), à Montréal, où nous avons conçu l'application Eurêka, nous sert d'exemple tout au long.
C'est le premier de deux articles. Le second portera sur ce qui est propre à la réalité augmentée (RA) : la capture et le calibrage des images 360 qui alimentent les instructions en réalité augmentée, et les contraintes techniques avec lesquelles il faut composer.
C'est le premier de deux articles. Le second portera sur ce qui est propre à la réalité augmentée (RA) : la capture et le calibrage des images 360 qui alimentent les instructions en réalité augmentée, et les contraintes techniques avec lesquelles il faut composer.
Comprendre l'expérience sur place
Chaque campus est unique
Implémenter une application d'orientation dépend énormément de la compréhension de l'architecture des lieux par les équipes en charge du projet. Si notre compréhension des lieux est incomplète ou fausse, aucune fonctionnalité logicielle ne pourra compenser cela. En plus d'analyser les plans, nous commençons par visiter le site comme le ferait quelqu'un qui y met les pieds pour la première fois, et par repérer tout ce qui peut servir de point de repères, et ce qui peut prêter à confusion. La logique et les subtilités de la signalétique existente, les nomenclatures existantes (parfois différente entre les utilisateurs et les employés) ainsi que l'architecture.
Si les grands campus sont compliqués, c'est souvent pour de bonne raisons, que ce soit des agrandissements, déménagements, regroupements d'établissements, modernisation... Le site Glen du CUSM en est un bel exemple : ouvert en 2015, il regroupe sur un seul campus l'Hôpital Royal Victoria, l'Institut thoracique de Montréal, le Centre du cancer des Cèdres, l'Hôpital de Montréal pour enfants et l'Institut de recherche du CUSM. Le bâtiment est récent, et c'est justement la complexité née de ce regroupement que nous cherchons à cartographier.
À cela s'ajoute un fait important : plus de la moitié des gens qui se présentent au Glen n'y sont jamais venus. Ils ne connaissent ni les logiques internes ni les conventions de nommage. Beaucoup ignorent, par exemple, que le campus abrite deux hôpitaux pédiatriques distincts, voisins l'un de l'autre.
Si les grands campus sont compliqués, c'est souvent pour de bonne raisons, que ce soit des agrandissements, déménagements, regroupements d'établissements, modernisation... Le site Glen du CUSM en est un bel exemple : ouvert en 2015, il regroupe sur un seul campus l'Hôpital Royal Victoria, l'Institut thoracique de Montréal, le Centre du cancer des Cèdres, l'Hôpital de Montréal pour enfants et l'Institut de recherche du CUSM. Le bâtiment est récent, et c'est justement la complexité née de ce regroupement que nous cherchons à cartographier.
À cela s'ajoute un fait important : plus de la moitié des gens qui se présentent au Glen n'y sont jamais venus. Ils ne connaissent ni les logiques internes ni les conventions de nommage. Beaucoup ignorent, par exemple, que le campus abrite deux hôpitaux pédiatriques distincts, voisins l'un de l'autre.
Voici quelques-uns des aspects que nous analysons, exemples du Glen à l'appui.
La signalisation déjà en place
Nous examinons les cartes affichées sur les murs et les conventions qu'elles emploient déjà : couleurs associées aux secteurs, pictogrammes, façons de nommer les étages. Réutiliser ce que les gens ont déjà sous les yeux garde l'application cohérente avec le bâtiment. Au Glen, un code de couleurs distinguait déjà les établissements donc nous l'avons intégré pleinement dans l'application.
Comment fonctionne les adresses.
Crucial pour le répertoire, il change d'un hôpital à l'autre. Nous tombons parfois sur plusieurs conventions au sein d'un même site, ce qui arrive souvent quand on ajoute / rénove un pavillon sans renuméroter les bâtiments d'origine.
Comme le Glen est récent, son adressage est unifié. Chaque emplacement porte une adresse en trois parties : secteur, étage et numéro de local, par exemple D RC.3114. Sur un campus de cette échelle, la numérotation suit la logique de la construction, au lieu du trajet d'un visiteur. Les visiteurs ne doivent pas avoir à comprendre la logique derrière tout cela : nous la cartographions, pour que l'application mène droit à la bonne porte, peu importe l'ordre des numéros. Nous ajoutons aussi des points de repère intermédiaires le long du parcours, du type « tournez à droite à la porte C 02.1024 ».
Comme le Glen est récent, son adressage est unifié. Chaque emplacement porte une adresse en trois parties : secteur, étage et numéro de local, par exemple D RC.3114. Sur un campus de cette échelle, la numérotation suit la logique de la construction, au lieu du trajet d'un visiteur. Les visiteurs ne doivent pas avoir à comprendre la logique derrière tout cela : nous la cartographions, pour que l'application mène droit à la bonne porte, peu importe l'ordre des numéros. Nous ajoutons aussi des points de repère intermédiaires le long du parcours, du type « tournez à droite à la porte C 02.1024 ».
Comment le campus est-il subdivisé
Le Glen compte cinq blocs, de A à E. Comme plusieurs établissements cohabitent dans le même bâtiment, un bloc ne correspond pas à un seul établissement. Nous démêlons tout cela pour que l'application sache toujours vers quel établissement le visiteur se dirige, même quand la seule lettre du secteur ne suffit pas à le dire.
Par où les visiteurs arrivent vraiment
Les visiteurs arrivent souvent ailleurs qu'à l'entrée principale. Au site Glen, beaucoup de visiteurs arrivent par le niveau S1 et les niveaux de stationnement souterrains. Nous étudions ces flux d'arrivée pour que l'application soit utile à partir du point où les gens commencent vraiment leur trajet. Ces flux nous indiquent aussi où faire connaître l'application, avec de grands codes QR et des bornes lorsque c'est possible.
Les chemins réellement accessibles
Tous les corridors ne sont pas ouverts à tous, et certaines destinations ne se rejoignent que par un groupe d'ascenseurs précis. Nous cartographions les chemins qu'un visiteur peut emprunter et ceux réservés aux employés, pour ne jamais lui proposer un corridor ou un ascenseur qui lui est interdit.
Le visiteur n'a jamais à comprendre la logique interne du bâtiment : nous l'avons déjà absorbée pour lui.
Exemple de personnalisation du répertoire basé sur l'analyse du site
Répertoire intelligent
un répertoire qui correspond à la façon dont les utilisateurs cherchent les destinations
Une fois l'architecture du site comprise, nous construisons le répertoire, véritable colonne vertébrale de la recherche. Un plan ne sert à rien si le visiteur ne trouve pas sa destination avec les informations dont il dispose.
Nous comparons le répertoire fourni à l'information publiée en ligne pour débusquer les destinations manquantes ou mal nommées. Nous complétons ensuite chaque fiche avec les services offerts, et nous y ajoutons des mots-clés pour les abréviations, les surnoms et les services. C'est important, car un même lieu a souvent plusieurs noms. Au Glen, le Centre de ressources McConnell, presque tout le monde l'appelle « la bibliothèque ». L'important, c'est que le visiteur le trouve, quel que soit les termes qu'il emploie.
Les projets de navigation interactive et d'orientation sont intrinsèquement liés à la signalétique : quand nous découvrons ce type d'écart entre les noms officiels et ceux réellement utilisés, nous le signalons au gestionnaire de projet de l'hôpital, de façon à ce qu'ils puissent harmoniser aussi la signalisation sur place au besoin.
Nous comparons le répertoire fourni à l'information publiée en ligne pour débusquer les destinations manquantes ou mal nommées. Nous complétons ensuite chaque fiche avec les services offerts, et nous y ajoutons des mots-clés pour les abréviations, les surnoms et les services. C'est important, car un même lieu a souvent plusieurs noms. Au Glen, le Centre de ressources McConnell, presque tout le monde l'appelle « la bibliothèque ». L'important, c'est que le visiteur le trouve, quel que soit les termes qu'il emploie.
Les projets de navigation interactive et d'orientation sont intrinsèquement liés à la signalétique : quand nous découvrons ce type d'écart entre les noms officiels et ceux réellement utilisés, nous le signalons au gestionnaire de projet de l'hôpital, de façon à ce qu'ils puissent harmoniser aussi la signalisation sur place au besoin.
Important
Une règle d'or pendant la construction du répertoire : deux destinations ne peuvent jamais porter le même nom. Si deux endroits s'appellent pareil, il faut toujours offrir un élément distinctif, sinon le visiteur ne peut jamais être certain d'aller au bon endroit.
La force des mots-clés
Les mots-clés ne servent pas qu'à gérer les surnoms et les abréviations. C'est aussi là que nous consignons ce qu'un lieu fait vraiment, ce qu'un nom n'indique pas.
C'est particulièrement important pour les destinations "génériques", nombreuses dans un hôpital : ces points de prise en charge requis où il faut d'abord se présenter, même si ce n'est pas là qu'on croit devoir aller. Un patient attendu en gastroentérologie doit parfois passer d'abord par un guichet général des "Cliniques". Son réflexe sera de chercher « gastroentérologie », mais l'endroit qu'il lui faut s'appelle « Cliniques », et rien dans ce nom ne le laisse présager. Nous ajoutons donc « gastroentérologie » comme mot-clé sur la fiche des services ambulatoires, et la recherche suggère maintenant la bonne destination en premier.
Encore faut-il que l'utilisateur comprenne. Trouver le bon résultat ne suffit pas : un résultat qui semble sans rapport avec ce qu'on a tapé, on l'écarte d'instinct. C'est pourquoi notre moteur ne se contente pas d'afficher la destination. Il montre aussi les mots-clés qui ont mené à elle, en surlignant la portion qui correspond à la requête. Celui qui cherche « gastroentérologie » et aboutit aux cliniques comprend aussitôt pourquoi, et ce lien visible entre sa requête et notre suggestion lui donne la confiance de s'y fier.
C'est particulièrement important pour les destinations "génériques", nombreuses dans un hôpital : ces points de prise en charge requis où il faut d'abord se présenter, même si ce n'est pas là qu'on croit devoir aller. Un patient attendu en gastroentérologie doit parfois passer d'abord par un guichet général des "Cliniques". Son réflexe sera de chercher « gastroentérologie », mais l'endroit qu'il lui faut s'appelle « Cliniques », et rien dans ce nom ne le laisse présager. Nous ajoutons donc « gastroentérologie » comme mot-clé sur la fiche des services ambulatoires, et la recherche suggère maintenant la bonne destination en premier.
Encore faut-il que l'utilisateur comprenne. Trouver le bon résultat ne suffit pas : un résultat qui semble sans rapport avec ce qu'on a tapé, on l'écarte d'instinct. C'est pourquoi notre moteur ne se contente pas d'afficher la destination. Il montre aussi les mots-clés qui ont mené à elle, en surlignant la portion qui correspond à la requête. Celui qui cherche « gastroentérologie » et aboutit aux cliniques comprend aussitôt pourquoi, et ce lien visible entre sa requête et notre suggestion lui donne la confiance de s'y fier.
Révision et validation
L'établissement a lui aussi accès au répertoire, par l'entremise d'un outil de révision dédié qui lui permet de vérifier chaque fiche et de comparer ou retoucher facilement les textes dans les deux langues. Tout le répertoire du Glen a été conçu entièrement bilingue dès le départ, avec un soin particulier pour offrir des traductions de qualité : en milieu médical, la terminologie ne pardonne pas l'à-peu-près.
La recherche est le cœur de l'expérience : le visiteur doit trouver la bonne destination, dans une langue comme dans l'autre, peu importe l'information dont il dispose au départ.
La recherche est le cœur de l'expérience : le visiteur doit trouver la bonne destination, dans une langue comme dans l'autre, peu importe l'information dont il dispose au départ.
Création du plan interactif
Créer un plan interactif simplifié
Le répertoire en place, nous nous attaquons aux cartes interactives. Les plans d'architecture ne peuvent pas être utilisés tel quels. Souvent, nous recevons des PDF statiques, parfois même divisés par secteur et par étage. Le cas échéant, nous recollons ces morceaux en plans d'étage complets et détaillés, qui servent de couche de données dans notre éditeur. Nous produisont ensuite une version vectorielle simplifiée, à l'échelle réelle, qui englobe aussi le transport en commun, les stationnements et les cliniques des environs : la navigation ne commence pas simplement à la porte d'entrée. C'est essentiel, parce que le vrai point de départ, c'est souvent un quai de métro ou une place de stationnement, pas le hall d'entrée.
Au Glen, le plan interactif -couvre les trois étages principaux et deux niveaux de stationnement, et le répertoire couvre tous les étages. En tout, nous avons déjà couvert 100 destinations de santé (d'autres viendront dans une phase ultérieure), 40 sections de stationnement et 22 types de commodités : toilettes, entrées, escaliers, stationnement.
Résultat : un plan complèt à l'échelle réelle, capable de guider quelqu'un depuis son vrai point de départ, à travers le métro et le stationnement, jusqu'à la bonne porte.
Au Glen, le plan interactif -couvre les trois étages principaux et deux niveaux de stationnement, et le répertoire couvre tous les étages. En tout, nous avons déjà couvert 100 destinations de santé (d'autres viendront dans une phase ultérieure), 40 sections de stationnement et 22 types de commodités : toilettes, entrées, escaliers, stationnement.
Résultat : un plan complèt à l'échelle réelle, capable de guider quelqu'un depuis son vrai point de départ, à travers le métro et le stationnement, jusqu'à la bonne porte.
Une application fonctionnelle dès le premier jour
Nos applications d'orientation fonctionnent dès le premier jour. Pas question d'attendre la toute fin en espérant que les morceaux finissent par s'emboîter : nous mettons très tôt une version réelle entre les mains des équipes de l'hôpital, puis nous l'améliorons en continu avec eux.
Cette possibilité nous vient de notre propre CMS et notre éditeur de cartes. Nous réutilisons le même noyau d'un projet à l'autre, puis nous le personnalisons en profondeur pour chaque client : ses couleurs, son image de marque, ses exigences. D'où une application sur mesure et fonctionnelle déployée rapidement, sans tout reconstruire de zéro à chaque fois, mais ajustée sur mesure.
L'intérêt de procéder ainsi, c'est que l'application peut être testé tôt par toutes les parties impliquées pendant que nous continuons d'en consolider les fondations : employés, bénévoles, comité des usagers, utilisateurs. Nos équipes peuvent également tester l'application à chaque visite que ce soit pour prendre des photos ou faire du repérage.
Cette possibilité nous vient de notre propre CMS et notre éditeur de cartes. Nous réutilisons le même noyau d'un projet à l'autre, puis nous le personnalisons en profondeur pour chaque client : ses couleurs, son image de marque, ses exigences. D'où une application sur mesure et fonctionnelle déployée rapidement, sans tout reconstruire de zéro à chaque fois, mais ajustée sur mesure.
L'intérêt de procéder ainsi, c'est que l'application peut être testé tôt par toutes les parties impliquées pendant que nous continuons d'en consolider les fondations : employés, bénévoles, comité des usagers, utilisateurs. Nos équipes peuvent également tester l'application à chaque visite que ce soit pour prendre des photos ou faire du repérage.
Tester, écouter, ajuster en continu
L'implémentation d'une application d'orientation ne s'arrête pas le jour du lancement. Le site évolue, et les visiteurs s'en servent de façons que personne ne peut anticiper. Les tests et les améliorations font donc partie du processus, pas d'un après-coup.
Nous commençons par des tests sur place avec des bénévoles, pour récolter leurs observations. Au Glen, l'essentiel portait sur les mots-clés et les noms de destinations, c'est-à-dire les mots que les gens emploient réellement pour chercher. C'est logique : ces informations ne peuvent venir que de ceux qui sont sur place au quotidien. Ces commentaires sont aussitôt intégrés dans le répertoire, où nous ajoutons les termes manquants pour que le prochain visiteur trouve du premier coup. C'est aussi le moment de peaufiner l'interface partout où nous voyons les gens hésiter.
Vient ensuite une phase de test élargie auprès des employés, stimulée par un petit concours pour encourager les retours. Ceux qui connaissent les lieux par cœur remarquent autre chose que les nouveaux venus, et les deux perspectives sont importantes. En général chaque employé donne des commentaires concernant le département dans lequel ils travaillent, c'est pourquoi il est préférable de demander à des employés d'un peu tous les départements si possible.
Grâce à l'enthousiasme des employés et des bénévoles, nous avons recueilli plus de 50 commentaires en quelques jours à peine. De quoi apporter des améliorations concrètes dès qu'il y avait de la confusion, ou lorsque des destinations se ressemblaient trop. Les pharmacies en sont un bon exemple : il y en a trois au Glen, une pharmacie générale pour les visiteurs externes et les ordonnances, une spécialisée en oncologie, et une réservée aux patients hospitalisés, qui est souvent confondu avec la pharmacie externe. Nous en avons aussi profité pour ajouter d'autres destinations que les gens cherchaient.
Le système s'affine à l'usage : c'est en analysant les vraies recherches que le répertoire cesse de parler avec le vocabulaire officiel pour parler avec la langue des visiteurs.
Un article dédié sera bientôt écrit sur cette thématique, si vous êtes intéressés, nous vous recommandons la vidéo suivante : comment exploiter les données des systèmes d'orientation interactifs
Nous commençons par des tests sur place avec des bénévoles, pour récolter leurs observations. Au Glen, l'essentiel portait sur les mots-clés et les noms de destinations, c'est-à-dire les mots que les gens emploient réellement pour chercher. C'est logique : ces informations ne peuvent venir que de ceux qui sont sur place au quotidien. Ces commentaires sont aussitôt intégrés dans le répertoire, où nous ajoutons les termes manquants pour que le prochain visiteur trouve du premier coup. C'est aussi le moment de peaufiner l'interface partout où nous voyons les gens hésiter.
Vient ensuite une phase de test élargie auprès des employés, stimulée par un petit concours pour encourager les retours. Ceux qui connaissent les lieux par cœur remarquent autre chose que les nouveaux venus, et les deux perspectives sont importantes. En général chaque employé donne des commentaires concernant le département dans lequel ils travaillent, c'est pourquoi il est préférable de demander à des employés d'un peu tous les départements si possible.
Grâce à l'enthousiasme des employés et des bénévoles, nous avons recueilli plus de 50 commentaires en quelques jours à peine. De quoi apporter des améliorations concrètes dès qu'il y avait de la confusion, ou lorsque des destinations se ressemblaient trop. Les pharmacies en sont un bon exemple : il y en a trois au Glen, une pharmacie générale pour les visiteurs externes et les ordonnances, une spécialisée en oncologie, et une réservée aux patients hospitalisés, qui est souvent confondu avec la pharmacie externe. Nous en avons aussi profité pour ajouter d'autres destinations que les gens cherchaient.
Le système s'affine à l'usage : c'est en analysant les vraies recherches que le répertoire cesse de parler avec le vocabulaire officiel pour parler avec la langue des visiteurs.
Un article dédié sera bientôt écrit sur cette thématique, si vous êtes intéressés, nous vous recommandons la vidéo suivante : comment exploiter les données des systèmes d'orientation interactifs
Un déploiement en plusieurs phases
Il n'est pas nécessaire de tout cartographier pour le lancement. Une application d'orientation est un outil évolutif : nous pouvons démarrer avec les étages et les bâtiments principaux, puis ajouter le reste plus tard. Il y a plusieurs façons de réduire la portée initiale pour contrôler le budget, sans sacrifier la valeur pour les visiteurs et le personnel.
Ici, la première phase a couvert trois établissements, les trois étages principaux et les niveaux de stationnement. L'ajout d'un autre établissement est déjà en cours d'étude, et d'autres étages pourront suivre. Le système offre d'ailleurs des fonctionnalités pour permettre un déploiement progressif, par exemple en offrant un affichage alternative pour les destinations qui ne sont pas encore cartographiées.
Ici, la première phase a couvert trois établissements, les trois étages principaux et les niveaux de stationnement. L'ajout d'un autre établissement est déjà en cours d'étude, et d'autres étages pourront suivre. Le système offre d'ailleurs des fonctionnalités pour permettre un déploiement progressif, par exemple en offrant un affichage alternative pour les destinations qui ne sont pas encore cartographiées.
Ce qui nous rend différents
La philosophie derrière la démarche
Nous avons établis plusieurs principes pour guider chaque étape. C'est grâce à eux que notre démarche produit de bons résultats :
Nous complétons l'existant, nous ne le remplaçons pas. La signalisation demeure en place, les bénévoles aussi. L'application n'est qu'une couche de plus, posée par-dessus.
Il faut plus d'une porte d'entrée vers l'application. Les utilisateurs arrivent différemment, alors nous multiplions les points d'accès : code QR, nom de domaine facile à écrire, bornes d'affichage, liens bien visibles sur le site de l'hôpital.
Aucune solution unique ne peut convenir à tout le monde. Handicaps, barrières linguistiques, préférences personnelles : ont tous des besoins spécifiques. Combiner plusieurs solutions, et concevoir des solutions entièrement multilingues, reste la seule manière de rejoindre presque tout le monde.
Les points de prise en charge de chaque destinations sont validés sur place. Nous ne nous contentons pas d'indiquer la zone dans laquelle se trouve un département. Nous validons l'endroit précis où le visiteur doit se rendre, souvent un guichet ou une borne d'enregistrement, parfois un lieu tout autre que celui où l'on s'attendrait à trouver le département.
Nous complétons l'existant, nous ne le remplaçons pas. La signalisation demeure en place, les bénévoles aussi. L'application n'est qu'une couche de plus, posée par-dessus.
Il faut plus d'une porte d'entrée vers l'application. Les utilisateurs arrivent différemment, alors nous multiplions les points d'accès : code QR, nom de domaine facile à écrire, bornes d'affichage, liens bien visibles sur le site de l'hôpital.
Aucune solution unique ne peut convenir à tout le monde. Handicaps, barrières linguistiques, préférences personnelles : ont tous des besoins spécifiques. Combiner plusieurs solutions, et concevoir des solutions entièrement multilingues, reste la seule manière de rejoindre presque tout le monde.
Les points de prise en charge de chaque destinations sont validés sur place. Nous ne nous contentons pas d'indiquer la zone dans laquelle se trouve un département. Nous validons l'endroit précis où le visiteur doit se rendre, souvent un guichet ou une borne d'enregistrement, parfois un lieu tout autre que celui où l'on s'attendrait à trouver le département.
La suite
Le prochain article abordera ce qui est propre à la réalité augmentée (RA) : la capture des images 360 à chaque intersection et chaque porte, les contraintes avec lesquelles il faut composer, comme un GPS faible et l'absence totale de signal dans le stationnement, et le calibrage de chaque image pour que lest instructions en réalité augmentée pointent précisément la bonne porte ou le bon ascenseur.
