![]() |
![]() |
![]() |
|
User Interaction Working GroupFrom Rex community wiki
MandateWithin the constraints of use cases and interactions within the design document, and the general consensus arrived at through the R&D process, develop a series of specific User Interface mock-ups suitable for implementation within Naali. GoalsMock-ups should both be implementable within the the current or near-future User Interface Component, but should represent an improvement over existing methods. Where feasible, it should take advantage of the specific nature of the domain and on-going UI research in order to deliver a polished product people will enjoy using. ProblemThe central problem of developing a interaction design for Naali is that it is a multi-use application. Any type of interaction design methodology based on specifying and designing for a limited set of use cases, will naturally have difficulty proposing a coherent design. So we must propose a "meta-UI"; a means of allowing other designers to implement their own specific-use UI, constraining the implementer to a set of domain-appropriate UI primitives and idioms. A kind of "window manager" for virtual worlds. The tabbed browsing implemented in all web browsers is a limited example of this "window manager within an application" -- although a little investigation can dig up more examples. Domain IdiomsSpaceClearly the defining characteristic of a 3D virtual world is a 3D space. Any UI design must clearly and primally present a 3D world view. AvatarSome applications require a model that represents the actions of the user in world, from movement, to gestures, to complex animations. However not all applications require this, and some may indeed require the user be disembodied. ActionsEach application comes with a finite set of appropriate actions given the context of the task. We cannot know ahead of time what these actions are, but we do know that some will be shared, some will be far more common that others, some will be hierarchical, some will be context-dependent, and not all actions may necessarily be presented to the user in a uniform format (such as menu hierarchies, or on-screen buttons). NotificationsIn the real world our brains are finely tuned to noticed changes in our environment that are important for us to notice and react to. In a virtual environment, many events are either difficult to notice given current interaction hardware, or can be presented in a far superior way in electronic form. A system of notifying the user of important events, and giving them a method to either ignore or act upon that event, is required to feel you are interactive with your world. LobbyIn the ideal world, transitioning from one space to the next would be seamless and unobtrusive to the user. However in a heterogeneous network, moving from space to space will likely cause gaps due to changes in protocol, changes in authorization regimes, or network disruptions. Moreover, application-specific interaction elements -- such as "teleporting", or match-making services (for a competitive game), may require the user to become disconnected to the real-time world. The Lobby is the "place" where the users "exists" during these discontinuities; that is, any time he is not actively participating in a 3D virtual space. Cut SceneFor many applications where non-interactive demonstrations are common (especially games), it is helpful if the world is not completely interactive, and the world author has the ability to temporarily control camera and avatar orientation. A Cut Scene is any time the user has his camera and avatar controls disabled in order to perform a pre-set demonstration by controlling the user's perspective. World ViewsAlthough the user will usually choose to operate his avatar with automatic camera control (as this is the simplest option), there are uses where multiple views of the same scene are desired. For example in-world building, or perhaps a scaled-out overview to be used as a map. CataloguesNot every object a user can interact with will be strictly in-world. Some will be held in abstract containers that belong to characters, builders, or vendors. Examples could be avatar inventory, builder library, or the merchandise list of a vendor. Choosing items from within a catalogue can daunting task if the user only has partial information about the object he is looking for; such as "it has a red blob in it", "the name starts with 'Foo'", or I made it in Blender. A good catalogue will allow the user to successfully execute his query and find the item he's looking for. Window ManagementWith many dialogues open on screen, the view can quickly become cluttered and a distraction or obstacle. If the user has organized their open dialogues, and the view is resized, the organization may be destroyed. If dialogues can be "docked" or "magnetized" along the edges of the view, they will always be in a predictable, unobtrusive place, even when the view is resized. Dialogues should also be able to attach to each other, to enable logical groupings of functionality. Context-based ActionsWhile the set of all possible actions and objects are immense, usually very few commonly accessed actions make sense on a specific object. When the user has selected an specific object for interaction, the most common actions, in the context of that object, should be immediately available and made primary within the UI. Mock-up 1 |
|||
![]() |
![]() |
![]() |





