Search Unity

UI/UX feedback

Discussion in 'EditorXR' started by Birkeman, Dec 15, 2016.

  1. Birkeman

    Birkeman

    Joined:
    Apr 22, 2013
    Posts:
    21
    Heya super cool to get to play around with this! I thought I would provide some feedback on the UI/UX while it's still fresh in my memory. I have used Tilt Brush quite a lot so I'm used to their UX convention so a lot of my feedback is essentially "make it more like Tilt Brush" but I do think a lot of the way their gestures and menus work are more natural. I use the Vive and was pleasantly surprised how easy it was to setup! Here's my most immediate feedback

    EditorVR Only working when Unity is in the foreground

    Writing this forum post I kept switching between sitting in front of my PC with my text editor and using unity with the HMD. It got annoying that I had to switch back to Unity for the scene to reappear in the HMD.

    Radial Menu
    I think this works fairly well but can be a bit fiddly selecting the right button. Have you tried arranging the buttons in two layers so it's not only the direction you are holding in but also the distance from the center of the touch pad that determines what button you are hitting? I would also like the radial menu to still appear if you are pointing at something inside a workspace. I had a bunch of objects I wanted to delete from my scene so it was cumbersome to have to first select it, point outside the workspace, wait for the menu to appear then delete it, and then continue to the next one.

    Also get rid of the animation when it appears, that's a second of wasted time whenever you click on something you want to edit.

    Scrolling in a workspace
    I keep wanting to use the touchpad for this since it's the standard vive UI convention. You could enable this behaviour and disable moving around with the touch pad if the user is pointing at a workspace. It's not likely a user wants to move around while looking at a workspace anyways ;)

    Moving workspaces
    It's fiddly to select the workspaces and move them around. Because it's mapped to the same button as using your current tool I kept doing that instead of grabbing the workspace. Using the grip button for that would fix that problem.

    Moving around with the touch pad

    This action should require that the pad is pressed instead of just touching it. I keep doing it by accident when I'm focusing on another part of the UI. Instead of mapping horizontal swiping to rotating I also think you should have that be strafing instead. Alternatively you could copy Tilt Brush's approach to navigating the scene with the double gripping that allows you to zoom in and out, translate and rotate all combined into one gesture.

    I also think the forward/backward movement should follow your view direction directly and not just on the horizontal plane so you can move up and down with it as well. I want to be superman!
     
    dilan_vl likes this.
  2. DylanU

    DylanU

    Unity Technologies

    Joined:
    Aug 16, 2016
    Posts:
    17
    Thanks for trying EditorVR.
    Very good points & input! We appreciate the feedback, and will take these suggestions into consideration as EVR evolves.
     
  3. greenmonster

    greenmonster

    Joined:
    Jan 18, 2013
    Posts:
    26
    "I think this works fairly well but can be a bit fiddly selecting the right button. Have you tried arranging the buttons in two layers so it's not only the direction you are holding in but also the distance from the center of the touch pad that determines what button you are hitting?"

    While this could work great on the Vive's touchpads, this might be hard to pull off on the Oculus Touch's thumbsticks since you have to press in on the thumbstick to select the highlighted option, and that's hard to do while keeping the stick halfway out.

    Conversely, I was hoping some functionality was mapped to the Oculus Touch's grip trigger, but I suspect that maybe the EVR devs shied away from that since the Vive's grip button is a bit of a pain to use sometimes.

    It's really tough to find parity between the two forms of input because of things like this, and I'd almost suggest that the EVR devs to avoid trying to unify the control scheme, and have separate control schemes for Touch and Vive.


    "Moving around with the touch pad
    This action should require that the pad is pressed instead of just touching it. I keep doing it by accident"

    Same here, although I just chalked it up to "I need more practice with these controls". For those sensitive to rotational motion, the current behavior would be less than ideal though.
     
  4. DylanU

    DylanU

    Unity Technologies

    Joined:
    Aug 16, 2016
    Posts:
    17
    @greenmonster We appreciate the input! As mentioned before, we'll keep the suggestions under consideration during further EVR development. That said, (EVR)EditorVR contains an interface, IUsesProxyType, used for handling input for specific proxy/controller cases (see MainMenu.cs).
     
  5. ugur

    ugur

    Joined:
    Jun 3, 2008
    Posts:
    692
    Just gave it a test ride, too and yes, EVR has lots of potential and in between it is already fun to use.
    I mostly agree with Birkeman's feedback and especially regarding the point that one should have to press the touchpad to move around, i had it a bunch of times that i moved around accidentally by just touching the touchpad and it can be very disorientating when that happens by accident while one wanted to do something different =)
     
  6. timoni

    timoni

    Joined:
    Mar 23, 2015
    Posts:
    12
    Agreed on the touchpad 100%, and all of the rest of the feedback is great, too. Keep it coming!
     
  7. TexasGreenTea

    TexasGreenTea

    Joined:
    Dec 26, 2016
    Posts:
    12
    I second the grip-button-to-grab suggestion. I haven't used Tiltbrush very much, but I've been using Oculus Medium a lot. The grab convention is the same there. I think the main trigger should still be used to select an object. The grip button should slave workspaces and game objects to the grabbing hand independently of the current selection. Grab should affect whatever UI or object is the first raycast hit of the grabbing hand, even if that object is not currently selected. For instance, say there's a group of objects you've currently selected, but you want to move another object that's occluding them. You won't want to deselect the current group in order to move the one that's in the way, and then re-select them all again.