Revision as of 18:02, 24 May 2009

Late Submission! This proposal was submitted after the official deadline. Thus, it might not have been reviewed sufficiently by the community.

Design Proposal by Andreas Schuderer

ux.openoffice.org

Quick Navigation

Team

Please do not edit this page unless you are the original author. Your feedback and comments are welcome in the Comments section below or on the ui@ux.openoffice.org mailing list.

The following design proposal is part of the collection of design proposals for “Accessing Functionality”, which is part of Project Renaissance.

Summary and Status

In this proposal, I suggest these changes to the interface:

Make Keyboard Command Invocation the primary method of invoking commands.
Combine Direct Manipulation and the Context Menu into one paradigm for working with visible items.
Put all item properties in a scrolling sidebar (only properties, not commands)
Replace Wizards with Activity Guides

Status: Currently uploading and editing.

Then: Request for Comments

Goals

This proposal tries to improve the following aspects (adapted from http://www.mprove.de/script/02/raskin/designrules.html):

1. Make the interface more habituating.

Commentary. If the interface can be operated habitually then, after you have used it for a while, its use becomes automatic and you can release all your attention to the task you are trying to achieve.

2. Reduce modes, aiding habituation and reducing errors.

Commentary. Modes exist where the same user action yields different results depending on system state at a time when your attention is not on system state. In the presence of modes, you will sometimes make mode errors, where you make a gesture intending to have one result but get a different and unexpected result, distracting you from your task.

3. Reduce the number of used concepts in the interface. Attempt monotony.

Commentary. "Monotony" here is a technical term meaning that you do not have to choose among multiple gestures to achieve a particular sub-task. The idea is to make the system image as straightforward and simple as possible, to minimize UI consistency errors and wrong user images. Monotony is a tough goal because we try to change the interface while retaining the learned value of the user base. Both can't be achieved in full. That's why the result will have to be a compromise between adding some new concepts and getting rid of some old concepts.

4. Make the interface discoverable and clear while maximizing information efficiency (no more interaction than strictly necessary), and preserving as much screen space as possible for the content.

"Consistency" is inherent to the above goals. It is a logical consequence if those goals are achieved.

The subgoal "getting rid of wizards" also follows from the above goals: They are modal, require lots of interaction, work against learnability by duplicating functionality etc. Their shortcomings are too numerous to list here in full.

One current problem that will be addressed here is a lack of distinction between "item properties" and "commands". Of course there is always some kind of blur between those two categories, but it can be resolved clearly for 95% of the cases. Currently you change some properties by invoking commands. And then there are many properties that you currently can only change through dialogs. We'll get rid of all those dialogs. When removing all property-manipulating commands one finds that real commands aren't invoked as frequently as one might have thought. Manipulation of properties is far more frequent, and can be dealt with more efficiently through direct manipulation and the Properties Sidebar.

Keyboard Command Invocation

Keyboard Command Invocation, as the name implies, takes place with the keyboard. There will be, however, a text entry field that provides a visual cue and may be clicked on. It won't have a "go"-button to avoid training the user to inefficient mouse-keyboard-changes. The user will use the Enter key to invoke the command.

Because this will be the most-used UI element by far, it's very important that everyone will be comfortable with invoking it. That's why we give up monotony for the sake of universal accessibility. The field can be invoked in three ways:

Clicking it with the mouse, typing/selecting a command, and pushing the Enter key.
Pressing and releasing CAPS-LOCK, typing/selecting a command, and pushing the enter key (disabled by default).
Holding down the CAPS-LOCK, typing/selecting a command, and releasing the CAPS-LOCK key.

The third variant is quasimodal. It relieves the user of the burden to check visually whether their input goes into the text field -- they just now it because they FEEL it (holding down the CAPS-LOCK key). If the CAPS-LOCK key is held down while typing, it's a command, if it isn't, it isn't. This gets rid of mode errors and improves accessibility. You can cancel a command invocation by typing gibberish and releasing CAPS-LOCK -- it's quick to perform and no command will be found. You can also hit the Esc key.

While the user is typing into the command field, a list of suggestions is constantly updated below it. The topmost suggestion will be invoked by default, but the user can select another suggestion from the list by using the arrow keys. Typed letters will be matched non-consecutively. That means that when typing "rsl", the command "Run Slide Show" will appear in the suggestions list. The suggestions list will be ordered according to the following factors (with different weights applied to each of the factors):

Matches at beginnings of words appear higher.
Consecutive matches appear higher than non-consecutive matches.
Matches that cover more letters of the command name will appear higher.
Suggestions that have previously been selected after typing the same letters appear higher.

Of course you need not invent abbreviations like "rs". If you're comfortable with typing more of the command name, go ahead and type "run".

Mockup: As an example on how space could be saved, the Command Invocation Field has been integrated into the title bar. It is important to note that click-through should not work with the field (i.e. when the window is inactive and the text field is clicked, it should not take input focus).

About discoverability: It might seem like this approach "hides" all commands from the users, making them hard to discover. And in fact when "hiding" means "not cluttering up the screen with them", it does! ;-) But in fact this kind of interface is easier to explore than a menu-driven one. Static mockups can't convey that due to the instant feedback you are able to find out what command to use very quickly by typing and erasing letters. If you want to get an overview about the capabilities of the application, you can also "list available commands".

Although we now got rid of any visual representation of commands, there is a case where I am in favor of toolbar-like command invocation: Sometimes, there are commands that (a) are frequently executed in a context when the user is working with the mouse intensely, and (b) do not fit into the context menu by being too "general", i.e. unrelated to any of the on-screen objects. I guess the "Insert circle" command fits into this category. For these cases, I advocate allowing for a toolbar, with very carefully selected commands, that can be easily customized by the user if they find that they need a command often when working with the mouse. The used toolbar icons have to be clear and have a lot of contrast, have different shapes, as well as text labels. See the Apple Keynote toolbar for a good solution to the aspects of choice, icon design and user customization.

Rationale

Commands have names. Those will be used to invoke the commands. A similar approach has also been discussed under the name "Command Search". Keyboard Command Invocation maximizes the screen space available for the content, while at the same time avoiding excessive interaction (navigating through menus and sub-menus). Also, typing a letter sequence habituates nicely.

Commands are atomic. They don't take arguments (not yet, at least). Their only "argument", if any, is the current locus of attention, e.g. the current selection, the current slide, etc. All that is said here about commands applies independently of whether they are invoked through the keyboard or through the mouse.

Examples for commands are "insert oval" or "save file". The command "Insert oval" puts an oval with default properties onto the current slide. Those properties can be changed later, e.g. through direct manipulation or through the Scrolling Properties Sidebar. Not having to determine object properties at the point of creation is part of the "de-wizardization" goal of this proposal. De-coupling those steps gets rid of unnecessary double work and increases flexibility and the user's creative possibilities by an order of magnitude.

Direct Manipulation and Mouse Gestures

Impress currently makes decent use of direct manipulation to modify content objects. That's a good thing, because the object on the screen blends with its physical properties. Its physical properties are not abstract, but tangible, right there on the object itself.

This proposal suggests that direct manipulation can be further improved and extended very far. As many physical properties as possible should be modifiable through direct manipulation. The Properties Sidebar (see below) will ideally only need to be used for fine-tuning (also, there won't be any dialogs/wizards for item properties any more). Here's the proposal:

a) Changing single click behavior to always select the object

There should be no exceptions, such as is the case now for text objects. You will double click them to edit, same as with other objects. Then it's not so ludicrously difficult any more to select a text object (clicking once, pausing, and trying to click the border the second time). The thick selection border of text objects will then become unnecessary.

b) Changing "snap to grid" functionality

Currently, when performing some dragging operation (drag, resize, ...) on an object, it locks to an imaginary grid by default. Instead, do it like Apple Keynote: Get rid of this imaginary grid and introduce snapping to positions relative to the other objects instead (if closer than a about 10 pixels). When snapping occurs, display guidelines to indicate what is being snapped to. Snap edges/center of object...

...to slide edges/center
...to edges/center of other on-slide objects
(if text) ...to text edges/center of other text objects

c) Improving consistency of modifier keys

The operation should always react to pressing/releasing modifier keys during the operation. You could e.g. start resizing an object and then press Shift during resizing to preserve aspect ratio. This aids discoverability and reduces the need to stop, undo and start again. The modifier keys should always stay freely combinable, just as they are now. These are the current uses of modifier keys, with slight improvements:

CMD/Ctrl overrides snapping (already implemented in Impress)
Alt modifies action so that is uses the object center as pivot point (partly implemented in Impress -- does not react to pressing Alt during the operation)
Shift forces the action to be more "orderly", e.g. resizing preserves aspect ratio, rotating snaps to 45 and 90 degree positions (only aspect-ratio implemented in Impress)

d) Adding more handles for direct manipulation

When holding down CMD/Ctrl before starting to drag, additional handles, in addition to the corner and edge handles, appear on and around the selected object. The user can drag these to perform their operation. When the user starts to drag, all handles disappear and the mouse cursor assumes the handle's shape. Th dragging operations all react to the modifier keys mentioned above (where it makes sense). The only exception is that no snapping takes place in these operations. Therefore, no snapping-override (CMD/Ctrl) is necessary. The handles have distinct symbols that convey their physical effect through their shape, and they have a tooltip. They are for example: - Handle for rotation (desperately needed) - Handle for 3D tilt (backward/forward) - Handle for moving object backwards/forwards in Z order (up is back and down is front) - Handle to drag a drop shadow (determines angle and distance/blur of drop shadow) - Handle to adjust opacity - Handle to flip the object - Handle to modify a color gradient - ...and so on.

Those are a lot of handles, but they don't clutter up the interface because they only appear on demand (when CMD/Ctrl is held down). By adding those handles, we already made many dialogs and context menu entries redundant. Hooray!

Mockup: As an example on how space could be saved, the Command Invocation Field has been integrated into the title bar. It is important to note that click-through should not work with the field (i.e. when the window is inactive and the text field is clicked, it should not take input focus).

e) Adding a gestural context menu

There will probably still be often-needed properties that are will not fit this "drag a handle" metaphor. Also there are some often-needed context menu entries. That's why we'll still need some sort of context menu. But please take note that we will definitely not keep those context menu entries that simply provide shortcuts to properties dialogs. Those are kept in the Properties Sidebar (see below). We only want context menu entries that perform a particular action -- that is, that are commands.

I suggest making the context menu fit the direct manipulation approach by not using the classical menu paradigm, but a gesture-based menu.

This is a blend between a pie menu and mouse gestures, combining the advantages of both. I lifted this approach from the easyGestures project (http://easygestures.mozdev.org/).

Similar to the Keyboard Command Invocation, invocation of the context menu will not be monotonous for discoverability's sake. There will also be a modal and quasimodal way to use the context menu:

Right-click object, click to select item
Right-click object and hold mouse button, select item by moving mouse to it, release mouse button.

In the preferred second (quasimodal) usage, you cancel by (1) releasing the button again without having moved the mouse more than 10 pixels, (2) moving the mouse far beyond the menu, or (3) hitting Esc.

In a circular menu, you select an item by moving the mouse a certain angle. The distance you move it is not so important. Humans are far more precise in moving the mouse in a particular angle than in moving it a particular distance (you need to be dexterous in the latter for linear menus).

Mockup. Example of using a gestural context menu.

Mockup. It's easy to hit a menu item. Great dexterity is not necessary.

To copy an item, you would:

Right-click object and hold button
Push the mouse a bit to the left and release the right mouse button

The menu appears instantly on mouse-down. There's no timing involved whatsoever. The whole gesture takes less than 0.2 seconds.

The position of the menu items never changes (unavailable ones can be grayed out, however). You will habituate the selections you make after only a few uses, and invoking them will no longer be a conscious action, but one that will be performed by your hand, not by your brain.

A technical note: When the user pushes down the right mouse button, it's important that the system already tracks gestures instantly -- even before the menu has actually been drawn. The reason is that users will soon rely on invoking commands by a quick flick of the wrist and won't look at the menu any more anyway. This is the idea of habituation, which should be supported by all means available. We don't want the user to hesitate (he already has made the choice of what to do before invoking the menu).

Mockup. Example of using a submenu.

Submenus are invoked in a similar fashion. There's no need to release the button or click again while navigating submenus. They open by themselves when you move over them (immediately, no timeout). To select a sub-entry, you just "change the course" towards the subitem (and so on for deeper nested menus).

Here, it slowly becomes obvious why these are called "gestural menus". When you imagine the selection process without the visible menus, you've got classical mouse gestures. Copy is left. Normal Paste is right, down. And so on. The main difference to ordinary mouse gestures is that you always have a visual cue available when you need them. You don't have to remember anything -- it's still a menu.

When trying to merge direct manipulation handles and gestural menus, the next step could be to provide direct manipulation handles whose use can be parametrized by combining them with associated gestural menus.

Mockup

Please add your main “wireframe” mockup. For example: A mockup which shows the functionality for adding a slide in Impress.

Detailed Description

This space is reserved for the detailed description of your design. Add anything you might find important for us to know. If you don't have any clue what this might be, then you will find some topics below.

Describe dynamic behavior: The mockup above is something static. To better illustrate what will happen on the screen, describe what actions would be taken by the user and what would appear on screen.
Explain the rationale and assumptions: If you decided to go for a certain concept, then please explain why you chose this.
Highlight particular design ideas and alternatives: A concept usually incorporates many individual ideas. If you think certain ideas are really unique, then please highlight them. And if you think that there were other really good ideas which could not be implemented at the same time, tell us about them.
List issues and open questions: Please list any issues you are aware of and open questions. Do not worry if your proposal or concept isn't perfect. If you have discovered any stumbling blocks or worries, then please provide this information right from the start. Maybe the team can help find answers/solutions.

Additional Material and Mockups

Please share everything you might think is important to better understand your proposal. Perhaps you also have other ideas which are not directly related to “Accessing Functionality”? You might add further documents, Internet links, or additional mockups - e.g. showing a workflow or different states of the software.

Author or Team Working on This Proposal

Author / Team Member	Contact (OpenOffice.org login name, used for email)
Real Name	OpenOffice.org Login Name
Real Name	OpenOffice.org Login Name

Comments

Community members, this is where your comments and questions concerning completeness and clarity should be written. Please add your OpenOffice.org login name to let us contact you via email.

Your space :-)

@@ Line 154: / Line 154: @@
 |-
 | Mockup. Example of using a gestural context menu.
+|}
+{| class="prettytable"
+| [[Image:ProjectRenaissance DesignProposalCollection Template EmptyProposal.png|640px|thumb]]
+|-
+| Mockup. It's easy to hit a menu item. Great dexterity is not necessary.
 |}

Difference between revisions of "Proposal by Andreas Schuderer"