Since Citrus has gone through many changes since I posted the Inkscape SVG, here is a link to a newer SVG: https://docs.google.com/leaf?id=0B_RBf0YVtxzkYWFmYjM3YmQtYmU3OC00Zjg3LWE0MzctMTljNDJmY2NlOGM3&hl=fr
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?
While trying to reorganize LibO’s menus, I ran into a problem.
You’ve probably noticed that, in Citrus, menus (except “View” and “Insert”) are organized by the thing they apply to: things under “LibreOffice” apply to LibreOffice in general, things under “File” apply only to the current file, and so on.
You’ve also probably noticed that there’s no “Edit” or “Tools” menu in Citrus: they’ve all been sorted out into the appropriate contextual categories. The problem I ran into is that “Selection mode” doesn’t really fit into any of the categories I set. The only category that it sort of made sense in was “View”.
“View” is special in that it contains commands that pertain to the current Window. (If you change the view in one window, the view in other open LibO windows shouldn’t change.) Selection mode works the same way: if you change the selection mode in one window, it doesn’t change in another window.
So here I need Help appropriately naming the “View” menu so that it can also fit the concept of modes. (“Window” seems confusing, as many other programs use that menu to list open windows, but it’s a possible solution. “Instance” sounds too technical. And then I’m pretty much out of ideas.)
Not too long ago, I introduced Fizz. The point of Fizz is to make simple edits quicker. If you select text, you get Fizz, if you select an image, you get Fizz, if you select a page, a table, a chart, you get Fizz. Yet… there’s no simple way to select a paragraph.
So… here’s what I came up with:
This paragraph handle would only show up on hover over the area next to the paragraph.
Paragraph selection would be especially useful when it comes to lists: to move list items up and down, all you’d do is select them and drag. You would select multiple paragraphs with Shift/Ctrl.
I promised to talk a bit about LibreOffice Home, so here I go. (Keep in mind that this is all a proposal, none of this is actually planned for LibO.)
LibreOffice Home started basically just as a successor to the current Start Center, but grew into the successor of most of the current dialogs in LibO. It is an application separate from LibreOffice. It’s much lighter, and therefore loads much faster. Because it loads much faster, it doesn’t need a boot screen.
There are several different areas of the Home:
There’s the home page, which I haven’t really given much thought to. However, Christoph Noack’s Start center proposal seems quite promising. Just add a toolbar with a search box and back and forward buttons, and it’s good to go.
Then there are Options. For those, I do have a rough mockup:
You can tell that Options have been reduced: the less useful options would be made into extensions, the useful, but technical extensions would be under “Advanced”. Options would be saveable and loadable.
From Options, as well as from other places, you can access the Extension manager, the Theme/Template/Wizard manager, the Style manager, and the Font manager.
These managers are not really well thought out yet, and are definitely subject to changes. I was thinking the Extension manager could be somewhat akin to the Ubuntu Start Center, and integrate seamlessly with the online repository. I’m really not sure about a Theme/Template/Wizard manager yet. Actually, the only reason these three are together is because it’s the same as the “Theme/Template/Wizard” dialog used to create new documents.
There’s also a new Help dialog built into LibO Home, which is deeply integrated with the online Help. There are very prominent links to the online Help forums and bug reporting, and the documentation can be (if the user wishes) a mix of offline and online content.
In the next few days, I’ll be posting about two or three posts, and then I’m probably not going to be here for a while. These posts will be about ideas I haven’t really thought about much yet and that aren’t fully “baked” yet, but they might prove useful and inspirational nevertheless.
So I hereby kick off a very short series of experimental posts.
Whenever you have a major UI overhaul, it’s pretty hard to imagine how to get there gradually, without causing any power user to get frustrated and leave.
So I put together this potential roadmap on how LibO could get to Citrus gradually:
Milestone 1: The little things
- Improved splash screen: make the splash screen tiny, undistracting, and put it off at the bottom of the screen.
- Contextual toolbars no longer hide the selection: Make the contextual toolbars that appear when you’re working with an object (tables, pictures, lists, …) appear above the object (so that it doesn’t cover up the object).
- Make slides scrollable: the scroll bar in Impress should scroll through the different slides, much like it can scroll through different pages in Writer.
- Make bundled styles deletable (but restorable if deleted)
Milestone 2: Things to make a new UI painless
- Make customizations saveable: by “customizations”, I mean things from the “Customize…” menu: toolbars, menus, and keyboard shortcuts; these things should also stay when you upgrade to
- Add basic command search to LibO (the Mac OS X version already has one under “Help”)
Milestone 3: Gradual UI changes
- Previews: in the font and styles pickers, preview fonts and styles; also, preview changes live in the document (i.e. “live previews”)
- Color picker: implement a color picker that lets one pick ANY color
- Search Box: Make command search into general search, as described here.
- Menu/toolbar reorganization: the menus and toolbars can now be reorganized, as customizations are saveable and loadable. Disabled items should be hidden by default. It should always be possible to get back the classic interface from “Customize…”
- Styles: give styles a more prominent place in menus, as described at this link. Where such integration into menus is impossible (such as in Mac OS X), add a link to the Style sidebar, which has the same functionality.
- Selectable pages: as described at this link
- Different tab management: see “Citrus tabs“
Milestone 4: LibreOffice Home
I’ll have more on this section later.
- LibreOffice Home: LibreOffice Home will be what comes up when you launch LibreOffice. It’s the successor to the Start center. What’s different about it is that it’s an application separate from the main LibO application. It starts up quickly while LibO’s still loading. This allows it to replace the splash screen.
- Simplified options: Options should be greatly simplified, so that they’re actually usable. That means making some of the rarely used, unnecessary options into extensions and putting the technical, yet very useful options under “Advanced”. ”Customize…” and “Extensions” should be merged into Options.
- Improved theme, template, and wizard manager
- Font manager
- Style manager
There’s a UI element I haven’t brought up yet. I’m sure you’ve seen versions of it elsewhere, I’m not sure what it’s called though, so I’ll just call it Fizz for now, because that’s terse. It appears centered just above the selection.
Unlike MS Office’s Mini toolbar, Fizz always appears above the selection and so never obstructs any part of it. It also packs less buttons by default (copy, cut, and styles, plus some other common commands), since it really is meant just for quick edits.
Fizz is basically just an abridged contextual toolbar, and the user can always get the full toolbar by clicking on the “…” symbol. And, yes, Fizz is customizable.
Fizz, along with the contextual toolbar, also provides a way to get to the features of Direct manipulation snippets, like spelling suggestions, hyperlink editing, etc.
This post aims to summarize everything style-related about Citrus.
Where they are
Styles appear in several places in Citrus. They appear in contextual menus (“Page”, “Paragraph”, “Text”, “Image”, “Table”, etc.).
They appear in the contextual toolbar.
You can even have a Styles sidebar. And you get styles on right-click.
You can edit styles from all these places except for the right-click menu. You can also edit them in Options (along with Fonts and Templates), where you can also export and import them.
When editing styles from the sidebar, toolbar, or menu, you get something akin to this:
Check boxes are used to specify what attributes apply to a style. From the “wrench” menu, you can duplicate or delete it, and you can set its keyboard shortcut or the style that follows it. You can do the same from the “Style settings” category.
Style groups are now what parent styles/linked styles used to be: you use them to edit several styles at once. Groups can be either hierarchical or unordered.
And yes, you can have groups nested within groups, simply by dragging and dropping a group into another group.
Alternative to styles
Since people on the mailing list were talking about automatically creating styles from hard formatting or about hiding hard formatting options to get people to use styles, I want to bring up an incredible replacement for styles that people forgot about. It’s not a new feature — it’s called “Find and Replace.”
Just like you use styles, you can use Find and Replace to quickly search for and select text with certain formatting and then change that formatting. Yes, it doesn’t work nearly as well as styles do, but it’s definitely enough for the average user who doesn’t want to use styles.
Putting styles ahead of hard formatting is NOT a good solution. Styles are good for books or long documents, but not for a 2-page-long essay. And hard-formatting will always be easier and quicker than using styles. (Yes, we should work on styles, but in no detriment to hard formatting.)