There’s a new way to insert pages (or “add page breaks”) in Writer: right at the bottom of a document.
Much like most of today’s design software (e.g. Inkscape, Pinta, various apps in the Calligra Suite), Citrus has a toolbox, a bar on the left used for inserting stuff quickly. It combines commands from the old LibO Drawing and Insertion toolbars and contains both static and contextual (like “Insert symbol”, which only appears in a text field) commands. It does not house commands like “edit nodes” or “rotate” — that’s left up to the command bar/fizz of each object.
The toolbox takes advantage of Fitts’s law, so the clickable area extends to the left edge of the screen. Also, the toolbox can be quickly shown and hidden with a button placed at the bottom left corner of the window.
I’ve been thinking about how to improve the UI of navigator, and I ended up restructuring the whole thing. Here’s my proposal:
First of all, there would be no “content view” button anymore and categories would be handled by a more common drop-down menu. Thus, different categories could use specific views (graphics and tables could use thumbnails, comments could be color-coded by author, etc.) and show only relevant toolbar buttons (promote/demote and “headings shown” only under “headings”, “go to page” only under “pages”, etc.). There could also be an “All” category, which would show everything in a text-only tree view, just like now. This “All” category could also host the “Show content view” icon, for users who don’t want to use the menu drop-down.
Second of all, the “navigation” arrows would be merged with the ones in the scrollbar, and instead of the “navigate by” pop-up, the arrows would navigate by whatever category is selected in the navigator.
Third of all, a “Pages” category (“Slides” under Impress) would be added. It would work like a cross between the current slides pane in Impress and the navigator: you could use it to navigate the document, but also to drag pages onto the document to create a link to a page. The “Go to page” widget would appear on the category’s toolbar.
The “drag mode” button would reside in each toolbar’s ellipses menu (or, if there’s enough room for it, it could be shown directly on the toolbar). I’m not sure what to do with “Set Reminder”, “Header”, “Footer”, and “Anchor <-> Text”. They could appear in a second Navigator toolbar, one that’s not specific to a category (if this toolbar was there, it could also house “Drag mode” and “Search”). One or two of them could appear in the scroll bar, along with the navigation buttons (although we don’t want to overload the scroll bar). Or, if they’re not used that extensively, they could be bundled as an extension (think “Navigator+”) or appear in the ellipses menu.
What do you think?
While I’ve talked about the context bar, I failed to mention one important aspect of it: Indicators.
These are common contextual (i.e. appearing/disappearing based on the state of things) commands that are not related to the current selection, like “Save”, “Undo”, and “Paste”, and they sit at the right of the bar. Indicators take some load off the status bar, which, in today’s LibO, uses a “saved status” section that acts as a “Save” button on double-click (very non-standard behavior).
And that brings me to the status bar: it’s been drastically reduced in Citrus, consisting of only a zoom slider, a button for showing the toolbox that doubles as an “insertion mode” indicator, and textual indicators of the current state. If you hover over or click on the “Statistics” indicator, you get some more statistics:
Page style indication is left to the page fizz/context bar (which one gets by selecting a page), language indication is left to the text/paragraph context bars/fizz.
Today, LibreOffice organizes commands in a number of ways. Menus, toolbars, sidebars, and dialogs (including the “Customize…” dialog) all sort commands into different categories, which can make it quite difficult to find certain commands under different scenarios. What’s worse, there’s no central place that houses all the currently available commands, so the user might have to browse all the various available UI contraptions to find the command he is looking for.
Last time, I showed you how menus are organized. Well, it turns out that this organization applies not only to menus, but to other parts of Citrus as well, including the context bar (the main toolbar) and fizz. Menus are the central UI for finding commands here: if a command is available, it’s somewhere in the menu hierarchy. Text fizz contains a subset of the commands from the text context bar, which contains a subset of the commands from the Text menu.
So it basically boils down to this: fizz is for really fast access to a select few commands (it’s closest to the pointer, appearing centered above the selection), the context bar holds more commands and is still relatively easy to access, and the menu structure replaces dialog windows for access to more tedious options. Clicking the “ellipses” icon on either the context bar or on fizz shows a menu containing the commands not shown on the bar/fizz, like so:
One can customize fizz or the context bar by dragging an item to or from this “ellipses” menu.
Having commands organized in a singular way should also be a boon to developers: Menus and toolbars and fizz don’t have to be coded separately.
That said, there are areas of this interface for which I’ve received criticism. Notably, because the whole interface is contextual, the “copy” and “cut” items only appear when something is selected, and only under that object’s menu (so if you select text and want to copy it, you go to “Text” > “Copy”). I’m hoping that these commands will be discoverable because they appear in fizz by default:
This is basically going to be an image-based post.
I’ve talked about command organization before, but now I’ve actually mocked it up. The following are not standard menus — they might include split buttons, galleries, color pickers, etc. Plus they change based on context (so when you have text selected, you get a “Text” menu, an “Image” menu with an image selected, etc.). This is done to minimize the number of dialogs in LibO, as dialogs are annoying and break workflow. On those operating systems that can’t handle these menus (Mac OS X and Ubuntu, perhaps, as they both use global menus), LibO should offer dialog windows instead.
This application menu will look a bit different on each platform. On Mac OS X and Gnome, it will integrate with the platform’s application menu. On Windows and desktop environments that allow widgets in the title bar, the menu will be in the title bar (à la Firefox). And everywhere else, it will be a standard menu. And here’s the rest of the menus:
Note: These mockups are based on the theming section of gnome-design git master branch. I’m not sure who the author of the theme is, so props to everyone involved. I’ll add a name if it surfaces.
P. S. Sorry for letting the blog stagnate for such a long time. I’m planning to post more now, but I can’t promise anything.
I’ve been gone for quite a while and it’s about time I wrote something here.
So, without further ado, I’m starting a new wave of Citrus posts. Expect a real post soon, for now here’s a mockup:
Quick summary (in the spirit of the first post):
- the menu bar has different categories
- there’s a search box on the same line
- there’s a toolbar below with commands that apply to the current selection on the left and common contextual stuff that doesn’t apply to the current selection on the right
- The ruler appears contextually, but can be enabled to show full-time or disabled completely.
- The status bar has been reorganized.
And here’s an SVG file (it should be much more browseable than the last SVG file): http://rapidshare.com/files/451087506/citrus.svg (sorry for the RapidShare, Google Docs wouldn’t cooperate).