Difference between revisions of "Competitor Analysis"
Line 1: | Line 1: | ||
{| style="border: thin dashed #CC2222; padding:5px" | {| style="border: thin dashed #CC2222; padding:5px" | ||
|- | |- | ||
− | | '''Please, don't delete anything on this page. Relevant suggestions are welcome -- | + | | '''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's example, I should put up my proposal also. | + | Well, I guess, following FLUX UI and DaVinci's example, I should put up my proposal also. |
− | = Mockups = | + | == Mockups == |
[[Image:Iced_coffee_-_default.png|300px|thumb|center|Mockup of the default Iced Coffee interface, minus the status bar]] | [[Image:Iced_coffee_-_default.png|300px|thumb|center|Mockup of the default Iced Coffee interface, minus the status bar]] | ||
[[Image:Iced_coffee_-_full.png|300px|thumb|center|Mockup of the alternative menu mode, demonstrating most of the available UI elements]] | [[Image:Iced_coffee_-_full.png|300px|thumb|center|Mockup of the alternative menu mode, demonstrating most of the available UI elements]] | ||
− | [[Image:Iced_coffee_-_small.png|300px|thumb|center|Mockup of | + | [[Image:Iced_coffee_-_small.png|300px|thumb|center|Mockup of OO.o resized to a pretty small size, showing how tabs/menus become icons, how secondary UI elements are automatically hidden, and how the tab browser button takes the place of other open tabs]] |
− | = Command categorization = | + | == 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... | 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... | ||
{| border = "1" cellpadding="0" cellspacing="0" width = "100%" | {| border = "1" cellpadding="0" cellspacing="0" width = "100%" | ||
Line 26: | Line 26: | ||
*Save | *Save | ||
*Save as > (includes exporting and digital signatures) | *Save as > (includes exporting and digital signatures) | ||
− | *Print... ( | + | *Print... (automatically jumps to "Print Preview" in a separate tab; Print options are inline panels, glued to the top of the window; they include printer settings) |
− | |||
*Send > | *Send > | ||
*~ Convert document | *~ Convert document | ||
Line 45: | Line 44: | ||
*** Side-by-side (triggers checkboxes on the window thumbnails in the window gallery so the user can choose the tabs to arrange) | *** Side-by-side (triggers checkboxes on the window thumbnails in the window gallery so the user can choose the tabs to arrange) | ||
*** Grid (also uses checkboxes) | *** Grid (also uses checkboxes) | ||
− | ** | + | ** Close current |
− | ** | + | ** Close others |
− | |||
** /Window/tab gallery/ | ** /Window/tab gallery/ | ||
− | * | + | *Options/Preferences... (includes "Extension manager" and "XML Filter Settings") |
− | *Reload > ( | + | *Reload > ("Reload" and "Update >" combined) |
− | *Exit | + | *~ Exit |
| | | | ||
*Undo | *Undo | ||
Line 115: | Line 113: | ||
** Right | ** Right | ||
** Justify | ** Justify | ||
− | + | ||
** Top | ** Top | ||
** Middle | ** Middle | ||
Line 150: | Line 148: | ||
*Styles > | *Styles > | ||
** Save selected style | ** Save selected style | ||
− | |||
** /Style gallery/ | ** /Style gallery/ | ||
*Font > | *Font > | ||
− | ** /Font | + | ** /Font chooser/ |
*Size > | *Size > | ||
− | ** / | + | ** /Size slider/ |
*Emphasis > | *Emphasis > | ||
** Bold | ** Bold | ||
Line 168: | Line 165: | ||
** Autocorrect | ** Autocorrect | ||
** Thesaurus | ** Thesaurus | ||
− | + | ** /Language chooser/ | |
− | ** /Language | ||
** For selection | ** For selection | ||
** For document | ** For document | ||
Line 198: | Line 194: | ||
|} | |} | ||
− | = UI Elements= | + | == UI Elements== |
− | == Central menus/toolbar == | + | === 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). | 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 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). | :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 == | + | === Sidebar === |
The Sidebar consists of five things -- Inspector, Navigator, Styles, Stockpile, and Notes. | 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 Inspector is a left-hand properties sidebar, much like that in many Apple programs and Lotus Symphony. | ||
Line 210: | Line 206: | ||
:"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. | :"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. | :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 == | + | === 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... | 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 == | + | === 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. | 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 == | + | === Scrollbar === |
− | The scrollbar undergoes small changes. Page numbers are now shown to improve click navigation. | + | 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 work | + | === Tabs === |
− | = Details = | + | 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. |
− | == Help == | + | == 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. | 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 === |
− | 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) | + | 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 == | + | === 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). | 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 == | + | === 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 [[Font_Categories|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. | |
− | == Color scheme == | + | === 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. | 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. | ||
− | = Ideas = | + | == 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. | 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. | ||
[[Category:UX Idea]] | [[Category:UX Idea]] |
Revision as of 22:11, 23 March 2009
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.
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, Search, 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.
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.
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.
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.