Category Archives: Mockups

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?

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.)

Command cleanup: Menus, again

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.


To kick off the next wave, let me introduce a proposal for the successor to the Welcome screen: Tap. (Yes, the idea called LibreOffice Home is dead.)

Big thanks to DanRabbit for his elementary icon set and his Marlin mockup: they’ve really helped with the mockup.

It’s actually a file manager, inspired by Google Docs, Shotwell, iTunes, and other software. Why?

1) To close the gap between the file manager and the office suite
When you open an office suite, you either want to edit an existing file or create a new one. To do the former, you need to go to your file manager, navigate through a maze of files and folders to get to your file, then wait a few seconds while your office suite loads. (Alternatively, you can launch the suite first, then use the “Open…” dialog, but that’s a very similar experience.) To create a file, you need to launch the suite, create a blank document, immediately save it (choose where it goes and name it), and then you can edit it. Neither experience is very fluent or comfortable, because there’s a pretty big disconnect between the file manager and the office suite.

And here’s where Tap comes in. First of all, because Tap offers only select formats, it’s much easier to find a specific file. Nothing irrelevant gets in your way and there’s no complex hierarchy. Second of all, Tap loads the office suite in the background, so files open very quickly and there’s no splash screen disturbing your workflow. Creating a new file takes one or two clicks, and the user is first prompted to name it and then to edit it, much like when you create folders.

2) Sync and sharing

With the increasing popularity of mobile and web office suites, it’s becoming more of a need to sync and share files over a variety of platforms and devices. Most generic managers weren’t built with this functionality in mind, so developers of online and mobile office suites need to add this functionality to these managers. Unfortunately, generic managers tend to vary from OS to OS, meaning that if a service wants to integrate syncing and collaboration features with common file managers, it needs to develop a separate solution for all the various managers out there (Nautilus, Dolphin, Mac OS X Finder, the various Explorers, …).

With Tap, developers of both web and mobile office suites can focus on integrating sync and collaboration features with a single, cross-platform file manager that’s built with this kind of integration in mind, rather than the notorious variety of generic file managers there are.

3) Collections
Instead of folders, Tap works with collections. Collections are basically a best-of-both-worlds combination of tags and folders: they’re tags with a hierarchy (you can place a file in several collections, and you can have subcollections). If you have your files organized into folders, your folders can be effortlessly converted into collections, and so can your tags.

4) Unified experience
If Tap is ever developed, it shouldn’t be tied to LibO. All office suites should be able to take advantage of Tap, and it’d be great if Tap could actually be a standalone file manager, integrated with formats and applications of the user’s choice.

P.S. SVG of mockup here:

Citrus: Wave 2

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): (sorry for the RapidShare, Google Docs wouldn’t cooperate).

Citrus UI: Review

UPDATE: Here’s a more current version.


Hi everyone,
I still don’t have time to work on Citrus yet, but, as in the last days I’ve been getting many more hits than usual, here’s a list of all the important Citrus UI posts I’ve done so far:

Citrus UI: the first post

How styles work + how menus look

How the menus are organized

Managing windows through LibO menu (early prototype)

Fizz: small toolbars that show up with selection

How you can select pages

How you can select paragraphs

How you can select and edit tabs


Replacing the splash screen

Citrus: Where things go

Commands in Citrus are organized a bit differently than how they’re organized now. The new organization aims to bring more logic to the whole organizational structure and weed out vague categories like “Tools” or “Edit”, as well as bad categorization (e.g. how the “File” menu is used to house commands that aren’t related to the current file).

Also, menus are now contextual, which means that you no longer get grayed-out menus and commands, but rather these inapplicable commands and menus are hidden by default.

The new menus are:


The LibreOffice menu includes everything related to the application as a whole. It features commands for creating and opening documents (“New“, “Open“, “Open Recent“), managing open windows, and using and managing the application (“Options“, “Help“, “About“, “Extensions“, “Quit“).


This menu houses everything specific to the currently open file. It includes commands for file output (“Save“, “Export“, “Print“, “Rename“, “Preview in browser“), file history (“Undo“, “Redo“, “Repeat“, “Versions“, “Track changes“), and other commands that have to do with the whole file (“Statistics“, “Select all“, “Refresh“).


Everything specific to the current window goes under this menu. Basically, it includes all the commands for showing UI elements in the current window (“Show Ruler“, “Show Navigator“, “Toolbars“, …) and commands concerning window modes (“Zoom“, “Full screen“, “Selection mode“, “Outline“, etc.).

This menu is more like the old View menu rather than the old Window menu, but as it is placed where the View menu used to be, and as it’s immediately obvious what this menu does just by looking at its commands, it shouldn’t be too hard to get used to this menu.


Just like now, Insert is a menu for inserting stuff into the document. Paste is now the first item under Insert (because when you paste, you insert stuff).

Contextual menus

Then you get contextual menus. When you open Writer, with nothing selected, you get three contextual menus: Pages, Paragraph, and Text. If you were to select an image, you’d no longer get a Text menu, but you’d get an Image menu instead. You might not even get a Paragraph menu — that depends on whether the selected image floats or behaves like a character.

Pages contains commands that pertain to the current page group. It basically includes all of the commands from the current “Page…” dialog, as well as Page styles. As long as you’re in Writer, you’ll get the Pages menu. If you were in Impress, you’d get the Slide menu instead.

The Paragraph menu also contains all the commands from the “Paragraph…” dialog and Paragraph styles, as well as “Bullets and Numbering…”

The Text menu includes character formatting options, styles, hyperlink and language options, as well as “Cut” and “Copy“.

Cut and Copy are now under contextual menus. If you’re working with a text in a chart, you can copy some selected text from the chart under the Text menu or copy the whole chart under the Chart menu. If nothing is selected, you don’t get Cut/Copy.

That’s the jist of it. I know I left out a ton of stuff, so feel free to post comments with questions.

Citrus Labs: Color codes

The icons in Citrus are very simple. They usually use one or two colors: white/black (depending on the theme) and a “group” color.

By “group color”, I mean a color attributed to a certain set of commands. In the two mockups above, you can tell that blue is the group color for text commands, while orange is the group color for paragraph commands.

These icons weren’t originally intended as part of the proposal, but I wonder if this kind of color coding might be a UX improvement, as it visually separates the toolbar into sections and makes it immediately obvious what you’re working with (e.g. you could see that you’re working with an image because the group color of the toolbar would be yellow).

What do you think?