[Libreoffice-ux-advise] ux-advise advice
jean-francois.nifenecker at laposte.net
Sat Feb 18 08:22:13 PST 2012
Hi again Michael,
it's a real pleasure to talk with you in a smooth and sensible manner. I
feel much better than when reading some previous msgs on the other thread.
I may be somewhat long here and, hopefully, won't bother and take too
much of your (precious) time.
Before I go any further, let me introduce myself -- which I should have
done long before: I'm a 56 yo French civil servant using OOo since 2005
when my employer decided to move from MSO. Since then I never looked
back and I have always been very pleased with OOo.
In a former part of my professional life, I had been an unofficial
part-time programmer (Turbo-Pascal, Object Pascal then Delphi). Though
this was supposed to be a part-time job, it in fact took most of my
time, daily and nightly for nearly 15yrs. I was forced to stop sometine
after I switched job as I couldn't do both. Now, I've been an IT tech
(support chain) for 20yrs. As such, among a lot of other things, I help
and train my colleagues to our office automation suite of choice (was
MSO, now OOo, soon to be LibO). More importantly, I can see everyday how
and why my colleagues use the software, what they do right and what they
do wrong. To the risk of seeming overly proud, I think I have a broad
view of our corporate workflow and I can tell where the local pitfalls
are (wrt office automation tools). I have some ideas of what's wrong
with the current textprocessors and in which direction some changes
would be beneficial to their users. (hence my visit here ;)
Now, back to the discussion :)
Le 18/02/2012 15:51, Michael Meeks a écrit :
> On Sat, 2012-02-18 at 14:00 +0100, Jean-Francois Nifenecker wrote:
>> Ah! Ah! I'm starting to get the real thing which has nothing to see with
>> what I was presented at first: this list is in *no* way for users to ask
>> for a change/enhancement to the devs!
> Right - we have few-to-no mechanisms for users to ask devs for things,
> beyond bugzilla and perhaps some user surveys if someone wants to put
> the work in to set these up. This is in large part because we have a
> factor of ~a million more users than developers. It is hard to think of
> a functioning system that can deal with 10^6 random conflicting opinions
> -per-developer- and filter them in a meaningful way.
>> It is all the way around: the devs are those asking for advice to
>> the world.
> Preferably not the world, but some known-sane-and-decisive UI /
> LibreOffice feature experts, like Astron, Christophe, Regina, and
As I understand from your words, here's part of the workflows:
users <-> [users lists] <-> "UI experts"
<-> community members
devs <-> [UX] <-> "UI experts"
designers <-> [design] <-> "UI experts"
(*) who? Are users listened at? On what criteria? Who are the designers?
What do they do with the lists discussions? What are their interactions
with the devs?
> If there are UI experts who have a view, they should be here, such that
> when people ask for advice they can give it.
Ok, that's neat. What makes someone a "UI expert"?
> Fine - please write up some new blurb for the list description, and/or
> edit the wiki where it refers to this to some new, more descriptive /
> balanced position.
Which page do you refer to (there are plenty ;)?
As for what's on the site/wiki (see copies below) I can tell that UX and
design are mixed up, which doesn't help a user's choice. Well, [UX]
remains quite hidden, though.
From what I read on the second page, I can't tell where User Experience
is dealt with: is it UX or is it Support and Training (as the helpdesk
personel has also a wide view of user experience)?
Also, I can find links from the Design pages that point to UX
(wikipedia). This doesn't help making sense and encourages coming to
[ux] while [design] is probably better suited. But I'm still unsure...
On this page: http://www.libreoffice.org/get-involved/
one can read
Do user experience [UX] and visual design: Design provides the visual
basis for any tool. In addition to the factual content, it is able to
transport usability, quality and emotions. The LibreOffice Design Team
dedicates its skills and creativity to improving LibreOffice by visual
means, inside the office suite, in user interaction and at any place
where the product, or the community behind it, is visible in public. Our
team consists of professionals and ambitious amateurs in several areas.
If you're interested, and want to share and improve your knowledge by
working collaboratively in an active and friendly team, join in.
And on that one:
If you're interested in user experience and visual design work, we'd
love to hear from you.
Primary points of contact and resources: the Design Team wiki page and
the Design mailing list.
LibreOffice aims to be a great tool for people to let them create, edit
and share any kind of information - to enable them to turn their ideas
into documents. But offering that much capability requires the software
to be easy and intuitive to use.
The LibreOffice Design Team wants to, "Make it just work, and look
great, too!" We set out to do this by offering user experience [UX]
design and visual identity design.
We need people to get involved in one or some of the following areas:
User experience: User experience considers the user's point of view
even before and also during the use of LibreOffice. It aims for
productivity, usability and enjoyment and targets both the LibreOffice
project's Web resources and the LibreOffice software. If you're
interested in or have expertise in research, design and evaluation
methods, we want to hear from you!
Visual identity design: Visual identity design is about creating
stunning artwork to be used in the LibreOffice productivity suite, in
the LibreOffice project's Web infrastructure, and in the LibreOffice
project's marketing material. It is also about improving the quality and
consistency of the visual branding language, which represents our whole
Accessibility: Accessibility is about making the software usable
for everyone: people with and people without special needs. To achieve
this challenging goal, we implement the laws and technologies that are
widely-recognized requisites in the field.
User support and training: This is about sharing your experience
when providing support and training for end users. It helps us identify
important areas for improvement and establish essential requirements.
Consequently, if you'd like to work on improvements that target both the
community and our large end-user base, then the Design Team is the right
place for you.
To contact the Design Team, please visit the Design Team wiki page and
sign-up for the Design mailing list.
>> Thanks again for answering and giving me a clearer view about UX. It's a
>> shame that those who participate (hey, Cedric!) are themselves directing
>> people here while we (I) should go elsewhere (ie, [design]). Then they
>> feel pissed off... Doh!
> I didn't read his mail; but I suggest that if a hacker has asked for
> input here, and there has been no negative feedback, and that decision
> is taken then he did 100% the right thing, and anything else is just
> time-wasting fluff. Possibly we'll revisit the decision in future.
> Certainly if there is concrete code, and someone making the status quo
> even better then we will.
Well... I *did* give input (see other thread) but this was quite badly
received. I was treated as a troll. I fail to understand what I did
wrong: was I impolite? harsh? did I call people names? I don't think so.
Feel free to tell me where my error(s) was/were as I like to learn from
bad experiences, just to avoid some more :)
>> PS: wrt the text boundaries thingy, do you know if that feature
>> discussed on [design]? If it was not, then we're in a catch 22.
> The hacker implementing this improvement would have asked for advice
> here first, at least that's the typical flow.
Seems ok to me.
> I see no catch 22 there.
Well, I do. When a dev gets a consensus here, I'd think he gets to
[design] and ask for validation. Or is there a brick wall between the
two lists? Otherwise, this would mean that design decisions are made
here by devs without refering to anyone in the Desing team.
> If you have a strong desire to see the code changed, then you need to
> jump in and change the code :-)
But no, it would take ages before I can get to the core and,
unfortunately, I haven't time enough. Like most of us here.
> it is not incredibly hard, given that
> the existing patch can be identified I suspect -but- it takes work:
> hacking is real work, and just talking about work takes time away from
> doing real hacking.
> Next time some sort of change happens in this area, I expect the same
> thing will happen, asking for advice here.
Meaning that if I want my ideas to spread, I should stay subscribed and
post when a question is asked.
> It is extremely easy to complain, and extremely painful
> and unpleasant to deal with those complaints.
<sigh> yes, I know.
To come back to the question that brought me in this list, ie the
(dreaded) text boundaries, I have a strange feeling that this is a
question I can't grasp.
Going to [design] is probably a long shot as any decision (if such would
be the case, dunno) would take ages to get to the devs. Asking here --
as I did, following some hints -- first is not the way things are
expected to happen and second, gets a "too late, my lad" answer as I was
informed *after* the discussion had taken place. Now, *this* is a catch-22.
Thanks again for reading this way too long message.
Jean-Francois Nifenecker, Bordeaux
More information about the Libreoffice-ux-advise