Revision as of 21:32, 28 May 2009

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.

Design Proposal "FLUX UI"

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

Summary and Status

FLUX UI, or FLUX User Interface, is a user interface design proposal for OpenOffice.org initially developed by Joshua Martin, Stefan Roeben, and Mikko Lehtisalo. FLUX UI was a winner of the 2008 Sun Microsystems Community Innovation Awards Program. The design is now being developed by Joshua Martin, Adam W. Knox, and Pranavrules. Three design principles guide the design's development:

The document is the most important UI element.
Don't show the user what he/she doesn't need at the moment (context sensitivity).
Don't focus on a single UI element (i.e. Ribbon, Menus, Tabs) - use a hybrid of elements so that the information is displayed in the most appropriate way.

Please know, this design is far from complete. It is our hope that even if this particular design is not implemented, a number of ideas might be collected from our thoughts on user interface design.

Download our Call for Design Proposals Presentation. Also download the original Draw file for FLUX UI Impress Proposal

Mockup

Detailed Description

You can download our official Call for Design Proposals Presentation here.

Utility Bar: Consists of the most common "File Menu" options.

new file, open file, save, save as, print

Document Bar: Consists of the most common “Standard Toolbar” commands. These are commands that must be accessible at all times as their usage is unpredictable. Also, this “toolbar” will function as a drag/drop/remove toolbar to which users can add their own commonly used commands.

Undo, Redo, Spell Check, Cut/Copy/Paste, Zoom, Gallery, Navigator

FLUX Bar: Completely context-sensitive “toolbar” that allows various options depending on the current workspace

Ex. User clicks on rectangle drawing -- Then... Dynamic Options Menu displays the 3D tools, background, styles + formatting, etc.

Ex. User has nothing selected -- Then... Dynamic Options Menu displays Slide Layout options, Master Page options, slide background, etc.

Slide List: List of slides in the current presentation. This is merely an implementation of the current “Slides” pane.

Slide View Options: Drop down list of available slide views. Though we know a tab-based method is far more common, we thought that something “drop down based" was more efficient for this design.

Ex. Normal, Outline, Notes, Handout, Slide Sorter

Tabs (Horizontal): Designed as a replacement for menu-driven approach. One tab for each group of related commands and features. Note: This is NOT a MS Office Ribbon knock-off. This is a traditional tab-based UI element for inserting objects and performing tasks similar to the UI of Dreamweaver MX.

Ex. Tab “Insert” would have buttons: Insert Slide, Insert Image, Insert Chart, Insert Symbol, etc.

Ex. Tab “Publish” would have buttons: Export, Export to PDF, Send Document as E-mail

Author or Team Working on This Proposal

Author / Team Member	Contact (OpenOffice.org login name, used for email)
Joshua Martin	josmar52789
Adam W. Knox	ak13
FLUX UI Team	FLUX UI Wiki

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.

Please bear in mind that not everyone has large screens. In particular, laptops are now all supplied with "widescreens" rather than full-height screens. Vertical space is further reduced by the taskbar, title-bar, and menu-bar. For netbooks, this is even worse. Yet most documents are in portrait mode. So please make it easy to make the icons small, merge multiple toolbars together, and optionally move the toolbars to the left and right sides. --RichardNeill 21:46, 11 May 2009 (UTC)

Many UIs today tend to blend buttons into the toolbar, as seen here. Unfortunately, this can confuse novice users, as they may not realize that an image with a label can be clicked. If something can be clicked, it should _look_ clickable. In the screenshots shown here, all the buttons blend into the toolbar's background color. To improve usability, please add some sort of button-esque finishing to the buttons. I have seen this done poorly in a variety of Windows, Mac, and Linux apps, despite the widespread knowledge of "affordances" in the HCI world. For more information about affordances in UI design, please see: Affordances in E-Learning and ID Encyclopedia: Affordances. Otherwise, this is looking quite slick! Nice work! -- Angela Thomas

I really like the look of the design, but I'm not crazy about the usability. I think there are two things holding it back. First, the 'Document Bar' has a bit of a catch-22. If you don't add any more buttons, then you are wasting a fair amount of screen real estate, but if you start adding buttons down the whole side of the document that may rarely be used, you start ruining the wonderful clean look that you guys have achieved. My second issue is the size of the expanded tabs. There is going to be very few commands that you can fit within that style. Currently, you have 4 tabs, 9 items, and space for about 4 more tabs/items. That would be a maximum of 8x9=72 commands that you ever exist in your Tabs. Obviously, that's not even close to being a UI for the whole program. You can get some more commands through the FLUX bar, which I think is a great idea, but we're talking about 2-3 times as many commands, when we really need 10-20 times as many commands[1]. The easy way to solve this is by having the tabs control a new horizontal bar across the entier screen, but then we run into more real estate issues, do we want the 'command' tab controlled bar and then also the FLUX bar always there? that takes up room that might be better spent on a larger tab controlled bar, and a 'FLUX Tab'. -- Kevin Hill

Response from FLUX UI Team So the number one thing I'm seeing from comments and such is the issue of screen real estate - specifically, FLUX UI might take up too much of it. Also, that people might not realize that the buttons on the horizontal tabs are clickable.

The second issue is very easily fixed. The solution to the first: We shrink the height of the tabs and utility bar, which isn't a big problem. Then, we make the labels below the buttons optional - like the way things are now. Since horizontal screen space isn't too much of a problem nowadays, the challenge of taking up less vertical space has been at the forefront of commenters' thoughts.

Thoughts?

Joshua Martin

Hi. I have a few questions:

You talk about the utility and common bars displaying only the most common commands. If you don't have a menubar or anything similar, where will all those less commonly used commands go?
Is there be a way to optionally view the status bar, or is it gone (sob ;( -- I don't think I could live without one)?
Is there a reason for moving the slide list to the right, or is it just because the document bar is on the left?

Thanks. --Mirek2 21:58, 12 May 2009 (UTC)

Response from FLUX UI Team

This needs a little fleshing out still. We have discussed having "expansion" icons that allow access to these less used features. The original concept called for a "command search box" but this is not a current feature and thus could not be included in the proposal. That said, we have been working on compiling the current command layout and the proposed command layout and have found a comfortable home for nearly all of the commands
Think about when you use the status bar and what you use it for. Layout, and information that ought to be provided to you anyway. There are other ways to have this information built in more directly (visually) so that you don't have to reference a corner of the window. The functionality would be worked in to other parts of the interface.
The slide list is on the right because it makes sense for what we predict the scrollbar will turn into. If you look at the Flux UI page you will see it in the proposal section. In Writer pages would be in a column on the right hand side, working in conjunction with the scrollbar (and if space is deemed necessary, can collapse into just a scrollbar). It makes sense to have this location match in all of the programs.

Knoxy

Hi. I'm just wondering if you are inspired by Buzzword? --Xell 14/5/2009

Hi! I like very muck your design: the tabs are great and the FLUX Bar is essential. Actually, your principles are mainly the same as mine (see: Proposal by Rodrigo Carvalho). An something I liked is that it's really simple to make a web version of it! But I agree the space usage problems. One doubt: how do you feel about modal windows? Best regards and great job! -- Rcsilva83 14 May 2009

Response from FLUX UI Team

The only circumstance I can think of a modal window being referenced from this interface are the following commands:
- Save as
- Print
- Page Setup
- and less frequently used command lookup.

Most all the options should be easily seen, but not forced upon the user. Having seen users try to ignore a modal window after clicking a button, and just try and click the button they want (and not being able to) I am very hesitant to use them. Knoxy

Hi dear Flux UI team members,

that looks really nice :-) Just a few questions from my side to better understand your concept (I'm referring to your “Call for Design Proposals Presentation“):

Slide 4, the zoom menu:
- How does the user know that this is a menu? Is there any visual clue?
- Is it intended to only provide the zoom level here? Placing it in a menu would mean that people don't know what zoom level is currently active – which may be a problem for the other document types.
Slide 8, user clicks on rectangle:
- Where would the rectangle drawing be placed. In the insert menu, or is there an additional toolbar?
- A rectangle in Impress does also provide the ability to contain text which makes the settings pretty complex. Will the contextual toolbar also provide these settings at the same time?
Slide 8, nothing selected: Do I get it right, that “nothing” selected means the slide itself is selected? Because the contextual toolbar will show settings related to the current slide.
Slide 8, picture, Modify Slide: If the user clicks on “Modify Slide”, what will happen? Will usual dialogs be used, too?
Slide 10, drop down list for slide views: You say that the drop-down list may be more efficient, can you please provide some assumptions?

Thank you guys for your effort and sharing your ideas! :-) --ChristophNoack

Hi Flux UI team. Firstly, I would like to say that I like many of your design concepts. However, I have a few concerns with your UI design. I am currently not understanding where the vast OOo command content is accessible within your design. I don't see any "Modify" commands, and while I can intuit where you might place "tools" I am curious where you envision the tool commands going. Additionally, how do you propose window navigation be handled? Perhaps through the utility bar? Thanks, Jaron --JaronBaron 00:56, 25 May 2009 (UTC)

@@ Line 97: / Line 97: @@
 Many UIs today tend to blend buttons into the toolbar, as seen here. Unfortunately, this can confuse novice users, as they may not realize that an image with a label can be clicked. If something can be clicked, it should _look_ clickable. In the screenshots shown here, all the buttons blend into the toolbar's background color. To improve usability, please add some sort of button-esque finishing to the buttons. I have seen this done poorly in a variety of Windows, Mac, and Linux apps, despite the widespread knowledge of "affordances" in the HCI world. For more information about affordances in UI design, please see: [http://elearning.kern-comm.com/?p=7 Affordances in E-Learning] and [http://www.interaction-design.org/encyclopedia/affordances.html ID Encyclopedia: Affordances]. Otherwise, this is looking quite slick! Nice work! --[[User:amthomas| Angela Thomas]]
 I really like the look of the design, but I'm not crazy about the usability. I think there are two things holding it back. First, the 'Document Bar' has a bit of a catch-22. If you don't add any more buttons, then you are wasting a fair amount of screen real estate, but if you start adding buttons down the whole side of the document that may rarely be used, you start ruining the wonderful clean look that you guys have achieved. My second issue is the size of the expanded tabs. There is going to be very few commands that you can fit within that style. Currently, you have 4 tabs, 9 items, and space for about 4 more tabs/items. That would be a maximum of 8x9=72 commands that you ever exist in your Tabs. Obviously, that's not even close to being a UI for the whole program. You can get some more commands through the FLUX bar, which I think is a great idea, but we're talking about 2-3 times as many commands, when we really need 10-20 times as many commands[http://wiki.services.openoffice.org/wiki/Framework/Article/OpenOffice.org_2.x_Commands]. The easy way to solve this is by having the tabs control a new horizontal bar across the entier screen, but then we run into more real estate issues, do we want the 'command' tab controlled bar and then also the FLUX bar always there? that takes up room that might be better spent on a larger tab controlled bar, and a 'FLUX Tab'. --[[User:khill| Kevin Hill]]
@@ Line 117: / Line 118: @@
 * Is there a reason for moving the slide list to the right, or is it just because the document bar is on the left?
 Thanks. --[[User:Mirek2|Mirek2]] 21:58, 12 May 2009 (UTC)
+{| style="border: thin dashed Gray; padding:5px; background: LightGray"
+|-
+| '''Response from FLUX UI Team'''
+* This needs a little fleshing out still. We have discussed having "expansion" icons that allow access to these less used features. The original concept called for a "command search box" but this is not a current feature and thus could not be included in the proposal. That said, we have been working on compiling the current command layout and the proposed command layout and have found a comfortable home for nearly all of the commands
+* Think about when you use the status bar and what you use it for. Layout, and information that ought to be provided to you anyway. There are other ways to have this information built in more directly (visually) so that you don't have to reference a corner of the window. The functionality would be worked in to other parts of the interface.
+*The slide list is on the right because it makes sense for what we predict the scrollbar will turn into. If you look at the Flux UI page you will see it in the proposal section. In Writer pages would be in a column on the right hand side, working in conjunction with the scrollbar (and if space is deemed necessary, can collapse into just a scrollbar). It makes sense to have this location match in all of the programs.
+Knoxy
+|}
 Hi. I'm just wondering if you are inspired by [http://www.acrobat.com Buzzword]? --[[User:Xell|Xell]] 14/5/2009
-{| style="border: thin dashed DarkGreen; padding:5px"
-|-
-| Hi! I like very muck your design: the tabs are great and the FLUX Bar is essential. Actually, your principles are mainly the same as mine (see: [[Proposal by Rodrigo Carvalho]]). An something I liked is that it's really simple to make a web version of it! But I agree the space usage problems.
-One doubt: how do you feel about modal windows?
+Hi! I like very muck your design: the tabs are great and the FLUX Bar is essential. Actually, your principles are mainly the same as mine (see: [[Proposal by Rodrigo Carvalho]]). An something I liked is that it's really simple to make a web version of it! But I agree the space usage problems.
+One doubt: how do you feel about modal windows?
 Best regards and great job!
 -- [[User:Rcsilva83|Rcsilva83]] 14 May 2009
+{| style="border: thin dashed Gray; padding:5px; background: LightGray"
+|-
+| '''Response from FLUX UI Team'''
+* The only circumstance I can think of a modal window being referenced from this interface are the following commands:
+** Save as
+** Print
+** Page Setup
+** and less frequently used command lookup.
+Most all the options should be easily seen, but not forced upon the user. Having seen users try to ignore a modal window after clicking a button, and just try and click the button they want (and not being able to) I am very hesitant to use them.
+Knoxy
 |}
@@ Line 142: / Line 163: @@
 * Slide 8, picture, Modify Slide: If the user clicks on “Modify Slide”, what will happen? Will usual dialogs be used, too?
 * Slide 10, drop down list for slide views: You say that the drop-down list may be more efficient, can you please provide some assumptions?
 Thank you guys for your effort and sharing your ideas! :-) --[[User:ChristophNoack|ChristophNoack]]
-{| style="border: thin dashed DarkGreen; padding:5px; background: White"
+Hi Flux UI team.
-|-
-| Hi Flux UI team.
 Firstly, I would like to say that I like many of your design concepts.  However, I have a few concerns with your UI design.  I am currently not understanding where the vast OOo command content is accessible within your design.  I don't see any "Modify" commands, and while I can intuit where you might place "tools" I am curious where you envision the tool commands going.  Additionally, how do you propose window navigation be handled?  Perhaps through the utility bar?
 Thanks, Jaron  --[[User:JaronBaron|JaronBaron]] 00:56, 25 May 2009 (UTC)
-|}

Difference between revisions of "Proposal by Knoxy"

Revision as of 21:32, 28 May 2009

Design Proposal "FLUX UI"

Contents

Summary and Status

Mockup

Detailed Description

Author or Team Working on This Proposal

Comments

Views

Personal tools

Navigation

Search

Tools