v2.3 and still no navigator UI?? what gives?
Since the navigator ui was introduced I liked it a lot. I used it while on the PTC and was 100% relived that i didn't have to have the ugly grey bar with limited slots for apps i actually use just hanging there all the time. Then an update (which was more a downgrade) removed it and brought the old universal menu back which sucked. Then i hear the navigator is replacing the universal menu permanently - Awesome! except its been several months and 3 version updates since then and my quest is STILL using the ugly menu that is useless to me because i cant put more than one app i actually use on it and its just an eye sore when i using 2d apps. WHY? i get your goofy rollout process but its been months and months and updates keep coming but somehow not updating the UI? theres not even an option to choose? what is this bs?
Feature Request / UX Discussion: Separate Immersive App Control UI From 2D Apps
``` I’d like to discuss an issue with how immersive apps interact with running 2D apps when switching contexts using the Meta button on Quest. The problem is not the immersive app itself, but the 2D control window that appears for immersive apps (the window with Resume, Close, and other controls). When this window is shown, it is treated like a normal 2D app, and its appearance often causes currently running 2D apps to be minimized, closed, or refreshed. This behavior makes multitasking unreliable and forces users into specific app-launch sequences just to avoid losing state in their 2D apps. Proposed Behavior Change The idea is that the immersive app control window should not behave like a standard 2D app and should not interfere with other running 2D apps. Specifically: - Showing the immersive app’s control window should not minimize, close, or replace existing 2D app windows - The immersive app control UI should exist in a separate system layer, not the same layer as user-launched 2D apps - Running 2D apps should remain exactly as they are when the immersive app control UI appears - Access to Resume, Close, and related immersive controls should be possible without disrupting active 2D workflows - Ideally, immersive app controls could be accessed via a dedicated icon, overlay, or system-level panel rather than a standard 2D window In short: Viewing or interacting with immersive app controls should not be treated as “launching a 2D app.” Why This Matters - Prevents active 2D apps from being kicked out or refreshed - Makes switching between immersive and 2D contexts predictable - Improves productivity and multitasking - Reduces frustration caused by forced app restarts - Allows immersive apps to coexist cleanly with 2D workflows This could be implemented as an optional setting or as a revised default behavior for immersive app control UI, without removing any existing functionality. I’m interested to hear if others experience the same issue and whether separating immersive app controls from the 2D app system would improve overall usability. ```
Question about Meta UI and returning to app
Hello, I am reaching out on behalf of one of our clients, who has reported the following: While running our application, their users may occasionally press the Meta button, which invokes the Meta UI and temporarily makes it so they cannot interact with our application until the Meta UI is closed out of. This part makes perfect sense. However, the issue is that they have reported difficulty in closing out the Meta UI and returning back to our application. Normally, users can either press the Meta button again (or press the 'Resume' button while the Meta UI is overlayed) to return back to the application. In our client's case, they state that they have to press the Meta button / press the 'Resume' button multiple times before the Meta UI finally responds to the action and closes out, returning to the application. In their troubleshooting, they could not find any consistent pattern that would indicate a condition that triggers this. For instance: They are using Quest 3 headsets Some of them are on Shared Mode or Kiosk Mode, while others are not Some of them are on an MDM solution while others are not The controllers do not have any noticeable debris on them and are regularly cleaned with approved electronic sanitization products (i.e. low moisture wipes and set to dry in a UV cart, not using any sprays) The controller batteries are also regularly charged before any session of our application is run Tracking frequency on controllers is set to 'auto' *Especially for the 2nd and 3rd point listed above about Shared/Kiosk Mode and MDM solution - it does not matter whether these headsets have these enabled. The issue occurs on headsets that have these enabled as well as those in which these are not applicable. Can you kindly please suggest additional troubleshooting suggestions that our client can try, as this issue is significantly impacting their use of the application? Thank you, and please let me know if there are additional details I can share.
