Proposal by Rodrigo Carvalho
|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 firstname.lastname@example.org mailing list.|
Design Proposal "Simple UI"
- 1 Design Proposal "Simple UI"
- 1.1 Summary and Status
- 1.2 Mockup
- 1.3 Detailed Description
- 1.4 Additional Material and Mockups
- 1.5 Author or Team Working on This Proposal
- 1.6 Comments
Summary and Status
The purpose of this proposal is to create a non-intrusive contextual interface with a steep learning curve.
The focus is on:
- dynamic components that morph by context;
- non-intrusive notifications;
- take simple decisions to user;
- familiar UI;
The goals are to:
- ease of learning
- reduce amount of clicks to perform activities
- reduce time to find features
The design directives are:
- minimize clutter and maximize consistency (similar elements are grouped and positioned in similar ways)
- minimize redundancy and maximize relevancy (required information is revealed on demand)
- minimize recall and maximize recognition (visual decision aids are provided when they are beneficial)
The constraints are:
- do not interrupt user by showing modal windows
- always apply default behavior for actions
- always show only relevant tools for each activity (e.g. never show table editing buttons when writing text)
Status: Request for Comments
Buttons included in "Static Toolbar" are:
- Export to PDF
- Copy style
- Slide show
The "Contextual Toolbar" contains buttons for the current action. E.g.:
- While entering text, is has: font, font size, bold, italic, underline, etc;
- While editing a drawing, it has: line, square, circle, etc;
PS.: If the space in the toolbar isn't enough to fit all the buttons, a small button is placed to give access to other options. The most used buttons are placed by default (like MS Office does).
The "Menu Bar" is still there for non-contextual actions, like insert new elements, but with less options, to ease option's search. The reasons to maintain a "Menu Bar" are:
- Users are used to it;
- Will ease consistency across operating systems (MacOS X);
The "Search Bar" is used to give instant access to functionalities and help topics. This instant access is made by a drop down menu updated during typing (like "Google Suggest").
Default Action Alert
The "Default Action Alert" will show up notifying that a default behavior has been made. A button is placed to give options to user. After some seconds without user interaction, it'll disappear.
In the left side, a panel can have 2 different behaviors according to the context:
- Slides panel
- Properties panel
The "Slides Panel" is shown when no presentation items are selected, i.e., user clicks outside the slide.
The "Properties Panel" is shown when a presentation item is selected. It contains extended properties of the item, as the today's "Edit Style" window.
- Dynamic behavior: The dynamic components always change its looks based on what the user is doing and on what tools are mostly used, in case of space optimizations. In addition, today's Impress UI has a kind of "Contextual Bar" in the second line of the toolbar panel. But I think this "horizontal approach" doesn't provide a good separation between static and dynamic components, so I provide a kind of "vertical approach".
- Rationale and assumptions: The main assumption is that a UI have work to make functionalities available to user on the most direct, fast and easy to find away. Secondly, I assume that a UI can't be intrusive by stopping users "mental workflow"; it has to take simple decisions and provide a simple way to change the taken behavior. Lastly, a UI have to learn what are the most important tools for a user and prioritize them.
- Particular design ideas and alternatives: The "Contextual Toolbar" gives emphasis on the contextual behavior. The Menu is use just for "non-contextual" activities, what helps it to be "cleaner" then today's version. The "Search Bar" is a way of fast access functionalities or help topics. The "Slides/Properties Panel" provides a bigger space for editing properties. And the "Default Action Alert" provides a non-intrusive way of notification.
- Issues and open questions: One open question is "this kind of UI can fit all Impress's functionalities?". Only the community can say it :)
Additional Material and Mockups
Author or Team Working on This Proposal
|Author / Team Member||Contact (OpenOffice.org login name)|
|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.|
| No address here to the problem of MS Office 2007 user sees feature it disappears how is user going to get there way back to it. This problem has to be addressed it the bug bar of contextual toolbars.
--Oiaohm 23:41, 13 May 2009 (UTC)
| Hi Rodrigo,
I like that you kept the menu bar, but I'm not quite sure what you mean by "less options" in the menu bar. Do you mean that these would be hidden by default (like Office 2003) or merged together or triggered only by customization or put into extensions or ...? Otherwise, the toolbar seems a lot like that in FLUX UI. I don't quite agree with the buttons placed into it (I don't think a user needs to see "Export to PDF" all the time), but I guess those would be debatable. I'm also not quite sure what you mean by the "Default action alert." Wouldn't that go off with practically every action? As for the toolbar name, I liked the proposal better without it. I think you're underestimating the user -- if the toolbar changes every time you select a different object type, and it holds features related to the selected object, it should be apparent that it shows functions related to that object. I wonder, though, what this will hold when there's no object selected. Impress is going to be one of those where that happens a lot. Is the bar going to be empty until the user selects something? And how does the whole bar scale as the window is resized?
As for the UI prioritizing frequently used commands, I think I would be against this -- I think UIs that change over time are too confusing, as the user has to relearn command placement with every use. Anyway, I like your proposal, and am looking forward to a response. Thanks. --Mirek2 17:40, 26 May 2009 (UTC)