UX - IDEATION - 3D - VR
Original Concepts and Proposals for Solving Complex Interaction Problems in Virtual Reality
VR Tutorial Functionality
“Tutor-BOT” or “People BOT” would be and actual in-world BOT that the user would interact with. This proposal is just dealing with explaining functions of the people app. Maybe there could be a few different BOT types, each tutoring a specific feature set of Hifi. The BOT could be used and positioned at the discretion of the domain admin.
Since the BOT has a physical 3D presence it can demonstrate all the functions of the people app using itself instead of another user’s avatar. The user would initiate the the tutorial by clicking the BOT. Maybe the user is prompted to click it. The user might be required to be within a set distance from the BOT.
VR Tutor Bot Interaction
The BOT would work in conjunction with the user’s tablet . The BOT would explain how to open the tablet or instruct the user to press the “people” button. Interaction would ideally include prerecorded voice narration (BOT character voice) but could also work with just text. A graphical “pointer” object (example: large, bold, colored arrow) would be used to focus the user’s attention on the specific button or control the BOT is explaining. There are probably some real technical challenges with this approach. It requires that both the BOT and the tablet be clearly in view and at the right size and proportion. There would be many specific interaction details to work out.
Tutorial Flow
The structure of the tutorial and user flow should ideally be made as simple as possible: (1) BOT explains function, (2) the pointer focuses the user’s attention (tablet) , (3) the user does the action (tablet), (4) the user sees/hears the result (in world), (Repeat 1) the BOT explains the next function. The sequence is repeated until all functions are explained or the user breaks off the tutorial session. This Approach would track the user’s action, the BOT’s action, what happens on the tablet and what happens in-world.
Personal Space Bubble
The following proposal can be viewed as a comprehensive safety system of interactive features however individual features could be implemented independently.
Broad Considerations and Objectives
A. Each user should feel safe and have some degree of control of interactions.
B. When examining potentially aggressive interactions the system should be fair, balanced and avoid rushed and/or unnecessary judgements.
C. Admins are also users and have rights to make decisions and set parameters within their respective domains.
D. The designed solution should ideally be as simple as possible.
E. Since we probably can’t envision every possible use case we should anticipate adding additional rules and functionality as it grows.
Determination of “Bad Actor” Behavior
There needs to be a (simple) set of rules to determine “bad actor” status.
Test: Which avatar was moving towards the other?
Test: How many times has the collision occurred?
There should also be tests to determine if the contact was accidental.
Test: Were both avatars in motion?
Test: Were one or both in the process of arriving in the domain?
Test: Were both users in conversation? (probably not easy to determine)
With a few simple tests hopefully we can get to 80% Accuracy
Bad Actor Escalation
If the collision/touch was clearly caused by one of the users and after the initial auto hiding or the user the user continues the behavior then they get a series of messages. Such as:
Alert 1: “You Seem to be getting awfully close to another user.”
Alert 2: “You violated their bubble space again!”
Alert 3: “Please review the good behavior guidelines.”
Space Bubble modal
If there have been multiple collisions in a short time but neither user is deemed to be a bad actor then user is shown a modal dialog box. The modal could be something like: “(name of other user) keeps bumping into you”
Choice A: Hide and Mute this user (and track)
Choice B: Make them an Associate (Handshake)
Choice C: Add them to my Friends List.
Usually modals force the user to make a decision before continuing. Alternately we can continue to use “Tablet needs your attention” and the user would deal with it there. Users already in My Friends List would not trigger any kind of messaging. There should also be a way for a user to disregard the dialog box. (close [X])
Time Out (Penalty Box)
When the user gets the third warning they are teleported to a designated location within the domain, facing a large sign with good conduct rules written out. Some bad actors may just be immature or ignorant of VR norms and need to be educated or reminded. The sign could also explain the escalation/kick policy of the specific domain.
Tracking Bad Actor
Keeping track of number of times issued timeout by the system. Keeping Track of number of times hidden and muted by another user
Panic Button
There may be unforeseen use cases such as a group ganging up on a single user in which the user feels unsafe and overwhelmed despite the other safety protocols. The Panic button could teleport them to a predetermined safe location or it could mute everyone and set everyone invisible.
Admin Control
Domain Admin could set threshold limit (timeouts, hides) for possible auto kick.
Domain Admin could set the domain up with no limit of contact, no warning, no escalation, no kick. A user in this domain could still retain the ability to hide/mute another and still have panic button.
Additional User Controls
User could set their own personal limits.
A. Set Threshold Limit (how many collisions before triggering hide/mute modal) B. Set Size of Bubble (as a % increase of current avatar scale)
C. Set Visibility of Bubble
Comfort Level Slider (concept) [cautious——()————————carefree] Sliding back and forth invisibly adjusts all the other safety parameters.
Notes of some ideas for redesigning the people app:
Analysis and Redesign of People App
Redesign of the people app is a big challenge. The existing people app combines several different sets of functionality in a small space. In general it probably has too many disparate functions and the UI is confusing. What do we really need it to do?
1. Set visibility and volume of other users.
2. Locate an individual within a group or within the domain
3. Manage/Search friends and connections
What are some of the existing problems?
A. The tablet blocks some portion of view of other users.
B. UI is confusing: buttons versus status indicators.
C. Which functions can be separated or regrouped?
Sketch : Connections Tab Showing Filtered List of Avatars/BOTS
Revised People App Concept: 3 Tabs
Connections : Has many filters to display any/all avatars or BOTS Availability : Allows user to set personal parameters and display name. Domain Map : 2D overhead view of domain to help locate others.
Me (and my Avatar) App
Instead of the “Availability” tab there could instead be a “Me” app separate from “people” app. The “me” app could might include some functionality of the avatar settings in Menu_Avatar . The user could control avatar settings, adjust their availability, set their display name etc.
Sketch : Avatar Selection “Magic Ring”
Magic Ring
In-world the user could simply click (select) an avatar and a ring would pop up around that person allowing the user to mute or hide them. The ring would be color coded green to indicate “friend” or blue: “connection” or clear for no connection. It would also dynamically indicate the other user’s audio level. Activating the people app would display all avatar’s rings in-world.