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


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

Context


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.