Date: prev next · Thread: first prev next last
2012 Archives by date, by thread · List index

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

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

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 :

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 !






Unsubscribe instructions: E-mail to
Posting guidelines + more:
List archive:
All messages sent to this list will be publicly archived and cannot be deleted


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.