Designa röststyrda skärmar för RealWear Navigator 520

Sammanfattning

RealWear Navigator 520 använder röstnavigering som bygger på skärmelement som medarbetaren kan se och säga. Krymp inte bara en mobillayout till headsetet; visa de tillgängliga åtgärderna tydligt och låt WearHF koppla talade kommandon till kontroller som stöds.

RealWear rekommenderar att man begränsar lång textinmatning, komplexa inställningar och överfulla skärmar. Använd en uppgift per skärm, kortfattade instruktioner, läsbar text och tydligt åtskilda, synliga etiketter. Tillämpa samma principer i en arbetsyteapp och i en inbyggd Android-app.

Utvecklingsteam har två affärsmässigt beprövade vägar. Använd inbyggd Android med WearHF när arbetsflödet kräver anpassat enhetsbeteende, offlinehantering eller integration med företagets system. Använd Microsoft Power Apps när organisationen redan hanterar arbetsflödet i Power Platform och RealWear-spelaren stöder de appfunktioner du behöver. Den inbyggda vägen nedan innehåller exempel i XML och Java; Power Apps-vägen är ett valfritt lågkodsalternativ.

Grundregel: Ett röstgränssnitt är inte en vanlig mobilskärm där tal har lagts till i efterhand. Skärmen i sig ska visa medarbetaren vad som kan sägas.

Vad är RealWear Navigator 520?

Navigator 520 är en robust, handsfree Android-enhet för industriellt arbete som underhåll, inspektion och fältservice. RealWear anger skärmupplösningen till 1280 × 720 pixlar och programvaran för Navigator 520 till Ari OS (Android 13) med WearHF. Sedan underhållsversionen Ari OS 2.0 den 17-09-2026 (firmware 3.0) kör uppdaterade enheter Android 16, så kontrollera vilket bygge flottan har. Bekräfta firmware och skärmkonfiguration i enhetsflottan före lansering.

RealWear mappar Navigator 520:s standardskärm på 720p till en Android-layoutyta på 854 × 480 dp vid 240 dpi. Använd dp för layoutmått och sp för text i stället för hårdkodade fysiska pixlar. Håll skärmen enkel, eftersom displayen bara täcker en del av medarbetarens synfält.

Se produktsidan för RealWear Navigator 520 hos VR Expert

Välj en implementeringsväg för företaget

Använd inbyggd Android när du behöver anpassat beteende, integration eller kontroll över releaser. Använd Power Apps när företaget redan har en Power Platform-miljö och appen kan hållas inom de funktioner som stöds för arbetsyteappar.

Microsoft Power Apps:

• Där du designar: Power Apps Studio i en webbläsare
• Passar bäst för: Företag med en godkänd Power Platform-klient som behöver ett affärsarbetsflöde med lågkod.

Inbyggd Android-app:

• Där du designar: Android Studio + WearHF/WearML
• Passar bäst för: Utvecklingsteam som behöver anpassat Android-beteende, integration med företagets system eller kontroll över den hanterade releasen.

Båda vägarna kräver en identitet som godkänts av organisationen, åtkomst till rätt verksamhetsmiljö och behörigheter för varje ansluten datakälla. Testa på den hanterade flottan av Navigator 520, inte bara i en förhandsgranskning på datorn.

Inbyggd Android-väg: bygg en röststyrd skärm

En Android-View är en standardkontroll på skärmen, till exempel en Button eller TextView. WearHF körs på enheten och kan aktivera klickbara kontroller som stöds utifrån deras synliga etiketter, så en enkel skärm behöver inget separat tal-SDK.

Steg 1: Skapa Android-projektet.

• I Android Studio väljer du New Project > Phone and Tablet > Empty Views Activity och sedan Java och Views/XML.

• Använd organisationens paketnamn med omvänd domän (till exempel com.company.fieldworkflow). Ställ in minSdk efter den äldsta Android-versionen i den flotta som stöds och låt sedan Gradle synkronisera.

• Installera Android SDK Platform-Tools via SDK Manager så att adb finns tillgängligt för tester på headsetet.

Byggkompatibilitet: minSdk styr vilka Android-versioner som kan installera appen. Flottor av Navigator 520 kör Android 13 (API 33) med firmware 2.x eller Android 16 med firmware 3.0, så minSdk 33 täcker en flotta med enbart 520-enheter; använd ett lägre värde om äldre enheter stöds, och testa på båda byggena om flottan är blandad. Ställ in compileSdk och targetSdk på versioner som din organisation har godkänt och verifiera sedan appen och dess beroenden på ett hanterat headset före utrullning.

Steg 2: Definiera skärmen.

• Öppna app > src > main > res > layout > activity_main.xml i panelen Project i Android Studio.

• Ersätt den genererade layouten med det här exemplet. Det använder dp för avstånd och sp för text, har två tydliga verksamhetsåtgärder och låter de talade etiketterna vara synliga:

<?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>

Steg 3: Koppla varje knapp till appens beteende.

• Öppna app > java > ditt paket > MainActivity.java i panelen Project.

• Ersätt den genererade aktiviteten med det här exemplet, se till att paketdeklarationen stämmer med Gradle-namnrymden och använd vy-ID:na från XML-filen. Exemplet uppdaterar en lokal statustext; ersätt kommentarerna med företagets validerade arbetsflöde och tjänsteanrop:

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 -> { // Call the approved inspection workflow here. statusText.setText("Status: confirmation recorded"); });

reportButton.setOnClickListener(view -> { // Validate and submit the issue through the company service. statusText.setText("Status: issue reported"); }); } }

Steg 4: Lägg bara till en anpassad talad fras när den synliga etiketten inte räcker.

• I activity_main.xml placerar du det här attributet på den befintliga knappen CONFIRM STATUS. Android-fältet contentDescription påverkar även tillgängligheten. Verifiera det talade kommandot och tillgänglighetsutdata på målenheten, och lokalisera kommandot för varje språk som personalen använder och som stöds:

<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" />

Steg 5: Bygg och testa på en Navigator 520.

• På ett testheadset som hanteras av organisationen säger du MY SETTINGS, sedan ADVANCED SETTINGS och sedan ABOUT DEVICE; säg PAGE DOWN tills Build Number syns och säg sedan BUILD NUMBER ungefär sju gånger tills headsetet visar ”You are now a developer!”.

• Gå tillbaka till SYSTEM > DEVELOPER OPTIONS och aktivera USB-felsökning, om företagets policy tillåter det.

• Anslut en USB-C-kabel som klarar dataöverföring och godkänn uppmaningen.

• Kör adb devices -l och bekräfta att enhetens status är device.

• Välj headsetet i Android Studio och välj Run > Run app. Testa talade etiketter, klickbeteende, felstatus, hur innehållet passar på skärmen och det buller som kan förväntas på arbetsplatsen.

adb devices -l # Confirm that the Navigator 520 appears with status: device

Steg 6: Driftsätt den interna APK-filen via företagets enhetshantering.

• I Ari Business Cloud öppnar du Apps > Enterprise, lägger till appen, anger namn och versionsuppgifter, laddar upp den signerade release-APK-filen och väljer Publish. Tilldela den sedan till lämplig hanterad enhet eller enhetsgrupp.

• Alternativt kan du använda organisationens godkända EMM/MDM, till exempel Microsoft Intune. RealWear påpekar att appar som laddats upp av företaget kanske inte är optimerade för Ari OS och att versioner måste uppdateras manuellt; verifiera kompatibiliteten före utrullning i flottan. Använd ADB-installationer endast för utveckling och testning.

Valfri lågkodsväg: Microsoft Power Apps för affärsarbetsflöden

Steg 1: Skapa en arbetsyteapp i företagets miljö

Innan du börjar: bekräfta att organisationen har en godkänd Power Platform-miljö, behörighet att skapa appar, nödvändiga licenser och godkända affärskopplingar. Skapa och testa appen i den arbetsmiljön; använd inte ett personligt Microsoft-konto eller en personlig datakälla.

Skapa skärmen på en dator i Power Apps Studio, publicera den sedan i företagets miljö och driftsätt RealWear-spelaren via företagets enhetshantering.

1. Öppna Power Apps på make.powerapps.com och logga in med organisationens arbets- eller skolkonto. Välj den godkända miljö som innehåller affärsappen och dess data.

2. I den vänstra navigeringen väljer du Create och sedan Create from blank. Välj en arbetsyteapp och välj layouten Responsive eller Tablet, beroende på vad som passar din design och driftsättningsplan.

3. Power Apps öppnar arbetsytan i Power Apps Studio. Innan du lägger till kontroller ska du bekräfta att miljön, licenserna och de godkända affärskopplingarna uppfyller organisationens krav.

Öppna Microsoft Power Apps

Steg 2: Anpassa skärmen för Navigator 520

För en fast Navigator-layout ställer du in en liggande surfplatte-arbetsyta och förhandsgranskar appen i enhetens bildförhållande. Om appen måste anpassas till flera enhetsstorlekar använder du responsiva behållare och testar varje layout som stöds, i stället för att tvinga en fast design att sträckas ut.

1. Öppna Settings. Öppna Settings och sedan Display i Power Apps Studio.

2. Välj Landscape för den hanterade headsetflottan. RealWears självstudie för Power Apps använder liggande orientering för headsetlayouter.

3. För en fast arbetsyta låter du Scale to fit vara aktiverat så att designen skalas till den tillgängliga skärmytan. För en responsiv arbetsyta stänger du bara av det när kontrollerna använder responsiva layoutregler och har testats i varje målstorlek.

4. Låt Lock aspect ratio vara aktiverat i en app med fast layout för att förhindra förvrängning. Om du använder en responsiv layout ska du använda behållare med automatisk layout och testa att inget överlappar eller klipps av.

5. Låt Lock orientation vara aktiverat endast om alla driftsatta enheter används i liggande läge. Spara inställningarna och gå sedan tillbaka till arbetsytan.

Om skärmen: Navigator 520 har en fysisk skärm på 1280 x 720, men RealWear rekommenderar att Android-utvecklare använder densitetsoberoende enheter i stället för att designa efter råa pixlar. Enheten erbjuder en designyta på 854 x 480 dp vid standarddensitet.

Steg 3: Bygg en skärm för en arbetsuppgift

Utgå från det operativa beslut som medarbetaren måste fatta. Kopiera inte en instrumentpanel från datorn till headsetet.

1. Välj en enda uppgift för den här skärmen, till exempel att kontrollera ett inspektionsresultat och avgöra om arbetet ska fortsätta eller om ett problem ska rapporteras.

2. Flytta sekundära data, inställningar och godkännanden till en annan skärm eller till ett behörigt backoffice-arbetsflöde.

3. Behåll bara de kontroller som behövs för just det här beslutet. Ge varje kontroll en tydligt åtskild etikett som motsvarar den fras WearHF ska känna igen.

Skärmtest: En bra röstskärm besvarar tre frågor direkt: Var är jag? Vilken information är viktig just nu? Vad kan jag säga härnäst?

Steg 4: Lägg först till stor, synlig text

RealWears vägledning för Power Apps rekommenderar text som inte är mindre än 16sp, och 20sp eller större där det är praktiskt möjligt. Använd kortfattade instruktioner, synliga åtgärdsetiketter och tillräckligt med avstånd; kontrollera läsbarheten på headsetet i stället för att enbart lita på arbetsytan på datorn.

1. Lägg till skärmrubriken. I Power Apps Studio går du till Insert > Text och placerar den högst upp på skärmen. Använd en kort rubrik som INSPECTION STEP 3 eller MACHINE STATUS.

2. Lägg bara till den instruktion som krävs för det aktuella arbetsbeslutet. Dela upp längre procedurer på flera skärmar.

3. Gör åtgärdsetiketterna större och mer framträdande än stödtexten. Använd samma formulering i etiketten och i det talade kommandot.

· Undvik långa stycken när en kort instruktion räcker.

· Lämna luft mellan kontrollerna.

· Krymp inte texten bara för att få plats med mer information på en skärm.

Steg 5: Använd textknappar, inte kontroller med enbart ikoner

En röstanvändare behöver veta vad hen ska säga. En ikon kan se bekant ut på en telefon, men den talar inte automatiskt om för medarbetaren vilken talad fras som aktiverar den.

1. Infoga en knapp. Använd Insert i Power Apps Studio och lägg till en Button-kontroll.

2. Ge den en synlig åtgärdsetikett. Exempel är CONTINUE, REPORT ISSUE eller OPEN CHECKLIST.

3. Håll den talade frasen och den synliga etiketten samstämmiga. Användaren ska kunna säga det hen ser.

För att koppla en enkel skärmövergång väljer du knappen CONTINUE. I egenskapsväljaren bredvid formelfältet väljer du OnSelect och anger den här Power Fx-formeln. Ersätt scrNext med det faktiska namnet på nästa skärm; använd organisationens godkända koppling och felhantering för alla åtgärder som ändrar data:

Navigate(scrNext, ScreenTransition.None)

Du kan fortfarande använda en ikon som visuellt stöd, men behåll textetiketten bredvid den. Det är etiketten som gör röståtgärden begriplig.

Välj varje Button i Power Apps Studio och ställ in Text = "REPORT ISSUE" och AccessibleLabel = "REPORT ISSUE" (ersätt exemplet med den aktuella knappens åtgärd). Ställ bara in Tooltip när extra hjälp är användbar; använd det inte som ett dolt röstkommando. Microsoft dokumenterar AccessibleLabel som text för skärmläsare, och RealWear dokumenterar varken den eller Tooltip som ett garanterat röstalias, så verifiera den talade etiketten i den driftsatta spelaren.

Om en ikon, en anpassad komponent eller en annan kontroll inte kan väljas med rösten, gör samma åtgärd tillgänglig via en synlig standardknapp (Button) och lägg åtgärdsformeln i knappens OnSelect-egenskap. Testa det på headsetet. RealWears dokumenterade reservlösning är att säga MY CONTROLS och sedan MOUSE, flytta markören med huvudrörelser och säga MOUSE CLICK. Se markörstyrning som en reservlösning, inte som huvudvägen för en åtgärd som används ofta.

Steg 6: Välj röstkommandon som är lätta att känna igen

RealWear rekommenderar röstkommandon med två eller fler stavelser, eftersom de är lättare för taligenkänningen att särskilja på ett tillförlitligt sätt.

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

Det här är inget strikt förbud mot korta ord. Det är en praktisk regel för tillförlitlighet: längre och mer särpräglade fraser ger talsystemet mer information att matcha mot.

Steg 7: Utforma textinmatning för röst, inte för tangentbord

När du väljer en TextInput öppnas RealWears taltangentbord; diktering är ett uttryckligt inmatningsläge, inte en kontinuerlig tal-till-text-ström. För en kort anteckning väljer du fältet, säger DICTATION, väntar på nedräkningen, talar och säger sedan OK när dikteringen är klar för att godkänna och stänga textfönstret. För inmatning tecken för tecken säger du VOICE KEYBOARD och anger tecknen fonetiskt, och säger sedan ACCEPT. Diktera inte lösenord eller känsliga identifierare; använd det säkra tangentbordet eller en inloggningsmetod som organisationen har godkänt. Diktering kan kräva nätverksåtkomst, så testa målspråket och anslutningen på den hanterade enheten. Välj hellre kontroller med fasta alternativ när uppgiften kan utformas så.

· Använd en kort dikterad anteckning i stället för ett långt formulär.

· Använd valbara kategorier för vanliga svar, till exempel LOW, MEDIUM och HIGH.

Använd streckkods- eller QR-läsning endast när den valda skannerkontrollen eller integrationen stöds av RealWear-spelaren och är godkänd för företagets dataflöde. Testa den på den faktiska enheten.

· Fråga efter information över flera enkla skärmar i stället för i ett enda kompakt formulär.

Steg 8: Håll viktiga kontroller inom det säkra området

Håll rubriker, instruktioner och huvudåtgärder borta från ytterkanterna. RealWear varnar för att element vid kanterna kan konkurrera med annan visuell information och bli svårare att använda.

1. Håll huvudinnehållet centrerat. Placera inte den primära åtgärden direkt mot kanten.

2. Lämna utrymme runt knapparna. Medarbetaren ska direkt kunna urskilja separata åtgärder.

3. Förhandsgranska i både ljusa och mörka förhållanden. Enkel kontrast fungerar bättre än dekorativa effekter.

Steg 9: Publicera och dela appen inom organisationen

Spara och publicera arbetsyteappen i den godkända Power Platform-miljön. Dela den sedan med de avsedda användarna eller med en säkerhetsgrupp i organisationen. Det räcker inte med åtkomst till appen: användarna behöver också de behörigheter som krävs till anslutna Dataverse-tabeller, flöden och andra godkända datakällor i verksamheten.

1. Välj Save i Power Apps Studio och ge appen ett tydligt verksamhetsnamn.

2. Välj Publish och bekräfta sedan den version som är avsedd för piloten. Publicera igen efter senare ändringar så att testarna får den aktuella versionen.

3. Gå till listan Apps i Power Apps, välj appen och välj Share. Ge körbehörighet till de godkända användarna eller säkerhetsgruppen i Microsoft Entra ID, tilldela databehörigheter enligt principen om minsta behörighet och bekräfta de Power Apps-licenser som krävs med administratören.

Steg 10: Driftsätt Power Apps-spelaren på hanterade Navigator-enheter

Företagets arbetsyteapp i Power Apps körs i RealWears Power Apps-spelare. Driftsätt spelaren på den hanterade headsetflottan; själva skärmen skapas fortfarande i Power Apps Studio.

1. I Ari Business Cloud öppnar du RealWear App Marketplace, letar upp Microsoft Power Apps och väljer Install. Välj den godkända testenheten eller enhetsgruppen. För en flotta som hanteras med Intune följer du i stället RealWears aktuella instruktioner för driftsättning av företags-APK:er.

2. När installationen är klar öppnar du Navigators startskärm, säger MY PROGRAMS och öppnar sedan Power Apps.

3. Logga in med det arbets- eller skolkonto i organisationen som har åtkomst till den publicerade appen och dess datakällor. Bekräfta eventuella licensfrågor med Power Platform-administratören.

4. Öppna den publicerade appen från spelaren och kontrollera att avsedd version, skärmar och verksamhetsdata är tillgängliga.

Enligt RealWear är WearML inte tillgängligt i Power Apps efter inloggning. Använd därför synliga etiketter, testa varje kontroll som ska kunna väljas med rösten och utgå inte från att inbyggda Android-direktiv för WearHF kan läggas till på arbetsytan.

Steg 11: Validera arbetsflödet på den riktiga enheten

Godkänn inte en skärm enbart utifrån förhandsgranskningen i Power Apps Studio. Testa med den firmware som Navigator 520 ska köra och med organisationens driftsättningskonfiguration.

1. Kontrollera att användaren kan avgöra var hen befinner sig och vilka åtgärder som finns utan att röra skärmen.

2. Säg varje synlig etikett exakt som den står skriven och bekräfta att rätt verksamhetsåtgärd utförs.

3. Testa under de förväntade förhållandena när det gäller skyddsutrustning (PPE), rörelser, nätverk och buller på arbetsplatsen. Kontrollera långsamma, offline- och misslyckade dataoperationer.

4. Be en annan avsedd användare att utföra uppgiften. Åtgärda etiketter eller navigering som får användaren att tveka och upprepa sedan testet efter att nästa version har publicerats.

5. Dokumentera appversion, enhetens firmware, testresultat och kända begränsningar innan organisationen godkänner en bredare utrullning.

Praktiska layoutregler för Navigator 520

• Använd en skärm för en arbetsuppgift. Visa det aktuella steget, bara den information som behövs just nu och nästa tillgängliga åtgärd.

• Välj hellre några få stora kontroller med textetiketter än knappar med enbart ikoner eller kompakta menyer. RealWear rekommenderar kommandon med flera stavelser eftersom de är lättare att särskilja.

• För inbyggd Android använder du dp för bredd, höjd och avstånd och sp för text. Navigator 520:s standardarbetsyta motsvarar 854 × 480 dp; placera inte kontroller utifrån råa fysiska pixlar på 1280 × 720.

• Håll viktiga etiketter och åtgärder borta från skärmens kanter. Använd enkel kontrast och testa under de förväntade förhållandena när det gäller belysning, skyddsutrustning och rörelser.

• Undvik långa stycken och formulär med fritext. Använd korta instruktioner, strukturerade val, godkänd diktering eller validerade skanningsintegrationer.

• För inbyggda knappar ska den synliga etiketten och det talade kommandot stämma överens. Lägg bara till ett WearHF-direktiv när standardbeteendet för etiketter inte räcker för arbetsflödet.

Antal åtgärder:

• Undvik: En överfull skärm med många knappar
• Bättre: Bara de åtgärder som behövs för det aktuella steget

Textstorlek:

• Undvik: Liten text för att få plats med mer innehåll
• Bättre: Minst 16sp; omkring 20sp eller större där det är praktiskt möjligt

Kommandon:

• Undvik: GO, YES, NO
• Bättre: CONTINUE, CONFIRM, CANCEL STEP

Knappar:

• Undvik: Enbart ikon
• Bättre: Synlig textetikett, eventuellt med en ikon

Instruktioner:

• Undvik: Långt stycke
• Bättre: En kort instruktion eller flera korta rader

Datainmatning:

• Undvik: Stort formulär med många fält
• Bättre: En fråga i taget, diktering, fasta alternativ eller skanning

Navigering:

• Undvik: Dolda menyåtgärder
• Bättre: Synliga åtgärder som NEXT STEP, GO BACK eller OPEN CHECKLIST

Färg:

• Undvik: Många mättade färger och övertoningar
• Bättre: Enkel färgpalett med tydlig textkontrast

Testning:

• Undvik: Enbart förhandsgranskning på datorn
• Bättre: Testa på Navigator 520 på den faktiska arbetsplatsen

Varför komplexa skärmar fungerar dåligt med röstnavigering

En tekniskt korrekt skärm kan ändå göra ett handsfree-arbetsflöde långsammare. För mycket information eller för många val gör det svårare att avgöra nästa kommando. RealWear rekommenderar att man minimerar lång textinmatning och komplexa inställningar och validerar den färdiga designen på det faktiska headsetet.

Praktisk slutsats: RealWears egen regel är i praktiken: förenkla arbetsflödet innan du optimerar röstkommandona.

Slutsats: bygg in röstvägen i skärmen

Utforma varje skärm på Navigator 520 kring en tydlig arbetsuppgift. Använd kortfattade instruktioner, läsbar text och synliga etiketter som matchar det talade kommandot. För inbyggd Android bygger du med dp/sp-layouter, kopplar vanliga klicklyssnare för knappar till validerad affärslogik och använder WearHF-direktiv bara när fasta etiketter inte räcker. För ett arbetsflöde i Power Apps använder du organisationens godkända klient, licenser, databehörigheter och hanterade RealWear-spelare. Testa på den faktiska enheten och firmwareversionen innan du driftsätter i hela flottan.

Bygger du ett handsfree-arbetsflöde för RealWear Navigator 520? VR Expert kan hjälpa till att utvärdera enheten, förbereda en pilot och testa om en befintlig app, Microsoft Power Apps eller en anpassad Android-lösning passar bäst.

Utforska RealWear Navigator 520 för företag