Competitor Analysis
| Please, don't delete anything on this page. Relevant suggestions are welcome -- you can add those under "Ideas." Feedback (under "Discussion" or through the mailing list) is greatly appreciated. |
Well, I guess, following FLUX UI and DaVinci's example, I should put up my proposal also. I think the main problem with OO.o today is that the menus are overstuffed and illogically/unclearly organized (almost everything can be sorted into "Edit," "Tools," or "Format"). So the main thing to do is just to organize all commands in all the OO.o applications, and that would actually suffice as a revival of OO.o. This proposal bases on that, but, of course, there are probably much better ways to organize the commands. So I think that's what we should work on, and if you have any ideas, please let them be known.
Contents
Tenets
For those who would like to expand on this proposal as well as just to state the direction I think OO.o should take, here is a list of tenets:
- All commands need to be accessible from one single place (or parts of things triggered in the toolbar; this would happen rarely, but would include things like slide management [changing the order of slides, labeling slides] in Impress and layer management in Draw, for which a sidebar would be utilized) so that the user can easily find the desired command or at least be confident that the command doesn't exist. Let's avoid anything like the MS Ribbon solution, where unsorted, miscellaneous features, like Undo, are either in some random place (Quick Access Toolbar) or just aren't there by default.
- Encourage efficiency. Avoid dialogs and long lists of commands and clearly match the feature names to their functions (right now, "Section," "Fields," and other items have unclear names).
- Be creative and logical. Try to identify the unobvious problems and brainstorm interesting new ways to fix them.
- Try to keep everyone satisfied without harming the interface. Keep the UI [addition] customizable (I even suggest predefined menu/toolbar organization "styles," which could provide command organization similar to that of iWork and MS Office for the switchers) and flexible (providing the same features in similar ways across different resolutions, operating systems, and languages).
- NEVER differentiate between stuff for the basic user and the advanced user. If it can be put in simpler terms, put it in simpler terms. If it's too complicated or just has a very specific audience, make it into an extension. Remember that we're trying to make OO.o easy to use, and if that's impossible with a feature (which it truly shouldn't be), just don't put it in.
- NEVER just add a random feature if there's no real need for it. Perhaps you might have seen a cool way of doing things in another application, or feel like anything that can be customizable should be, but you should really consider if it's a good idea to bring it to the suite. That's what extensions are for.
- NEVER have the interface distract the user. Let's not repeat Office's Clippy disaster.
Mockups
Command categorization
So, this is how I imagine commands would be organized in Writer (identical commands would be arranged in the same places in other OO.o applications). The items that have ~ next to them I imagine should be either hidden by default and triggered through Options or made into extensions, since either their audience is very specific, or they don't seem necessary. I left out Help, Developer (~), and contextual categories other than Text both for readability and because I have not completed their categorization yet...
| File | Edit | Create | Insert |
|---|---|---|---|
|
|
|
|
| Pages | Paragraph | View | Text |
|
|
|
|
UI Elements
Iced Coffee has one central UI element, either a menubar or a toolbar, depending on the user's choice (they share categories and commands, so additions and improvements by developers are always reflected identically in both, and the user's own toolbars/menus are translated into both). Like FLUX UI, Iced Coffee tries to avoid dialogs, so "Options..." and "Help...," for example, are shown in a new tab, "Find and Replace," "Chart Data Table," and "Check Spelling and Grammar" are inline, pockets are utilized, and drop-down menus are used frequently. Both menus and toolbars are collapsible, so when the window is significantly downsized, the menu/tab labels turn into icons. To get users familiar with the icons, they are shown at mouse-over and selection next to the label (see the mockups). In the case of toolbars, like in MS Office 2007 (sorry), the icons' resolution is also adjusted with the window size. Also, when any command is moused over, an instant tooltip gives its description. (I'm still on the fence about this feature, as I worry about it being too annoying; the plus side of it is that, by giving the users a description about features they haven't heard of, the likelihood that a user will actually try such a feature is greatly increased.) When tabs or menus are customized to hide certain commands, an unobtrusive "Show all commands" button automatically appears (this is still debatable).
- The toolbar, unless it somehow violated Microsoft's pending bogus Ribbon patent, is the default choice. Windows applications are shedding the menubar, and its users are getting used to the (arguably faster) workflow. It also makes more sense in Mac OS X (which requires the menubar), as it would be awkward to initially show only the menubar and the document (jeez, not even Apple's basic TextEdit application does that). (If the Mac user wanted to, he could hide the toolbars; this would be Mac-only, since Macs require the menubar, and therefore hiding this central UI element is impossible.) The toolbar, when big enough, uses a unique "halfie" view, in which static tabs are shown on the left and contextual are shown on the right, one from each category simultaneously (again, I think the mockups make this clearer). This is there because many switch between both very frequently.
- The alternative menubar (Windows-only, I guess, since, under Mac OS, there would then have to be 2 menubars) is unusual in that, like the toolbar and its drop-down menus, it uses things such as galleries, color wheels, etc. Contextual menus are listed at the right. Under Windows and Linux, the menubar is as fat as a toolbar to make mouse navigation easier (not needed under Mac OS X, in which menu bars follow the Fitts Law).
Sidebar
The Sidebar consists of five things -- Inspector, Navigator, Styles, Stockpile, and Notes.
- The Inspector is a left-hand properties sidebar, much like that in many Apple programs and Lotus Symphony.
- The Navigator here is pretty different from its current implementation in OpenOffice.org. It provides a way to easily navigate, search, or browse through various document elements (pages, images, tables, etc.) as well as organize page groups and arrange objects (dragging objects up or down in the sidebar has the same effect as "Arrange > Back One" and "Arrange > Forward one").
- Styles is more like its cousin in OO.o today, but previews styles, like other suites do. If the font of the style is too big or too small, the font size is shown in a small rectangle over the preview. This behavior is identical to that of the styles gallery in the mockup.
- "Stockpile" is an improvement suggested by Leonard Mada, I think (someone please confirm this). It would basically be a place to drag files one might use in a document (think the "Clips Pane" in iMovie '06). The user can save these "stockpiles," creating somewhat like the old gallery.
- The Notes sidebar is pretty self-explanatory, but I should mention that since comments on changes in the document now use notes, the sidebar includes these comments, along with "Accept" and "Reject" buttons.
Rulers
This being a controversial subject, I really don't want to give up on rulers. Rulers could be really useful, if the user knew automatically how to use them. For that purpose, tabs, along with columns and "rows" (previously "sections"), are now added with a "+" button, so as to indicate to the user that he or she is adding something. The automatic tooltips that appear on hovering over most buttons explain tabs to novice users. The rulers are moved to around the pages, as to indicate their relationship to the page, make it easier to see where things are, and draw attention to itself. The old placement of the rulers, for the few who have gotten used to the old way, is triggered under "Options." The rulers also indicate the coordinates of an object as the user moves it (in rectangles over the ruler), and guides are shown by default to indicate alignment with other objects or the document (like in Apple's Pages). Anyway, the "Hide Rulers" button is under "View," where you expect it to be. Let's not clutter up the scroll bar with buttons like "Hide Rulers," like Microsoft is doing...
Status bar
Although I guess there is a general consensus that OO.o should hide the status bar, I still want it there for four simple features. Being bilingual, I use the status bar all the time to switch between languages. In fact, all the multilingual people I know use this. I don't know a single Office 2007 or OO.o user that doesn't use the zoom slider. With the birth of the sidebar, the status bar picks up sidebar buttons, which both raise awareness of the sidebar and provide very quick access to its features. Lastly, quick statistics (Word count, page count, etc.), here a tooltip triggered by a mouse-over on the page indicator (next to the language indicator), tend to come in handy, at least for me. The bar can, of course, be hidden under "View" and customized with the features it used to hold.
Scrollbar
The scrollbar undergoes small changes. Page numbers are now shown over it to improve click navigation. Since the navigation arrows, like rulers, have been neglected by most so far, I suggest a refresh. One idea, probably not too effective in bringing new attention, is to just get rid of the "dot," but keep the double arrows, showing the navigate-by buttons (cut down to "Page," "Page group" [what is called a "Section" by both MS Office and Apple Pages]), "Row" [the current OO.o meaning of "Section"], "Bookmark," "Search item," and "Object >") on hover over the double arrows. Another is to get rid of even the double arrows and put the function elsewhere, perhaps in the way Apple Pages does it (in the status bar, next to the location indicator).
Pockets
A while ago, there was a debate on what we should call "Direct Manipulation Snippets," and someone suggested the name "Pockets." It's translatable, to the point, and, although some want the name to be precise and thorough, I think we should settle on a simple, one-word name for the UI element (like most UI elements have). Enough of trivialities, I really like the way JaronBaron suggested Pockets should work, with access at the bottom, and tabs at the side. Also, optionally, Pockets can serve instead of the current annoying pop-up toolbars. In this case, a user selects a phrase or an item - anything really - and a gray (to show neutrality and lack of significance) down arrow suggesting a pocket shows under the highlight. In this way, OO.o can also utilize pockets for thesaurus, as Jaron Kuppers suggested.
Tabs
Tabs work similarly those in Google Chrome, except there is a new "All tabs" button. This button brings up a page of all tabs along with fitting actions, such as "Save all," "Arrange >," and "Compare". Since there is debate on whether the tabs would bother the traditional users, they could be more subtle, such as those in the new version of Safari.
Galleries
For styles, templates, effects, and things of such nature, we should use galleries, previewing in large thumbnails and live on mouseover the result of the action. (This, by the way, is really not intended just to copy Microsoft. I liked galleries even before Microsoft introduced them to Office.)
Details
Command search
So, we've been thinking about integrating command search into OO.o for quite a while now. I love the idea, yet I more and more want to do it like it's done in OS X -- put it under Help. Why?
- It makes sense under Help. That's where the user SHOULD go if he's looking for a command. However, the problem is that, from what I've seen, a lot of users now just dismiss the Help menu and turn to online resources, or even give up with the task prematurely. So, we need to make users trust in our Help system again. I'll expand on this idea below.
- That's where the Mac OS users will look. I don't want to be inconsistent across platforms -- that would make the UI SO much more confusing for switchers or dual platform users (that's me).
Help
As I was saying, we need to revamp Help. A LOT. We need to add images and videos and tutorials and descriptions of what things do. We need to reword some Help items so that they are comprehensible even to foreigners studying English (i.e. those with a very limited vocabulary). And we need to make the Help system robust and friendly, so that it truly feels like a part of OO.o and doesn't intimidate or frustrate the user. Search should be vastly improved, along the lines proposed in the [User Experience/Command search command search proposal]. "What's this?" should now work for EVERY command in the interface, and there should be an infobar with a nice big button to end the help mode (instead of having it turn off automatically at a random time). So what do I suggest to do to Help?
- Let's have Help in a separate tab (if we decide to go with tab navigation), or otherwise the OS's native help browser. This would make the user feel more comfortable with the feature. The Help home screen should be simple: A search box, a few large buttons (similarly to System Preferences/Control Panel in Mac OS and Windows, although fewer and larger), and a link to online resources.
- Let's sort the help items into categories. These could include "Basics," "Command descriptions," "Tutorials," "New features," "Interesting features" (old, yet very useful features that users might have missed), and perhaps "All topics."
- Tutorials especially should utilize videos, simple, step-by-step directions, loads of screenshots, and hopefully even a "Do this for me" button, which would walk the user through the task.
- Let's tout the Help improvements (once we're sure it's really good) with the release of the Renaissance OO.o (or even earlier; this could be implemented independently), since it seems a lot of people now simply disregard Help.
Options
Options are, like Help, a separate tab. I imagine navigation to be done through either a grid of icons linking to different option categories (like "System Preferences" in Mac OS X, or the home screen on the iPhone), which would be similar to the proposed "Help" tab.
Home screen
So, when you start OpenOffice.org or open up a new tab or window, you get this home screen, somewhat like the current StartCenter, but incorporating templates (through tabs), recent documents, document recovery, a light (unbloated), unobtrusive design (see the brainstorm on Mozilla Firefox's "New tab" page), and a tabbed interface. I tried to do a mockup of this (it's up at the top); when one clicks on one of the "new" icons, a gallery of templates and wizards shows up.
The user can create his or her own tabs(/menus), both static and contextual. Creating contextual tabs gives the user a choice of the launching action(s).
Font management
Apple already has a font management application built into Mac OS. I suggest we let the user manage his or her fonts with categories in exactly the same way, through Options, but also have default categories, such as the proposed "Serif," "Sans-Serif," "Proportional," "Monospace," "Symbol," and perhaps even "Fun" (fonts like Comic Sans), and "Professional" (Times New Roman). On Mac OS X, we should integrate with the bundled Font Book categories, and make this categorization two-way, meaning that edits in OO.o affect Font Book and vice versa.
Page groups, sections, and rows
I know this is a new feature and, technically, it shouldn't be in this proposal, but OO.o really needs page groups. These page groups are called sections in both MS Office and Apple's iWork suites, so, obviously, if we want compatibility, we need to bring them in. But otherwise, a lack of page groups is still a great impediment for the average user; he or she is limited to one page orientation per document, to one page numbering system per document, etc. (If OO.o already has a similar system and I just didn't notice it, please edit this.) Now, since "Section" means something different in the more widely-used office suites than in OO.o, I propose a name change for the current OO.o meaning to "Rows," more accurate and fitting with the name "Columns," used for the vertical equivalent, to avoid switcher confusion.
Color scheme
This proposal lacks a color scheme (ignore the one in the mockups). I like the FLUX UI scheme quite a bit, so that could be utilized where the OS design guidelines allow.
Color picker
I can't wait for OO.o to get a true color picker. I hate having to painstakingly define colors through "Options."
The Other Apps
I'm just going to list the ideas I have:
Impress
- Let's have the slide pane more like a movie editing program's timeline or the timeline in flash. Let's indicate the timing, animation, and transitions in the sidebar.
- I find it weird that only Writer has the navigator arrow buttons built into the scroll bar. They should be under all the applications in OO.o
Calc
- We should put the sheet tabs right below the toolbar/menubar, to show that the sheets are ONE document comprised of SEVERAL tabs, just like the tabs in Impress.
- We should implement inline functions (the dialog is just annoying and unnecessary).
- We should take example in Apple's revolutionary Numbers and make Calc easier to use.
Draw
- Let's find a direction for Draw, because, so far, it doesn't have one. Currently, it just seems like a rendition of Writer, only with the gray workspace and page-wide text field removed. Here's what I'd like it to become:
- I'd really love a free alternative to Fireworks, intuitively combining bitmap and vector tools, suiting a wide range of users, from web developers to drawers to photographers. I use Fireworks (MX; I'm not upgrading) so much -- in fact, all the mockups you see above were made in Fireworks.
- If not that, then perhaps an alternative to Inkscape, a vector editor, although I don't see why have two similar free open-source projects.
- Perhaps Draw could gain animation features and become somewhat of a continuation of CreatureHouse's vanished LivingCels (I've never tried it, but I loved their Expression application and heard that LivingCels was REAAALY good) or a primitive rival to Adobe Flash.
But since Draw doesn't have a direction yet, it needs to find one before we can propose something of value.
Ideas
You're welcome to add derivatives and improvements on this proposal to this section. Also, make sure you check out the DaVinci and FLUX UI proposals, both excellent.
- I think the it is time for an overhaul of the scroll bar. Adding page numbers is a step in the right direction, but lacks aesthetics. The idea I proposed on the FLUX page is similar to your navigation on the left side. I think you should just replace the scroll bar with it. If we could make it smarter it would really be useful; perhaps a navigator that slides out from the right hand side (where everyone is used to having a scroll bar), and have a faded (or transparent) scroll bar as a place holder that gives the user feedback on where they are in the document. - Ak13 16:01, 24 March 2009 (UTC)
- Thanks for the comments. I know there have been a lot of innovative, new ideas on the scroll bar, but I just don't see the use of the screens. If shown all the time, they take up space, so they should be at least optional or more functional -- here I really prefer the thumbnail sidebar under both iWork and MS Office, which can hold a lot of additional features (without clutter) -- things such as page group management, all previous navigator features, page labels, etc. They thumbed scroll bar is not even very useful unless the user has something stand out on every page. If you have a long, text-only document, chances are you're not going to find the right page even with thumbnails. If shown only when dragging the scroll bar, the screens duplicate the better, default, full page browsing. --Mirek2 06:59, 26 March 2009 (UTC)
- I think your zoom slider should be updated to Clement's version. It really is a great design, though you may want to pretty it up ,) Zoom Slider - Ak13 16:01, 24 March 2009 (UTC)
- I don't know. I've had a bad experience with a similar interface (I don't remember where, though). I hate trying to drag in a straight line. When I drag, I tend to go waaay outside the dragged object. But I don't know. Perhaps if the "quick buttons" were only on the bottom, it wouldn't bother me. Or how about making these things really just big buttons, independent of the precise drag interface. But overall, I don't think that the current way to zoom is a problem -- I'm pretty satisfied with the way things are... (By the way, I did make a small change to the slider in the proposal -- the zoom indicator is now a text box, so the user can manually write the zoom level without having to open another window.) --Mirek2 06:59, 26 March 2009 (UTC)
