Citrus Impress

I’ve been writing exclusively about Writer (because that’s the application I use most often) and it’s time to talk about my ideas for Impress. A lot of the ideas that went into Citrus Writer also apply to Citrus Impress. The end result is a much simpler, yet also a bit unusual, presentation application:

Slides are now scrollable, just like pages (makes it much easier to navigate through presentations).

The slide pane is gone, replaced by Navigator.

Just like with Writer, you get the Toolbox, you can select slides easily, and you can insert slides easily.

The menu structure has changed quite a bit, following Writer’s example. Slide show options are now under “Presentation”, transition options under “Slide”, and animation options under a selected object’s menu (way at the bottom of the menu, to discourage the use of animation as it can easily ruin a presentation).

(Note: The mock-ups are a bit off, acting as if text is selected. The toolbar should show commands related to the current slide and the toolbox shouldn’t show text-related commands.)

Command cleanup: Toolbox

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.

Navigator Simplified

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?

Nautilus nostalgia

I must’ve seen this mock-up before, but I forgot about it. If I remembered, that might have saved me the trouble of mocking up Tap from scratch. (Now that I look back at Tap again, I agree that my mock-up was unnecessarily complex and unwieldy.)

This mockup comes from a group of Gnome enthusiasts: Garrett LeSage, Allan Day,  Hylke Bons, Máirín Duffy, Lapo Calamandrei, Andy Fitzsimon, and others. The blog post that this mockup comes from discusses the possible evolution of Nautilus (which has been transformed into today’s much heavier Nautilus 3).

There’s one particular UI element that I really like about it, though, and, sadly, it hasn’t been implemented in Nautilus 3: the Actions bar. This bar would “show relevant actions for the selected item”.

While that’s not necessarily revolutionary (this functionality being hidden under a right-click menu for years), having this functionality up front could potentially lead application developers to integrate better with this toolbar, which could make the experience of moving between file browser and application more fluent (as I talked about in a previous post).

Command cleanup: Indicators and the status bar

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.

Command Cleanup: Menus and toolbars and fizz, oh my!

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:

(Note: the icons would be different. I’m just experimenting with using the standard file manager symbols for copying and moving for the clipboard.)