Re: [Libreoffice-ux-advise] Killed the ButtonBar in slide sorter

Hi Michel,

On Wed, Sep 26, 2012 at 1:45 PM, Michel Renon <michel.renon@free.fr> wrote:

> Hi Cor, Jan,
>
> Le 25/09/12 16:00, Jan Holesovsky a écrit :
>
>   [...]
> >  Therefore the good OpenOffice.org developers and people conducted a
> > > large project some years ago, Renaissance.
> > > Of course the toolbar is one of the changes the was a result from that.
> > > I guess all the work was done, because many obvious actions are not easy
> > > enough accessible for Joe-average. And that these were only the first
> > > steps in a route to make Impress (&more) more contemporary.
> > > The little pop-ups fit more in modern UI (-expectations) I guess then
> > > context menu's - let alone short-cuts and pull down menus...
> >
> > I don't think I agree with you here.  The touch-based devices need to
> > have everything shown, nothing appearing based on a presence of a mouse
> > pointer;
>
> It's a technical fact : touch interfaces have no 'hover' event.
> But look at what's happening with Nautilus : devs are making big changes
> to prepare for touch interface. The mistake is that they change *current*
> desktop version so that *future* versions may work on tablets.
> Since last year, users just can see Nautilus has less and less behaviors.
> Devs just say "we know what's good for you : we'll bring them back later
> for touch".
> The result is that the Nautilus project is forked and will be replaced
> very soon.
> We have to realize what for next 2 years (and more...), most LO users will
> still use a computer (desktop or laptop) to edit.

Actually, the new version of Nautilus is about as usable on a tablet as the
old version.
The changes have been brought about after careful deliberation -- you can
read about it in-depth at
http://blogs.gnome.org/mccann/2012/08/01/cross-cut/.

> Your modification will be useful for the tablet version of LO, but maybe
> not for the desktop version.


The on-hover button bar is being removed primarily because it causes
frequent accidental errors, not to better suit tablets (although that would
be a good reason as well).

>  and it seems to me as a good trend in general.
> >
>
> This is a personal and subjective opinion.
> UI decisions should be taken based on facts, analysis, polls, statistics.

Actually, I have heard widespread complaints about the on-hover control. I
myself have struggled with it.
Additionally, if you check the control against our design principles [1],
it performs quite poorly. It breaks ux-discovery, since it's not visible by
default, and ux-error-prevention, as any clickable buttons that appear
unexpectedly over another clickable target is bound to result in errors.

Why not allow users to enable/disable such appearing-controls by
> preferences ?
> Everybody should be happy :
> - beginners and average users won't see changes between versions
> - power users may choose what they prefer
>
> 1) It adds complexity (see Hick's law), goes against ux-minimalism
2) It has to be maintained.
3) It adds baggage to LibreOffice, makes it slower, makes the code
less manageable.

> As a general point of view on this subject, I would say that it shows
> several problems in the design team (that's why I'm CCing to design list) :
>
> - there is a lack of long-term vision for LO's UI/UX : a vision, a
> roadmap, with tenets.


Right now, we're hoping to change LO's UI iteratively, one usability
problem at a time.
Take a look at our design principles [1].

Some big users (administrations, companies...) need that kind of
> information so that they can plan training, migration [1].
> For example :
>    - should we use or avoid appearing / disappearing UI elements ?


Yes -- they go against ux-discovery and ux-error-prevention.

>    - should we use floating and/or docked panels ?
>    When a decision is made, it should not change for several years (3-5)

I disagree.
If a design has problems, it should be changed right away. It's best for
the user.

> - a developer may decide to make big UI changes, just because he talked
> with few users : it's a complete by-pass of the existing UI process
> (whiteboards, proposals, discussions, vote)


That process is for large design changes that need to be thoroughly thought
out.
It would be overkill to spend 3 weeks on minute design changes.

it may also bring some big inconsistencies [2]
>

It may also bring more consistency, such as in this case, where the
on-hover toolbar was unlike any other toolbar in both LO and elsewhere.

> - most important, it may changes/revert recent modifications --> users
> will be disturbed by those UI flip/flop (for example see previous changes
> between Rythmbox and Banshee in Ubuntu)

That's pure speculation.
I personally expect users to be glad to be rid of a usability nightmare.

[1] http://wiki.documentfoundation.org/Design/Principles