Concevoir des écrans pilotés par la voix pour le RealWear Navigator 520

Synthèse

Sur le RealWear Navigator 520, la navigation vocale repose sur les éléments d'écran que l'opérateur peut voir et prononcer. Ne vous contentez pas de réduire une mise en page pour smartphone pour l'adapter au casque : affichez clairement les actions disponibles et laissez WearHF associer les commandes vocales aux contrôles pris en charge.

RealWear recommande de limiter la saisie de textes longs, les paramètres complexes et les écrans surchargés. Prévoyez une tâche par écran, des instructions concises, un texte lisible et des libellés visibles bien distincts. Appliquez les mêmes principes à une application canevas comme à une application Android native.

Les équipes de développement disposent de deux approches adaptées à un usage professionnel. Optez pour Android natif avec WearHF lorsque le flux de travail exige un comportement spécifique de l'appareil, une gestion hors ligne ou une intégration aux systèmes de l'entreprise. Optez pour Microsoft Power Apps lorsque l'organisation gère déjà ce flux de travail dans Power Platform et que le lecteur RealWear prend en charge les fonctionnalités dont l'application a besoin. L'approche native présentée ci-dessous comprend des exemples XML et Java ; l'approche Power Apps constitue une alternative low-code facultative.

Règle essentielle : une interface vocale n'est pas un écran mobile classique auquel on aurait ajouté la parole après coup. L'écran lui-même doit indiquer à l'opérateur ce qu'il peut dire.

Qu'est-ce que le RealWear Navigator 520 ?

Le Navigator 520 est un appareil Android mains libres et durci, conçu pour les travaux industriels tels que la maintenance, l'inspection et le service sur le terrain. RealWear indique une résolution d'affichage de 1280 × 720 pixels et, comme logiciel du Navigator 520, Ari OS (Android 13) avec WearHF. Depuis la version de maintenance Ari OS 2.0 du 17-09-2026 (firmware 3.0), les appareils mis à jour fonctionnent sous Android 16 : vérifiez donc quelle version équipe la flotte. Confirmez le firmware et la configuration d'affichage de la flotte d'appareils avant la mise en production.

RealWear fait correspondre l'écran 720p par défaut du Navigator 520 à une zone de mise en page Android de 854 × 480 dp à 240 dpi. Utilisez les dp pour les dimensions de mise en page et les sp pour le texte plutôt que des pixels physiques codés en dur. Gardez un écran simple, car l'affichage n'occupe qu'une partie du champ de vision de l'opérateur.

Voir la page produit du RealWear Navigator 520 chez VR Expert

Choisir une approche de mise en œuvre en entreprise

Optez pour Android natif lorsque vous avez besoin d'un comportement personnalisé, d'intégrations ou de maîtriser les versions publiées. Optez pour Power Apps lorsque l'entreprise dispose déjà d'un environnement Power Platform et que l'application peut se limiter aux fonctionnalités prises en charge des applications canevas.

Microsoft Power Apps :

• Où concevoir : Power Apps Studio, dans un navigateur web
• Idéal pour : les entreprises disposant d'un tenant Power Platform approuvé qui ont besoin d'un flux de travail métier low-code.

Application Android native :

• Où concevoir : Android Studio + WearHF/WearML
• Idéal pour : les équipes de développement qui ont besoin d'un comportement Android personnalisé, d'une intégration aux systèmes de l'entreprise ou de la maîtrise du déploiement géré.

Les deux approches nécessitent une identité approuvée par l'organisation, un accès au bon environnement métier et des autorisations pour chaque source de données connectée. Testez sur la flotte de Navigator 520 gérée, et pas seulement dans un aperçu sur ordinateur.

Approche Android native : créer un écran piloté par la voix

Une View Android est un contrôle d'écran standard, comme un Button ou un TextView. WearHF s'exécute sur l'appareil et peut activer les contrôles cliquables pris en charge à partir de leurs libellés visibles ; un écran simple ne nécessite donc pas de SDK vocal distinct.

Étape 1 : créer le projet Android.

• Dans Android Studio, choisissez New Project > Phone and Tablet > Empty Views Activity, puis sélectionnez Java et Views/XML.

• Utilisez le nom de package en domaine inversé de votre organisation (par exemple, com.company.fieldworkflow). Définissez minSdk en fonction de la version d'Android la plus ancienne de la flotte prise en charge, puis laissez Gradle se synchroniser.

• Installez Android SDK Platform-Tools depuis le SDK Manager afin de disposer d'adb pour les tests sur le casque.

Compatibilité de build : minSdk détermine les versions d'Android sur lesquelles l'application peut être installée. Les flottes de Navigator 520 fonctionnent sous Android 13 (API 33) avec le firmware 2.x ou sous Android 16 avec le firmware 3.0 : minSdk 33 couvre donc une flotte composée uniquement de 520 ; utilisez une valeur inférieure si des appareils plus anciens sont pris en charge, et testez sur les deux versions si la flotte est mixte. Définissez compileSdk et targetSdk sur des versions approuvées par votre organisation, puis vérifiez l'application et ses dépendances sur un casque géré avant le déploiement.

Étape 2 : définir l'écran.

• Dans le panneau Project d'Android Studio, ouvrez app > src > main > res > layout > activity_main.xml.

• Remplacez la mise en page générée par cet exemple. Il utilise les dp pour l'espacement et les sp pour le texte, comporte deux actions métier explicites et laisse les libellés vocaux visibles :

<?xml version="1.0" encoding="utf-8"?> <LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" android:layout_width="match_parent" android:layout_height="match_parent" android:orientation="vertical" android:padding="24dp">

<TextView android:id="@+id/screenTitle" android:layout_width="match_parent" android:layout_height="wrap_content" android:text="INSPECTION" android:textSize="24sp" />

<TextView android:id="@+id/instructionText" android:layout_width="match_parent" android:layout_height="wrap_content" android:layout_marginTop="12dp" android:text="Confirm the equipment status." android:textSize="20sp" />

<Button android:id="@+id/confirmButton" android:layout_width="match_parent" android:layout_height="wrap_content" android:layout_marginTop="20dp" android:minHeight="56dp" android:text="CONFIRM STATUS" />

<Button android:id="@+id/reportButton" android:layout_width="match_parent" android:layout_height="wrap_content" android:layout_marginTop="8dp" android:minHeight="56dp" android:text="REPORT ISSUE" />

<TextView android:id="@+id/statusText" android:layout_width="match_parent" android:layout_height="wrap_content" android:layout_marginTop="12dp" android:text="Waiting for selection" android:textSize="16sp" /> </LinearLayout>

Étape 3 : relier chaque bouton au comportement de l'application.

• Dans le panneau Project, ouvrez app > java > votre package > MainActivity.java.

• Remplacez l'activité générée par cet exemple, alignez sa déclaration de package sur le namespace Gradle et utilisez les ID de vue définis dans le XML. L'exemple met à jour un texte d'état local ; remplacez les commentaires par le flux de travail et les appels de service validés de l'entreprise :

package com.company.fieldworkflow;

import android.app.Activity; import android.os.Bundle; import android.widget.Button; import android.widget.TextView;

public class MainActivity extends Activity { @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main);

Button confirmButton = findViewById(R.id.confirmButton); Button reportButton = findViewById(R.id.reportButton); TextView statusText = findViewById(R.id.statusText);

confirmButton.setOnClickListener(view -> { // Appelez ici le flux d'inspection approuvé. statusText.setText("Status: confirmation recorded"); });

reportButton.setOnClickListener(view -> { // Validez et transmettez l'incident via le service de l'entreprise. statusText.setText("Status: issue reported"); }); } }

Étape 4 : n'ajouter une expression vocale personnalisée que si le libellé visible ne suffit pas.

• Dans activity_main.xml, placez cet attribut sur le Button CONFIRM STATUS existant. Le champ Android contentDescription influe également sur l'accessibilité. Vérifiez la commande vocale et le rendu d'accessibilité sur l'appareil cible, et localisez la commande dans chaque langue prise en charge par vos équipes :

<Button android:id="@+id/confirmButton" android:text="CONFIRM STATUS" android:contentDescription="hf_commands:CONFIRM STATUS, MARK COMPLETE" android:layout_width="match_parent" android:layout_height="wrap_content" />

Étape 5 : compiler et tester sur un Navigator 520.

• Sur un casque de test géré par l'organisation, dites MY SETTINGS, puis ADVANCED SETTINGS, puis ABOUT DEVICE ; dites PAGE DOWN jusqu'à ce que Build Number s'affiche, puis dites BUILD NUMBER environ sept fois, jusqu'à ce que le casque affiche « You are now a developer! ».

• Revenez à SYSTEM > DEVELOPER OPTIONS et activez le débogage USB (USB debugging), si la politique de l'entreprise l'autorise.

• Branchez un câble USB-C compatible avec le transfert de données et acceptez l'invite.

• Exécutez adb devices -l et vérifiez que l'état de l'appareil est device.

• Dans Android Studio, sélectionnez le casque et choisissez Run > Run app. Testez les libellés vocaux, le comportement au clic, les états d'erreur, l'adaptation à l'écran et le bruit attendu sur le lieu de travail.

adb devices -l # Vérifiez que le Navigator 520 apparaît avec l'état : device

Étape 6 : déployer l'APK interne via la gestion des appareils d'entreprise.

• Dans Ari Business Cloud, ouvrez Apps > Enterprise, ajoutez l'application, saisissez son nom et les informations de version, téléversez l'APK de release signé, puis sélectionnez Publish. Attribuez-la ensuite à l'appareil géré ou au groupe d'appareils approprié.

• Vous pouvez aussi utiliser la solution EMM/MDM approuvée par l'organisation, comme Microsoft Intune. RealWear précise que les applications téléversées par l'entreprise peuvent ne pas être optimisées pour Ari OS et que leurs versions doivent être mises à jour manuellement ; vérifiez la compatibilité avant le déploiement sur la flotte. Réservez les installations via ADB au développement et aux tests.

Approche low-code facultative : Microsoft Power Apps pour les flux de travail métier

Étape 1 : créer une application canevas dans l'environnement de l'entreprise

Avant de commencer : vérifiez que l'organisation dispose d'un environnement Power Platform approuvé, d'un accès créateur (maker), des licences nécessaires et de connecteurs métier approuvés. Créez et testez l'application dans cet environnement de travail ; n'utilisez ni compte Microsoft personnel ni source de données personnelle.

Créez l'écran sur un ordinateur dans Power Apps Studio, puis publiez-le dans l'environnement de l'entreprise et déployez le lecteur RealWear via la gestion des appareils d'entreprise.

1. Ouvrez Power Apps à l'adresse make.powerapps.com et connectez-vous avec le compte professionnel ou scolaire de votre organisation. Sélectionnez l'environnement approuvé qui contient l'application et les données métier.

2. Dans le volet de navigation de gauche, sélectionnez Create, puis Create from blank. Choisissez une application canevas et sélectionnez la disposition Responsive ou Tablet qui correspond à votre conception et à votre plan de déploiement.

3. Power Apps ouvre le canevas dans Power Apps Studio. Avant d'ajouter des contrôles, vérifiez que l'environnement, les licences et les connecteurs métier approuvés répondent aux exigences de votre organisation.

Ouvrir Microsoft Power Apps

Étape 2 : configurer l'écran pour le Navigator 520

Pour une mise en page fixe sur le Navigator, définissez un canevas tablette en mode paysage et prévisualisez l'application au format d'image de l'appareil. Si l'application doit s'adapter à plusieurs tailles d'appareil, utilisez des conteneurs responsives et testez chaque disposition prise en charge au lieu de forcer l'étirement d'une conception fixe.

1. Ouvrez Settings. Dans Power Apps Studio, ouvrez Settings, puis Display.

2. Choisissez Landscape pour la flotte de casques gérés. Le tutoriel Power Apps de RealWear utilise l'orientation paysage pour les mises en page destinées au casque.

3. Pour un canevas fixe, laissez Scale to fit activé afin que la conception s'adapte à l'affichage disponible. Pour un canevas responsive, ne le désactivez que si les contrôles utilisent des règles de disposition responsive et ont été testés à chaque taille cible.

4. Laissez Lock aspect ratio activé pour une application à mise en page fixe afin d'éviter toute déformation. Si vous utilisez une mise en page responsive, employez des conteneurs à disposition automatique et vérifiez l'absence de chevauchements ou de troncatures.

5. Ne laissez Lock orientation activé que si tous les appareils déployés utilisent le mode paysage. Enregistrez les paramètres, puis revenez au canevas.

Remarque sur l'affichage : le Navigator 520 dispose d'un écran physique de 1280 x 720, mais RealWear recommande aux développeurs Android d'utiliser des unités indépendantes de la densité plutôt que de concevoir en pixels bruts. L'appareil présente un espace de conception de 854 x 480 dp à sa densité par défaut.

Étape 3 : créer un écran par tâche

Partez de la décision opérationnelle que l'opérateur doit prendre. Ne recopiez pas un tableau de bord de bureau sur le casque.

1. Attribuez une seule mission à cet écran, par exemple vérifier un résultat d'inspection et décider de poursuivre ou de signaler un problème.

2. Déplacez les données secondaires, les paramètres et les validations vers un autre écran ou vers un flux de travail de back-office autorisé.

3. Ne conservez que les contrôles nécessaires à cette décision. Donnez à chaque contrôle un libellé distinct qui correspond à l'expression que WearHF doit reconnaître.

Test de l'écran : un bon écran vocal répond immédiatement à trois questions : Où suis-je ? Quelle information compte maintenant ? Que puis-je dire ensuite ?

Étape 4 : commencer par un texte grand et visible

Les recommandations Power Apps de RealWear préconisent un texte d'au moins 16sp, et de 20sp ou plus lorsque c'est possible. Utilisez des instructions concises, des libellés d'action visibles et un espacement suffisant ; vérifiez la lisibilité sur le casque plutôt que de vous fier au seul canevas sur ordinateur.

1. Ajoutez le titre de l'écran. Dans Power Apps Studio, allez dans Insert > Text et placez-le en haut de l'écran. Choisissez un titre court, comme INSPECTION STEP 3 ou MACHINE STATUS.

2. N'ajoutez que l'instruction nécessaire à la décision en cours. Répartissez les procédures plus longues sur plusieurs écrans.

3. Rendez les libellés d'action plus grands et plus visibles que le texte d'appui. Employez la même formulation pour le libellé et pour la commande vocale.

· Évitez les longs paragraphes lorsqu'une courte instruction suffit.

· Laissez de l'espace entre les contrôles.

· Ne réduisez pas la taille du texte simplement pour faire tenir davantage d'informations sur un même écran.

Étape 5 : utiliser des boutons texte, pas des contrôles composés uniquement d'icônes

Un utilisateur vocal doit savoir quoi dire. Une icône peut sembler familière sur un smartphone, mais elle n'indique pas automatiquement à l'opérateur quelle expression prononcer pour l'activer.

1. Insérez un bouton. Dans Power Apps Studio, utilisez Insert et ajoutez un contrôle Button.

2. Donnez-lui un libellé d'action visible. Par exemple CONTINUE, REPORT ISSUE ou OPEN CHECKLIST.

3. Alignez l'expression vocale sur le libellé visible. L'utilisateur doit pouvoir dire ce qu'il voit.

Pour programmer une simple transition d'écran, sélectionnez le bouton CONTINUE. Dans le sélecteur de propriétés à côté de la barre de formule, choisissez OnSelect et saisissez cette formule Power Fx. Remplacez scrNext par le nom réel de l'écran suivant ; pour toute action modifiant des données, utilisez le connecteur et la gestion des erreurs approuvés par l'organisation :

Navigate(scrNext, ScreenTransition.None)

Vous pouvez toujours utiliser une icône comme aide visuelle, mais conservez le libellé texte à côté. C'est le libellé qui rend l'action vocale compréhensible.

Dans Power Apps Studio, sélectionnez chaque Button et définissez Text = "REPORT ISSUE" et AccessibleLabel = "REPORT ISSUE" (remplacez l'exemple par l'action de ce bouton). Ne définissez Tooltip que si une aide supplémentaire est utile ; ne l'utilisez pas comme commande vocale cachée. Microsoft documente AccessibleLabel comme un texte destiné aux lecteurs d'écran, et RealWear ne documente ni cette propriété ni Tooltip comme un alias vocal garanti : vérifiez donc le libellé vocal sur le lecteur déployé.

Si une icône, un composant personnalisé ou un autre contrôle ne peut pas être sélectionné à la voix, proposez la même action via un Button standard visible et placez la formule de l'action dans la propriété OnSelect de ce bouton. Testez-le sur le casque. La solution de repli documentée par RealWear consiste à dire MY CONTROLS, puis MOUSE ; déplacez le curseur par des mouvements de tête et dites MOUSE CLICK. Considérez le contrôle du curseur comme une solution de repli, et non comme le moyen principal d'effectuer une action fréquente.

Étape 6 : choisir des commandes vocales faciles à reconnaître

RealWear recommande des commandes vocales de deux syllabes ou plus, car le moteur de reconnaissance parvient plus facilement à les distinguer de manière fiable.

• GO : CONTINUE
• YES : CONFIRM
• NO : CANCEL STEP
• NEXT : NEXT STEP
• OPEN : OPEN CHECKLIST

Il ne s'agit pas d'une interdiction stricte des mots courts, mais d'une règle pratique de fiabilité : des expressions plus longues et plus distinctives fournissent au système vocal davantage d'informations pour établir une correspondance.

Étape 7 : concevoir la saisie de texte pour la voix, pas pour le clavier

La sélection d'un TextInput ouvre le clavier vocal RealWear ; la dictée est un mode de saisie explicite, et non un flux continu de reconnaissance vocale. Pour une note courte, sélectionnez le champ, dites DICTATION, attendez la fin du compte à rebours, parlez, puis dites OK une fois la dictée terminée pour valider et fermer la fenêtre de texte. Pour saisir des caractères, dites VOICE KEYBOARD et énoncez les caractères en alphabet phonétique, puis dites ACCEPT. Ne dictez pas de mots de passe ni d'identifiants sensibles ; utilisez le clavier sécurisé ou une méthode de connexion approuvée par l'organisation. La dictée peut nécessiter un accès réseau : testez donc la langue cible et la connexion sur l'appareil géré. Privilégiez les contrôles à choix fixes lorsque la tâche peut être modélisée ainsi.

· Privilégiez une courte note dictée plutôt qu'un long formulaire.

· Utilisez des catégories sélectionnables pour les réponses courantes, comme LOW, MEDIUM et HIGH.

N'utilisez la capture de codes-barres ou de QR codes que si le contrôle ou l'intégration de scanner choisi est pris en charge par le lecteur RealWear et approuvé pour le flux de données de l'entreprise. Testez-la sur l'appareil réel.

· Recueillez les informations sur plusieurs écrans simples plutôt que dans un seul formulaire dense.

Étape 8 : garder les contrôles importants dans la zone de sécurité

Éloignez les titres, les instructions et les actions principales des bords extérieurs. RealWear prévient que les éléments situés en bordure peuvent entrer en concurrence avec d'autres informations visuelles et devenir plus difficiles à utiliser.

1. Centrez le contenu principal. Ne placez pas l'action principale directement contre le bord.

2. Laissez de l'espace autour des boutons. L'opérateur doit pouvoir identifier immédiatement les différentes actions.

3. Prévisualisez dans des conditions claires comme sombres. Un contraste simple fonctionne mieux que des effets décoratifs.

Étape 9 : publier et partager l'application au sein de l'organisation

Enregistrez et publiez l'application canevas dans l'environnement Power Platform approuvé. Partagez-la ensuite avec les utilisateurs professionnels concernés ou avec un groupe de sécurité de l'organisation. L'accès à l'application ne suffit pas : les utilisateurs ont également besoin des autorisations requises sur les tables Dataverse, les flux et les autres sources de données métier approuvées qui y sont connectés.

1. Sélectionnez Save dans Power Apps Studio et donnez à l'application un nom métier explicite.

2. Sélectionnez Publish, puis confirmez la version destinée au projet pilote. Publiez à nouveau après chaque modification ultérieure afin que les testeurs reçoivent la version actuelle.

3. Dans la liste Apps de Power Apps, sélectionnez l'application et choisissez Share. Accordez le droit d'exécution aux utilisateurs ou au groupe de sécurité Microsoft Entra ID approuvés, attribuez des autorisations de données selon le principe du moindre privilège et confirmez avec l'administrateur les licences Power Apps requises.

Étape 10 : déployer le lecteur Power Apps sur les Navigator gérés

L'application canevas Power Apps de l'entreprise s'exécute dans le lecteur Power Apps de RealWear. Déployez le lecteur sur la flotte de casques gérés ; l'écran lui-même reste conçu dans Power Apps Studio.

1. Dans Ari Business Cloud, ouvrez le RealWear App Marketplace, recherchez la fiche Microsoft Power Apps et sélectionnez Install. Choisissez l'appareil de test ou le groupe d'appareils approuvé. Pour une flotte gérée par Intune, suivez plutôt les instructions actuelles de RealWear relatives au déploiement d'APK d'entreprise.

2. Une fois l'installation terminée, ouvrez l'écran d'accueil du Navigator, dites MY PROGRAMS, puis ouvrez Power Apps.

3. Connectez-vous avec le compte professionnel ou scolaire de l'organisation qui a accès à l'application publiée et à ses sources de données. Validez toute demande de licence requise avec l'administrateur Power Platform.

4. Ouvrez l'application publiée depuis le lecteur et vérifiez que la version, les écrans et les données métier prévus sont disponibles.

Selon RealWear, WearML n'est pas disponible dans Power Apps après la connexion. Utilisez donc des libellés visibles, testez chaque contrôle sélectionnable à la voix et ne partez pas du principe que des directives WearHF Android natives peuvent être ajoutées à l'écran canevas.

Étape 11 : valider le flux de travail sur l'appareil réel

N'approuvez pas un écran sur la seule base de l'aperçu de Power Apps Studio. Testez-le avec le firmware cible du Navigator 520 et la configuration de déploiement de l'organisation.

1. Vérifiez que l'utilisateur sait où il se trouve et quelles actions sont disponibles sans toucher l'écran.

2. Prononcez chaque libellé visible exactement tel qu'il est écrit et vérifiez que la bonne action métier se déclenche.

3. Testez avec les EPI, les mouvements, les conditions réseau et le bruit prévus sur le lieu de travail. Vérifiez le comportement en cas d'opérations de données lentes, hors ligne ou en échec.

4. Demandez à un autre opérateur concerné d'effectuer la tâche. Corrigez les libellés ou la navigation qui suscitent une hésitation, puis refaites le test après avoir publié la version suivante.

5. Consignez la version de l'application, le firmware de l'appareil, les résultats des tests et les limites connues avant que l'organisation n'approuve un déploiement plus large.

Règles de mise en page pratiques pour le Navigator 520

• Un écran par tâche. Affichez l'étape en cours, uniquement les informations nécessaires à ce moment-là et l'action suivante disponible.

• Préférez quelques grands contrôles dotés d'un libellé texte aux boutons composés uniquement d'icônes ou aux menus chargés. RealWear recommande des commandes de plusieurs syllabes, car elles sont plus faciles à distinguer.

• En Android natif, utilisez les dp pour les largeurs, hauteurs et espacements, et les sp pour le texte. Le canevas par défaut du Navigator 520 correspond à 854 × 480 dp ; ne positionnez pas les contrôles en pixels physiques bruts de 1280 × 720.

• Éloignez les libellés et actions essentiels des bords de l'écran. Utilisez un contraste simple et testez dans les conditions d'éclairage, d'EPI et de mouvement prévues.

• Évitez les longs paragraphes et les formulaires en texte libre. Utilisez des instructions courtes, des choix structurés, une dictée approuvée ou des intégrations de scan validées.

• Pour les boutons natifs, alignez le libellé visible sur la commande vocale. N'ajoutez une directive WearHF que si le comportement par défaut du libellé ne répond pas aux besoins du flux de travail.

Nombre d'actions :

• À éviter : un écran surchargé de boutons
• Meilleure approche : uniquement les actions nécessaires à l'étape en cours

Taille du texte :

• À éviter : un texte petit pour faire tenir plus de contenu
• Meilleure approche : 16sp minimum ; environ 20sp ou plus lorsque c'est possible

Commandes :

• À éviter : GO, YES, NO
• Meilleure approche : CONTINUE, CONFIRM, CANCEL STEP

Boutons :

• À éviter : icône seule
• Meilleure approche : libellé texte visible, éventuellement accompagné d'une icône

Instructions :

• À éviter : long paragraphe
• Meilleure approche : une seule instruction courte ou plusieurs lignes courtes

Saisie de données :

• À éviter : grand formulaire comportant de nombreux champs
• Meilleure approche : une question à la fois, dictée, choix fixes ou scan

Navigation :

• À éviter : actions cachées dans des menus
• Meilleure approche : actions NEXT STEP, GO BACK ou OPEN CHECKLIST visibles

Couleurs :

• À éviter : nombreuses couleurs saturées et dégradés
• Meilleure approche : palette simple avec un contraste de texte net

Tests :

• À éviter : aperçu sur ordinateur uniquement
• Meilleure approche : tests sur le Navigator 520 sur le lieu de travail réel

Pourquoi les écrans complexes échouent avec la navigation vocale

Un écran techniquement correct peut tout de même ralentir un flux de travail mains libres. Trop d'informations ou trop de choix rendent la commande suivante plus difficile à identifier. RealWear recommande de limiter au maximum la saisie de textes longs et les paramètres complexes, et de valider la conception finale sur le casque réel.

À retenir : la règle de RealWear revient en fait à ceci : simplifiez le flux de travail avant d'optimiser les commandes vocales.

Conclusion : intégrer le parcours vocal à l'écran

Concevez chaque écran du Navigator 520 autour d'une seule tâche clairement définie. Utilisez des instructions concises, un texte lisible et des libellés visibles qui correspondent à la commande vocale. En Android natif, construisez des mises en page en dp/sp, reliez les écouteurs de clic des boutons standard à une logique métier validée et n'utilisez les directives WearHF que lorsque les libellés fixes ne suffisent pas. Pour un flux de travail Power Apps, utilisez le tenant, les licences, les autorisations de données et le lecteur RealWear géré approuvés par l'organisation. Testez sur l'appareil et le firmware réels avant de déployer sur l'ensemble de la flotte.

Vous développez un flux de travail mains libres pour le RealWear Navigator 520 ? VR Expert peut vous aider à évaluer l'appareil, à préparer un projet pilote et à déterminer si une application existante, Microsoft Power Apps ou une solution Android sur mesure est la mieux adaptée.

Découvrir le RealWear Navigator 520 pour les professionnels