Le 26/09/2012 16:34, Jan Holesovsky a écrit :
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
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 .
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
And I repeat that such a schedule is important for companies and
administration, so that they can plan one or two years ahead (training
- 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
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."?
- 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
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
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
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
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 
With few lines of code (plus some other libs) he created a good
prototype and in 24 hours he had an amazing feedback .
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 
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 , 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
- that wiki page is outdated : it allows people to know each other
(specially skills). IMHO, it seems difficult to get involved without
- 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.
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 firstname.lastname@example.org
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
Impressum (Legal Info)
: 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