[Libreoffice-ux-advise] ux-advise advice

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

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"
others(*) <->

(*) 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
8< ------------------------------
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.
------------------------------ >8

And on that one: 
http://www.libreoffice.org/get-involved/ux-visual-designers/
we read
8< ------------------------------
UX/Visual Designers
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 
community.
     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.
------------------------------ >8

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

Thanks ;)
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.

BTDTGTTS ;)

>
> 	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.
Best regards,
-- 
Jean-Francois Nifenecker, Bordeaux