-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New Pause Menu / UI Overhaul #55
Comments
I really like this part, I can already imagine how with such smart cursor a website could be navigated using a VR headset only ( without controllers )
I like that there is a possibility to switch between the two, but the switch isn't intuitive.
I would not get rid of the pause menu / start menu personally.
I totally agree on the compass thing :)
I think you can't avoid that.
I think a simple button will be better. As far as I know most mobile games have some kind of UI constantly showing. Well it looks like I'm criticizing a lot here 😅 Hit me up on Discord if you want to discuss "live" some of the points here. Again, it's really exciting what you're building ! I really want to see the final product ! |
The main qualities I'm optimizing for are immersion and onboarding To maximize immersion, you basically have to get rid of everything that reminds you that this is a website – you want to feel like you're living in the world. That's why using our sites on fullscreen feels so much better than a maximum sized window - even just the toolbar at the top of your browser is enough to kill the illusion. (why I'm thinking about making the site go fullscreen when you press continue lol). And, of course, why the headset is magical. The drive for immersion impacts
To optimize the onboarding process, I'm looking to bring the amount of the time the user doesn't know what to do to zero. This means making it painstakingly obvious to click a button that should be clicked (i.e. tutorial, see https://muse.place). This impacts
To answer to some of your other points
In my head, I think of the click/drag controls as the "beginner" controls and the pointer lock as the "advanced" control scheme, so hiding it behind an input sequence that's hard to accidentally do seems correct. That was my train of thought, but typing it out it's a little shaky haha. I think we really need to do some user testing on either
I will die on this grave (but seriously, depends on the standard for this sort of stuff, i think i may be the weird one here haha)
I'm coming from the angle of tiktok's scroll, or iphone's pull to show the menu. you just kinda drag your fat finger down the screen and it works. might take a little bit of a learning curve, but it's hidden when not in use and requires no onscreen button to interact. |
I see what you mean, but I also feel like VR is the only one that doesn't need that pause menu etc. But I understand that you have a vision and a goal, they'll cause accessibility issues here and there and I'll try to help fix as many of them in an unconventional way to respect what you're trying to aim at. Then I guess you should go ahead with the no menu / no 2D, full screen etc and we'll work on each issue that come from the initial vision.
The Mozilla example you linked to used it too and it didn't feel weird there. Maybe I got used to it over night or it's because it's less sensitive but It's not such a big issue for me anymore :) |
Started this branch a while back and never got to finishing it. Want to see where to take it.
https://github.com/spacesvr/spacesvr/tree/ui-ux
https://spacesvr-gjudb1xki-metaplug.vercel.app/
This would be a pretty big shift in how things work, so i want to consider pros and cons before even starting.
it's got
unsolved problems are
The text was updated successfully, but these errors were encountered: