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

Hi Jon,

Le 26/09/2012 16:34, Jan Holesovsky a écrit :
> Hi Michel,
>
> Michel Renon píše v St 26. 09. 2012 v 13:45 +0200:
>
> > UI decisions should be taken based on facts, analysis, polls, statistics.
>
> So this is the statistics I have at hand: Several people angry about a
> feature, and nobody praising it.  Now, you are the first one, so please
> tell me how much do you actually use Impress.  If you do, it is really
> hard to believe that you haven't got bitten by this yet.  Also, I would
> be most interested to hear how many times have you actually used the
> buttons.

I use Impress very few, but this buttonBar has never disturbed me.
I essentially use the 'duplicate' button of this toolbar.
I can list other parts of Impress that are "design nightmare" ! (I have 
a list of bugs of LO and I will create bug reports asap).
I asked other people (from my LUG) and they had no problem with the 
buttonbar, or even with the concept of popup objects. They even find the 
context menu (with right-click) so '90s (while still very useful) and 
tend to prefer the popup objects, because they become used to that with 
current web UI.

> We cannot measure everything, otherwise we wouldn't get much far because
> all that time spent talking, and considering, and writing
> specifications.  Much better approach is to try what seems good, and if
> it does not work, ie. we get complaints constantly, not only a few
> during a transition period, change it.

This way of doing is possible with a small user base (I did it twelve 
years ago while writing big and important software for Airbus : we used 
a kind of agile process (idea, code, feed-back and loop).
Early users (1-4 people) were also testers and we created a wonderful 
software, still used and appreciated! (10-50 current users)
However, with LO's user base, it's impossible : most users want 
something that just work out-of-the-box, they are not testers and don't 
want to be considered like that : they have to produce documents, mostly 
in professional context, that's all. LO must be stable, efficient and 
not change UI (that disturb users) every release.
You can imagine an equivalence with car industry : drivers won't accept 
a new car that has defaults or that is not complete or that has 
something for testing.

And look at the huge problem that Apple has to face with his incomplete 
Maps app. Tim Cook had to apologize and explicitly said to use others 
software (from concurrents!).
It's not a design problem, but it shows that a large user base can't be 
considered as testers ; they accept only a finished product (already 
tested).

> > >   Please note that Renaissance is 3-4 years old project.
> >
> > A good idea will never be obsolete ;-)
>
> Renaissance was a project, not an idea ;-)

Who cares where ideas come from ?
Henri Poincaré (a french mathematician) solve a problem while jumping in 
a bus, Archimedes is famous for taking a bath, Isaac Newton and an apple.
(ok, Newton's apple is a legend...)


> [...]
> > 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. 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 ?
> >      - should we use floating and/or docked panels ?
> >      When a decision is made, it should not change for several years (3-5)
>
> Alex / Astron / Mirek / others [in alphabetical order :-)] all have
> common vision, and it shows with 3.6 - it is the most beautiful open
> source office suite around.  How comes you have not noticed that? ;-)

I was talking about something precise : roadmap with practical guidelines :
- a roadmap defines "where are we going to ?"
- a roadmap defines "what is the schedule ?"
- practical guideline defines "what should you do/don't do ? how to 
react in every kind of situation ?"

In the context of design, it would mean :
- how will the LO's UI be in the future ?
- what is the schedule of the incremental/big changes ?
(in X months, the panel Y will be changed, etc)
- guideline are for devs / ui people (like Human Interface Guideline, 
for iOS or Android or MS or Gnome or KDE)

Today, the design principles are too abstract to be considered as 
guidelines.

And I repeat that such a schedule is important for companies and 
administration, so that they can plan one or two years ahead (training 
/migration)
> > - 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) ; it may also bring some big
> > inconsistencies [2]
>
> Imagine a new volunteer who contributed code to improve something, do
> you want to say him/her that "OK, but you haven't followed the PROCESS,
> return to the drawing board."?
yes !
because :
- we all make errors, and we all need our work to be checked
(I work with someone who says we all make 5 errors by day!)
- good will isn't synonym of skills (unfortunately)
- it's a professional behavior, determined par QA needs
- LO is such a huge software, it needs very strict processes

>  Do you think that he'll contribute the
> next time?
If he doesn't, he isn't professional enough.

As I understand the need to accept new devs, they could work on special 
branches (or sandboxes) : they can learn, test, be reviewed, improve 
their skills without disturbing the official branches.
Every change in official branches has to follow QA processes (for code 
and design).

FYI, this summer I started to dig into Thunderbird code (only js first, 
just digging in cpp now), because I was very annoyed by some 
never-closed bugs.
After few days, I had 2 patches. The Mozilla process is strict : you 
start by a review. One of my patch was refused because one comment was 
not starting by an uppercase letter and not finishing by a dot !
I was very surprised, but after few minutes I understood they have to 
have a coherent code, even the comments, and the comments have to be 
strict sentences with a beginning and a end without ambiguity. So I 
modified the comment and submitted again the patch.

> Sorry, but no - this is what this ux-advise list is for.  If the code
> looks good, and generally the idea looks plausible (even without
> extensive UX testing), the best is to get it in, and then _cooperate_
> with the author to make it even better, and fitting the overall vision.

I agree with you... if you talk about prototyping.

I would suggest that every UI/UX change be prototyped and validated 
before doing any cpp code.
The idea is to use very light tools/languages to create very quickly 
different proposals.
For my future prototypes, I plan to use html+js+css (maybe Extjs 
framework) because :
- easy coding : standard languages, full support by every IDE
- easy testing : no compilation ; edit --> reload page in browser
- easy deployment : push it on a web server (as static files) or zip and 
email it ; open with a standard web browser

For example, look at the current prototype of future thunderbird address 
book, by Mike Conley [1]
With few lines of code (plus some other libs) he created a good 
prototype and in 24 hours he had an amazing feedback [2].
No need to create a full thunderbird version !
[He had 2 very good ideas :
 - integrate a link "give me feedback" inside the prototype
 - the feed-back form is very short and related to a simple topic
]

Another type of feedback is the poll defined for OpenOffice4 [3]

> I really appreciate how Mirek reacted on what I've done - concrete
> points to improve (the toolbar that is too far, etc.).  That's something
> actionable, and the way I'd like to see the design<->developers
> cooperation in general - and I see it happening, thank you all!

The cooperation design<-->developers is something I've been missing 
since the beginning of LO. I discovered that list only few days ago...

IMHO, it seems that design team and devs are not well synchronized : 
devs sometimes needs infos to code a part, but design team is working on 
another part. Or design team propose a modification but there is no dev 
available to code it.

Maybe a (humble) proposal : create a small list of tasks (from usability 
bugs). Some members of both teams agree to work together to correct 
one/some of them for next release. Something similar to 'papercuts' from 
Mozilla [4], even if it was not a huge success...

Or, in a more official version, the TDF board could do something
similar to UDS (Ubuntu Developer Submit) : a series of conf/meetings 
where they decide the roadmap for the futures versions :
- they have some users request
- they have some proposals from designers and devs
- designers and devs evaluate (time needed, complexity)
- the board finally decides what will be implemented during the next year

And the next LO Conf is in few weeks ;-)


And something that might sound off-topic :
- the wiki page that list members of design team is difficult to find 
(http://wiki.documentfoundation.org/Design/Team) ; it is only accessible 
from the 'mentor' page, it should also be accessible from the default 
design page.
- that wiki page is outdated : it allows people to know each other 
(specially skills). IMHO, it seems difficult to get involved without 
such informations.


> > - 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)
>
> The best way is to test changes early - get the daily builds, test them,
> and report anything that you see problematic there.

I agree.
And it would be stronger with prototyping before : so that daily builds 
could never contains "design nightmare".
Changing important behavior or foundations in cpp code is always difficult.

> > and the context of my feedback is that I have not enough
> > time to work, propose on the UI/UX team, so it's just a little
> > reflexion/suggestion
>
> Well - talk is cheap ;-)  Please do get involved, the best is to improve
> something that annoys you - an icon that is unpleasant, a drawing
> artifact that shouldn't be there, etc.  Or just test the daily builds
> from time to time, that won't take you that much time.

I already get involved, but irregularly.
You can see my 4 proposals on my wiki page :
https://wiki.documentfoundation.org/User:Michelr

I never had feedback about my proposal "bullet and numbering" : what do 
you think about it ?

I have to finish my work on thunderbird (writing patches and new 
extensions) and then I'll begin to prototype some ideas for LO.
And submitting bug reports asap.

I guess you understand that LO is very important for me : I use it for 
years (well I started with OOo of course), I teach it in my LUG and have 
feed-back from users and I really want it and TDF to be successful. I 
just wanted to share my experience (I started to write software with GUI 
in 1986 on a Mac 512/800...)

Thanks for reading the whole message !


Regards,
Michel

[1] 
http://mikeconley.ca/blog/2012/09/26/a-glimpse-of-a-new-address-book-for-thunderbird/

[2] http://mikeconley.ca/blog/2012/09/27/i-hear-you/
and http://mikeconley.ca/blog/2012/10/02/update-to-my-address-book-mock-up/

[3] https://www.google.com/moderator/#16/e=2011d5

[4] https://wiki.mozilla.org/Thunderbird/Papercuts#Papercut_nominations

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