Proposal by Knoxy

From Apache OpenOffice Wiki
Jump to: navigation, search


Quick Navigation


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 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 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



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 ( login name, used for email)
Joshua Martin josmar52789
Adam W. Knox ak13


Community members, this is where your comments and questions concerning completeness and clarity should be written. Please add your login name to let us contact you via email (add ~~~ to the end of your post).

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

Response from FLUX UI Team

Very interesting notion, thank you for your thoughts. I think you could even go a step beyond this to say that you need to overcome a users notion of not wanting to explore in a program. When you first start using a program you find yourself exploring different icons to determine their functionality, some people explore clicking with ctrl and alt. However, once you become accustomed to a certain layout you expect to find these keywords, or keytasks. This isn't necessarily bad however, since they cover several of learning styles, and many of these key phrases have been fleshed out and are now wholly descriptive, clear, and concise. Achieving the same goal with icons is a much touchier matter, and thus having both words and icons may seem like a hinderance to one and not the other having both will inevitably get you all the way there.

It is an interesting thought to have an option to have the bars condense from text and visuals, strictly to visuals or text. This slightly addresses Richard Neill's concern


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.


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.


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.


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

Response from FLUX UI Team
  • Response to "Slide 4...": I believe you are reffering to slide 5. Perhaps the interactivity is lost in a static image, It is not a click and hold menu. The fact that it expands to offer other options is intuitive. If you need to zoom, and see an icon that says zoom, and click that icon and other options appear, the user will have learned the functionality.
    • Response to "Is it intended...": This layout is only for impress. The functionality of a Gear Shift Zoom Slider for Impress is undergoing iterations, and is currently at the proposal stage in the FLUX UI.
  • We are currently working on the command hierarchy that we recommend be implemented for the FLUX UI. Your patience in this process is appreciated, as it is quite an undertaking.
  • Response to "Slide 10": We determined a few major factors when deciding how views should be implemented.

1) Views ought to remain visually separate from other toolbars or "bars"

2) Tabbed views on the stage in OO.o 3x occupy an entire row on the stage. This eats up far too much vertical space (read other comments already warning us on this).

3) Pairing Views and the Slide View make sense in terms of both work flow / process usage, and category. Being unable to combine the zoom functionality into this pairing is one of the few pitfalls we stumbled into.

4) This does as good a job of relating current view state to the user as past implementations.

5) This position still allows the Slide View Pane to disappear when in a View mode that does not need it.

6) This sets up future versions of Impress and other OOo programs to implement a Gear Shift Zoom Slider for Impress. This slider also tackles your concern of the zoom function and relaying current zoom level. Having this slider occupy the same space as the Views menu will ease the transition to new functionality


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)

Personal tools