07 Sep Simplifying Virtual Reality Deployment Using ArborXR
Problem
As virtual reality headset adoption and accessibility has increased, so has the need for a system to manage and maintain the headsets. Gone are the days of sideloading a bespoke app to a headset and handing off the headset as the final step of a project. Now there’s an expectation for continued support, maintenance, and updates post-handoff. The “Headset Handoff” is now considered an early step in a project instead of the final step. And as training simulations are becoming more popular, as well as multiplayer multi-headset “classroom” style experiences becoming the norm for virtual reality, the need for a high-end headset management solution has become essential.
Solution
Enter ArborXR. After researching and evaluating different mobile headset management solutions, we settled on ArborXR. We had a project coming up that would require the support and maintenance of 50+ headsets, which would be deployed around the country. A project of this scale wouldn’t be feasible to maintain by shipping headsets for support. Plus, once deployed, there was the potential of additional experiences being added onto the deployed headsets, as well as a need for support and maintenance. ArborXR checked all the boxes for what we needed and more.
Implementation
We began loading up the headsets into ArborXR and deploying our software. The process was smooth, easy, and quick. Once all the headsets were loaded up, we confidently delivered the ready headsets to our client. Since they were all integrated into ArborXR, we were able to continuously push updates as the app was being developed, as well as provide hardware support and maintenance.
We also realized the need to build a channel for a separate group of headsets for “Early Access” for our Subject Matter Experts (SMEs) to sign off on before we pushed app updates to the other headsets. We were able to do all this remotely and to reconfigure the headsets organization to have the “Early Access” users have an early version of the app before we released it to the remaining deployed headsets (A new “release channel” feature will soon be released by ArborXR in 2023, which will make this process even easier). It gave us the confidence that the “Headset Handoff” step was just the beginning of our support relationship with the client.
Process Improvement
Once we had gone through the entire process within ArborXR, it made us reflect on ways that we manage and support our apps, and we implemented several process improvements from what we learned. We now have a higher standard of headset maintenance that we have brought in-house for our internal headsets as well.
A few of the improvements are outlined below:
• Consistent and clear app names, icons, descriptions, and version notes: While many of these are optional within ArborXR, we have begun formalizing app names, and utilizing app icons that match the client’s branding standards. For each new update, we also categorize the changes within version notes. The end-users are able to view these before they launch the app within their headsets, and it gives clarity and consistency to their experience. The app icon and 360 space the user loads into also reflect consistent branding as mandated by the client.
• Versioning increments: We track and verify each new app update version number to ensure it’s consistent across development and deployment and to formalize its use. From iteration to delivery, the version numbers maintain a consistent flow.
• Naming and tagging headsets: We codify a name in ArborXR for each headset and label the headset and controllers with physical labels. We are now able to quickly cross-reference which headset is which and easily manage controllers that align to that headset. We are also able to provide “Tags” within ArborXR to informally add notes to the headsets as well, including ownership of the headset, location, or modifications to the headset. (E.g., Name: Futurus | 0001 Tagged: Jake, UltraLeap)
• Tracking headsets: Utilizing ArborXR’s geo tracking, we can confirm locations of headsets. We were able to utilize this with one client to verify headsets successfully arrived at their locations (and connected online) by manually verifying the geo locations. This has also been helpful when we have client events with a lot of headsets brought in from many locations that then need to be redeployed; we can quickly verify the location of the headsets.
• Remote Management: Utilizing ArborXR’s remote streaming feature, we can troubleshoot headset issues through a live stream to our computers. Previously, we would have to be on a call with the client, and they’d have to put the headset on while we also put our headsets on so we could walk them through support, which oftentimes ended up in a frustrating and confusing situation. Streaming remotely directly to our computers makes troubleshooting magnitudes easier and more convenient for the client.
• Ease of deploying internal test builds for multiplayer tests: While developing multiplayer and training applications, we can deploy test builds internally to multiple headsets at once without having to have all the testers manually sideload the experience. Utilizing this to load the experience verifies everyone is using the correct version with a fresh install. We are also able to send uninstall commands to the headset to remove old versions so there won’t be any version mismatches.
Conclusion
While ArborXR, at its core, is a tool for remote headset management, we took some of the conventions of use and applied those into our internal processes. Now, utilizing the above efficiencies has become a core tenant of our app development and support structure.
Many more features are coming out for ArborXR down the road, and we are excited to bring those into our development and support process and find more efficiencies and improvements we can implement for both our internal teams and in support of our clients as well.
