[libreoffice-design] Some Feedback on Citrus.

Hi everyone,

a few days ago, Andrew asked for feedback on Mirek's Citrus proposal.
So, here, I want to start a thread on what I/we like and what I/we
don't like (about the desktop/laptop proposal), in the hope that it
helps Mirek to refine his proposal. Please note, I am not a regular
reader of Mirek's blog and my assumptions are based on the short
descriptions from the wiki, so if anything on this list seems wrong to
you, feel free to correct me.
Here we go, structure is as on Mirek2's wiki page:

* Ellipsis menu:
I like the idea and it looks much better (cleaner) than it does
currently; for executing commands it is also more functional.
Here's what I don't like: that you can customise your toolbar via
drag-and-drop is not made visible at all; for users of accessibility
solutions there seems to be no way to add or remove something.

* Page/slide handles:
I like the idea (so much I opened a bug about it – fdo#38597). There's
a lot to discuss, though, before this can be implemented (how it
zooms, how it acts, etc.). Also, the proposal doesn't work at all for
Calc (which Mirek explained, he uses so seldomly that he didn't
include it in his proposals).

* Continuously scrollable slides:
Not a bad idea for the read-only mode. When editing a document,
however, there will sometimes be the case that an image or other
element would overlap into the next slide. What should LibO do then?
Push the slide further below? Cut the element off in between the two
slides? I'm sceptical.

* Add page/slide:
I can see this being very useful in Impress and Draw, but in those
programs, I would probably put this button into the sidebar.
For Writer, it would be similarly useful, but we'd also need more
complexity: it'd need at least a "Add page" and an "Add Section"
button (unless there is any way in which we can make those two
commands the same).

*Float bar:
I'm not sure that I heavily subscribe to this – there is a similar bar
in the Pencil extension for Firefox that I use for mock-ups that pops
up when one edits certain text fields.
I think the most important aspect for the float bar is that it keeps a
large enough distance from the element, so it doesn't annoy the user
or gets in the way; and still is not positioned so far from the
element that the user thinks it doesn't belong o the element any more.
There are a few other positioning questions that need to be solved: if
the element covers the entire screen, where would the float bar be
least in the way (it can either cover the element itself or cover the
docked toolbars or maybe could be positioned vertically) ... what's
the best option?

* Insert bar:
This is an idea from Ooo 1.0, I think. I'd love to know why it was
abandoned, then, because it probably is a good idea..?

* Live preview:
An MSO idea. I am unsure how much I like it, but I am pretty sure that
developers will protest at its resource usage. The idea is also not
very detailed.

* Color-coded icons:
This is a really good idea. But, I think, the codification is wrong.
Currently there are too many shades that are so close to each other
that no user will associate them with their underlying functional
aspect. Similar shades would appear clustered in certain application
(textual shades → Writer). Two ideas:
→ reduce the shades to only a few (~5)
→ maybe use menu titles as the basis for which command should have an
icon of which shade (one for file actions, one for editing, viewing,
formatting...)
I'd love to see if such a colour coding system is viable. I'd also
love to know if it is problematic for colour-blind or otherwise
visually impaired users.
By the way, building such an icon set is something the design team can
do on its own (all you need is a zipping tool, graphics software, a
file manager and lots of time) – so it could be the first part of
Citrus that would actually be implemented.

* Reduced standard toolbar:
I agree, mostly. I think Print is essential though. I always hide
Email (because I am a bit of a Ctrl frk and always open documents
again before sending, then drag/drop them from the file manager into
the mail application), but I think many people would see Email as
equally essential.
Finally, there is a command that I often use, but that doesn't fit the
standard toolbar even today: Non-printing Characters. Where could it
go or do we not need it in the toolbar? (I am assuming the Gallery
would become part of the Insert toolbar – is that correct?)

* Drop-down buttons:
Creates a lot of functional inconsistency, I don't think users would
like it. But we can agree on the direction of the arrows.



* Sorting out commands:
Good principles, basically, but probably too rough to be usable in
their current form. Point two (no greyed-out buttons) is contradictory
to the reasoning found under Reduced standard toolbar (clickable
buttons as indicators).
Also, this is part of the proposal is throwing (useful) conventions
out of the window: should we really move Cut, Copy and Paste into
completely different menus?

* Getting rid of formatting dialogs:
Granted, I am biased here [1], but I don't like interacting with menus
in this way at all, even though that's something Microsoft Office
makes heavy use of.
It is also a huge, huge, huge amount of work for an unclear (to me)
benefit. Two disadvantages of relying so much on rich menus:
→ opening menus to change anything all the time should be pretty annoying
→ customising styles is made very hard (we should want people to use
styles, so they can create more coherent looking documents more
easily!)

* Combining navigator and side pane.
I never actually use the Navigator, but I think that's an idea (a very
rough one, though) worth investigating.

* Simplified Options:
I am pseudo-actively working on a proposal here [2], so yes, absolutely.

* Rich menus:
In principle, yes, but I wouldn't base the whole UI on them (rf.
Getting rid of formatting dialogs).

Overall, this proposal is quite coherent (and radical and creative)
and that's all good, but there are still too many loose ends hanging
around.
Blip.
Astron.


[1] http://wiki.documentfoundation.org/Design/Whiteboards/PropertiesButtonLayout
[2] http://wiki.documentfoundation.org/Design/Whiteboards/OptionsRework

-- 
Unsubscribe instructions: E-mail to design+help@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted