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