Re: [libreoffice-design] Some Feedback on Citrus.

Hi Astron, everyone,

2011/10/30 Astron <heinzlesspam@googlemail.com>

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


The ellipsis menu wouldn't be the only way a toolbar could be customized.
If the ellipsis menu was implemented in today's LibreOffice, there would
still be a link to the Customize dialog in the menubar and the toolbar's
right-click menu.


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

It shouldn't be in Calc, at least not with how Calc works now.
I don't think Calc lets you change page formatting for each page
separately, so being able to select separate pages would be of no use. (You
can select the whole table with the blank top-left corner cell, though.)
And Calc already has a way of showing page number under Page view,
different from how all the other LibO apps show page number.

> * 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.
There are two ways it could go:
- Keep it shown on both slides, and leave cropping to the user.
- Keep the element shown on one slide only. If the user wanted to have it
on both slides, he would simply duplicate it.
I think the latter would be the ideal way of going about it, as it would
keep the functionality the same and therefore there would be no
compatibility probems between LibO versions.
The object would show up only on one slide, that slide being the one it was
created in (if it was a shape, this would be the slide in which the cursor
was placed initially) or dragged to (that is, on the slide where the cursor
stopped).

> * 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.
There is no sidebar for Impress/Draw in Citrus (unless you mean the
Navigator). The point of this button is to have a button inline, so that a
user didn't have to have a sidebar open to get this core functionality.
That's especially useful when working on a small screen and/or with two
windows side-by-side (which I have quite often).

> 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).
It's in the more recent proposal (add page is centered on the left half,
add section on the right half). :)

> *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?
The whole point of the float bar is to be as close to the selection without
covering it, so as to minimize mouse distance. That's the reason for having
it. Otherwise, there is no difference between it and the toolbar -- it can
only contain the same commands as the toolbar. And just like the toolbar,
it could be hidden/shown in the "View" menu.
(It would show up on any selection, it wouldn't discriminate.)

> * 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.
That was an older idea that really isn't that necessary. I'm all for saving
resources.

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

That was kind of a point: that way, Writer would have an associated blue
color, Calc a green color (green for tables), Impress an orange color
(images), and Draw a yellow color (shapes), just based on the kind of items
you work with most in these applications. Hue represents category (whether
the object is mostly visual, audible, textual, numerical, or a combination
of these), darkness shows hierarchy ("Page" is superior to "Paragraph",
which is superior to "Text", so "Page" is darkest and "Text" lightest) and
contrast shows relevance (a paragraph can not only contain text, but also
an image, although its primary purpose is still holding text, so its color
has less contrast than that of a text box, which can contain only text).

> 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...)
It does use menu titles as the basis, only the titles of the menus proposed
for citrus. If it used the current menu titles, most toolbar icons would
end up based on a single color, no matter what the toolbar would pertain
to, as the toolbar holds mostly formatting commands.

> 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.
As problematic as the current scheme, if not less.
This icon theme would have a lot of black-on-white (or white-on-black,
depending on the user's theme) icons, which have high contrast and are
great for visually impaired users.
Restricting a single icon's color scheme to only three shades allows for
better automatization: making a variant for dark themes could be as simple
as making a script to turn all the black shapes into white shapes (and
maybe to brighten up the object's color too), shading could be automated
also. Making a high-contrast theme would also be easy: just turn the
object's color into black (or white with an inverted HC theme) and lose the
shading.
Much simpler than with multi-colored icons.

> 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.
On the other hand, it would be a lot of work. A lot more, I think, than
implementing the "Add page/slide" button...
Not only that, we'd also need to make sure that the designers can make
similar enough icons, so that there's no obvious difference between one
designer's work and another's.

> * 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?)
There are a lot of commands that could go in here. I recently found myself
using "Export to PDF" in Draw, as I needed to add a signature to about 25
PDF's and there was no keyboard shortcut for this command.
Before we reduce the standard toolbar, I recommend adding in more
shortcuts, so ALL commands are equally accessible by keyboard.
(Surprisingly, even google Docs seems to outperform LibO in this respect,
offering shortcuts for styles, for superscripts/subscripts, and making
Ctrl-Shift-Z as well as Ctrl-Y redo; I use these a ton.)

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


I know it creates a bit of inconsistency between vertical and horizontal
toolbars, but at least it makes vertical toolbars usable. Honestly, a
vertical Drawing toolbar is pretty unusable right now.

> * 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?

Why not? They're used in different situations. You can only use "Copy" and
"Cut" when you have something selected. And you can only use "Paste" when
you're in an editable field. "Paste" therefore fits perfectly under
"Insert", while "Cut" and "Copy" fit well under a contextual menu/toolbar.
Sure it takes a little while to get used to, but it really makes much more
sense than a generic "Edit" menu.

> * 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
that's why toolbars contain the same commands as menus: so that you could
do everything quickly, right in the toolbar

> → customising styles is made very hard (we should want people to use
> styles, so they can create more coherent looking documents more
> easily!)
how so? You simply push "Edit" and edit the formatting options.

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


I've only used it in Writer, and it always seemed so much more complex than
it had to be. I wouldn't call myself a pro user, though.

> * 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).
Me neither. I'm actually backing away from rich menus right now, as they
break most operating system's UI guidelines and they probably wouldn't be
very cross-platform. (I don't think Mac OS X or Ubuntu Unity's menu bar
would allow these rich menus.)
On the other hand, they would be pretty useful if they were implemented on
at least some platforms...

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

P. S.  -- , so I probably won't read or answer other mails on the mailing
list today (there are quite a few unread mails), as I just came back from a
permaculture seminar and now I have some work to do and then a lot of sleep.
This one e-mail just got my attention. :)

> [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

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