Difference between revisions of "Competitor Analysis"

Revision as of 03:55, 27 March 2009

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.

Mockups

Mockup of the default Iced Coffee interface, minus the status bar

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, Search, Developer (~), and contextual categories other than Text both for readability and because I have not completed their categorization yet...

UI Elements

Central menus/toolbar

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.

Details

Help

Help now takes up a separate tab. It is a completely revised version of help, intended to be friendlier, simpler, and encourage exploration of new features. I'll expand on this later.

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.

Toolbar/menu customization

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.

The Other Apps

Calc

So Apple released this very innovative spreadsheet program called Numbers in iWork '08 (the newest version is '09). It is radically different from Microsoft's Excel and, of course, OO.o's current Calc, in what I would say very positive ways. I like its canvas, I like its flexibility, I like it indicating the colors of different columns as represented on graphs, etc. I don't think OO.o should copy its features (and I don't even know if they might be patented or something), but I really think we should take example in them and consider a similar implementation. However, I don't really use Calc very much, so I really shouldn't be the one to suggest how it should work.

Draw

So far, I don't think Draw has much potential. It's not even a true drawing program, just a mediocre shape and diagram program. To be honest, I very much prefer Inkscape. My most favorite vector programs, though, are Macromedia Fireworks (I say Macromedia, because I don't like some of the changes Adobe brought) and CreatureHouse Expression 3 (which, after being acquired by Microsoft, has been robbed of soul in what is called Microsoft Expression Design). Fireworks I like because it has a fast UI -- all the properties are in one place on the bottom, bitmap and vector editing blends together seamlessly, you see exactly what you're going to get after export (no white canvas showing), and, overall, it's just comfortable. Expression I liked because it was very new, innovative, and pretty comfortable at that (although having rulers as scroll bars bothered me, because they were on the wrong sides). (By the way, if anyone has the old Windows test version of LivingCels, I'd really like to try it out. I know there's a Mac version, but it only works with Tiger; I have Mac OS X Leopard. I heard LivingCels had some interesting workflow aspects as well.) I miss its B-Spline tool (an alternative to the Bezier/pen tool), its brushes, even its color picker. So that we could learn from. But I'm just not sure what direction Draw is taking. If it wants to be just a diagramming program, then we can greatly simplify it. If it wants to be a true vector program, then we need to radically change it, and simplify it also. It needs to put much more emphasis on the tools, like Inkscape does.

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)