Citrus: Editing styles

You edit styles through an “Edit” button in the menu, which gives you:

It’s a pretty huge menu, since it includes all the various things you can set for a paragraph. When menus are this big, they get expandable categories. In this mockup, you see 9 of those, of which only “Font” is expanded.

Styles are now managed a little differently. First of all, parent styles are now called “groups”. Groups can be either hierarchical or unordered. (You can tell by the small numbers in the mockup that “Headings” is hierarchical.) You can drag hierarchical styles up or down to move them up/down in their hierarchy.

Instead of linking a style to a style, you put a style into a group. It’s the same principle, just with friendlier terminology.

You turn a style into a group through a “Tools” menu (or a right-click). You can also delete a style or change its shortcut from this menu.

You choose what formatting applies to a style by checking/unchecking its checkbox.

Lastly, bundled styles are now deletable (but you can easily get them back from the LibO website).

P. S. On the topic of customizing tabs as a part of a style, it’d be nice to be able to do that both visually with a full-scale ruler and using a table. I’m thinking a “Use ruler…” under the “Tabs” category could do the trick.

Citrus: An evolution of the menu

I’ve been thinking about the menu behavior I introduced and there’s something that really bothers me about it: If it was possible to have several submenus expanded at once, the menu would get big pretty quickly. And if not (i.e. if by expanding a submenu, the last open submenu would be closed), then all the menu items would fluctuate a lot when expanding new catagories and automatically closing old ones.

So, going back to the drawing board, I pretty much reverted back to the old submenu-on-hover behavior, except now when a user clicks on a submenu, it sticks until the user clicks somewhere else. This is intended as an accessibility feature. I might have a mockup soon, but there’s not really much to show.

Splash

Splash screens always bothered me. They unnecessarily take up screen estate (and right in the middle of the screen, the place you need most) just to tell me that my application is loading. I know that it’s loading — I launched it. None of my other applications load right when I click their icon, and they don’t need splash screens.

IMHO, the splash is the most annoying and unnecessary UI element in the history of UI elements. And I want to at least replace it with something less annoying.

Splash meets Start Center

The first way to do this is to load the start center instead of the splash screen. That way, you don’t have to just sit and wait while LibO loads, but you can pick which app to work in or open a document. If LibO’s not done loading yet, you’ll get a progress bar under the task you chose.

You also get window buttons, so that you can hide the splash or close LibO if you opened it by accident.

PLuP

The first splash proposal applied only for LibO the application. This second proposal applies for the various applications of the suite (Writer, Calc, Draw, …), since those don’t use the Start center.

This is what their miniscule “splashes” would look like:

They’d be transparent, positioned on the bottom of the screen, and either centered or right-aligned.

Why We Can Do Better than the Ribbon

There’s a bunch of people who like the Ribbon. And there’s a bunch of people who don’t like it and either keep using Office 2003 (or earlier), use alternatives like OOo and LibO, or crankily use one of the ribboned versions of Office.

I actually think the change from Office 2003 to Office 2007 was a positive one. Here’s why:

• The organization finally makes some sense, and a user can now easily find his favorite commands.
• It is the one central place to find everything.
• It brings more functionality.
• It has some big buttons that are easy to hit with a mouse cursor.
• It looks good.

None of these things really require a Ribbon. This can all be accomplished with our classic menus and toolbars.

Here is where the Ribbon fails:

• It’s not very scalable.
• It’s horizontal, so it’s unintuitive to scroll through and move through.
• It takes up a lot of valuable screen estate (vertical space is more valuable than horizontal; sidebars would have been better).
• It’s browsed by icons, not by text.
• For acceptable scalability, each icon has to have several sizes.
• There’s an ambiguous “Home” category and “Quick Access” toolbar, which include various commonly used commands.

I’m convinced we can find a better UI than the Ribbon. I don’t think maintaining several different UIs for LibO is a good idea (that’ll just bloat LibO and take up development time) and I don’t think adopting the Ribbon is a good idea either, even if MS’s Ribbon patent gets rejected.

It seems that OOo is going to have both the Ribbon and the old interface (which I think is a horrible idea), and I’m hoping LibO will go another way.

I’d like to hear some comments on this from the LibO leaders: Does LibO plan to work on their own UI if OOo gets the Ribbon?

I’m also looking forward to some UI proposals from others: some people on the mailing list said that they were already working on them. There’s a good chance that the future LibO UI will beat anything MS has.

Go, make your own UI

I’m releasing the SVG to Citrus UI under the CC0 license (that means you can do whatever you want with them, without any restrictions) where possible — I’m not sure how the LibO logo, which is used, or the various fonts I used figure into this, so this license only applies to the parts that are my original work.

Here it is: https://docs.google.com/leaf?id=0B_RBf0YVtxzkYWFmYjM3YmQtYmU3OC00Zjg3LWE0MzctMTljNDJmY2NlOGM3&hl=fr

It’s an Inkscape SVG with a bunch of (mostly unnecessary) layers. You’ll need the fonts Vegur, either the Bitstream Vera or the DejaVu Sans and Serif fonts, and the Ubuntu font for it to look the way it should.

I’m hoping people will take it, edit it, tweak it, and add to it to make their own UI mockups.

P. S. I’m not sure about the licensing of the current LibO logo. Tell me if I should remove it.

Citrus Tabs

Since Citrus UI hides rulers by default (based on an old discussion on the OOo mailing list), I wanted to figure out some other way of presenting some of the functionality of the good ol’ ruler (like tab and paragraph alignment) to the user.

So… This shows up when a user puts the cursor at the borders of a tabbed space (by clicking or using the keyboard). If the user clicks on the tab symbol, he’ll get a drop-down menu of all the possible tabs (left, right, center, decimal), along with a “Reset this tab” button, which puts the tab in its default position (just like when you drag a tab symbol off the ruler). If the user drags the resize handle, the tab moves accordingly.

The same with the other types of tabs.

It works for columns too.

UPDATE: Here are a few other mockups of tabs in various situations.

UPDATE 2: I replaced the main mockup with one that shows more text and a cursor.

UPDATE 3: As Johannes Bausch suggested on the mailing list, dragging a tab’s resize handle should trigger the ruler. When finished dragging, the ruler should hide again.

The Citrus Search Box

The Search Box is basically an all-purpose search box.

It can search the current document, all open documents, menu items, help items, and, if enabled (as sending queries online is a privacy concern), online help items, tutorials, and commands from downloadable extensions. If the list of search results is too big, it’ll get a scroll bar.

When you push one of the “find” arrows (the ones you use to search the document), all of the command suggestions will get hidden under an expandable menu so that you would see more of the document.

(Oh, and it’s accessible with a keyboard shortcut. And you can use the arrow keys along with enter to navigate through it.)

Citrus: Page selection

(If you haven’t read about Citrus UI, you might want to read at least the intro first.)

You probably noticed that there is now a page number next to the page in Writer. This number is actually a bit more than an indicator — if you click on it, it selects the page group (page groups end at page breaks).
With the page group selected, the contextual toolbar now shows page options (don’t mind the mockup — by default, there would be several more buttons in this toolbar), letting the user quickly change the style, orientation, add headers/footers, etc. The same behavior applies for slides in Impress.

This page number can also be dragged to rearrange pages or slides under a smaller zoom.

Citrus: Possible solution to pane

I’m posting this because it deals with the multiple-pane problem discussed on the mailing list.

Here’s a work-in-progress of the LibreOffice menu mock-up.

Multiple panes would be managed under the “Layout” dropdown — you would select the open documents you’d like to open under several panes in a single window, click “Layout”, select the pane layout.

To separate a single window with multiple panes back into several windows, you’d select that window and choose Layout -> Separate panes into windows.

(Note: arrows pointing to the right indicate that the button expands as a pane on the right.)

The Citrus Menu

(Read the intro before reading this.)

The menus in Citrus aren’t quite what menus are today. I’ll explain with a mockup:

You’ll notice a few different things. There are sliders and buttons and text boxes in the menu now, to replace dialog windows. In this menu, there’s also a second pane that houses styles. You can now edit styles right within the menu. This same pane appears in all the other menus that use styles, like “Pages”, “Paragraph” or “Tables”.

Essentially, what used to be done through a variety of different interfaces (sidebars, toolbars, menus, dialogs) has now been consolidated into one central menu bar.

You’ll also notice that arrows now point down instead of to the side. That’s because categories now expand downwards, on click by default (as opposed to the classic on the side on hover). And if the menu (including the Styles pane) gets too big, a scrollbar will appear.

So why the change? Well, the new menu is much more like a dialog. That means that when people open a submenu, they will most likely be doing something that takes more than one click (in the mock-up above, a user might want to customize both the style and the color of an underline). Classic menus close on a single click. Also, opening submenus below decreases mouse distance and makes it much easier to hit the target. Opening menus on hover makes it hard to hit the target, because if you accidentally move your mouse, your whole submenu goes away and you have to navigate back with your mouse.

And that’s the menu. Feedback wanted and greatly appreciated.

I think I’ll tackle the search box next.

(P.S. For all the people out there who prefer the classic UI, assume that this UI will be as customizable as OOo is now and hopefully more. Ideally, anyone should be able to reproduce the Classic OOo UI in this.)

(Continue on to Citrus: Possible solution to pane)