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

Hi Loic,

thanks for your answer - it already clarifies lots of my questions ...

Am Freitag, den 09.09.2011, 09:44 +0200 schrieb Loic Dachary:

I would like to emphasize that I'm a developer with little insight
with regard to useability. It's a handicap shared by many developers
and I came to acknowledge it over the years.

Then I emphasize that I lack the skills for developing the software ...
that should be a basis for a very good partnership :-)

Your mail was my first inspiration when I picked up where Daniel Neel
left, back in february
( ). I'm now trying 
to mix your vision with the one provided by Rainer Bielefeld and Michael Meeks ( which are listed 
with yours at ).

Thank you very much for the link ... today I was able to spend some time
reading your page (very good overview, btw) and the document by Michael.
I think I've got the main idea for this activity (please correct me if
I'm wrong): It is less about simplifying reporting bugs for everyone,
but it is about ...
      * to improve the quality of the initially provided information in
        the bug by providing guidance and automating e.g. LibO version
      * some decoupling from the Freedesktop issue tracker which has
        also to suit the needs for many other projects
      * easing the way to report bugs in general (people should not
        search for a bug tracker)

I'd say this addresses more experienced people - the minority of our
user base (referring to the whole user base, not the community we know).
Since we offer that feature for all people in LibO, some of them will
get worried ... so there is a need to offer them alternatives (get help,
provide feedback). That's something I've tried to summarize here:

Furthermore, it would allow us to get all kind of feedback by users,
e.g. the surveys Bjoern analyses at the moment (see [1]).

What do you think?

@ Rainer: I should have been aware of this activity, but I've missed
your comment in issue 35855 - I was not on CC, grrr.

It would greatly help if I had a bullet list of what should be
implemented ( a proper specification is probably overkill, but details
would be appreciated ). If there is a consensus on the priorities, it
would help my technical work a great deal. I understand, however, that
such research takes time and that you are all very busy. This is the
reason why I went for a minimal implementation with what I believed to
be the parts everyone agrees on.

Concerning the latter: great approach!

In general, I'm happy to help, since this topic has been discussed so
often in the past (I remember a heated discussion at the OOoCon 2010).
But it will need two or three days to come up with anything from my
side ... I hope that's acceptable. Or, maybe somebody from the Design
team can jump in as well?

Some things I'm currently unsure about is the terminology we use ... if
we try to guide any type of users, then some "technical terms" should be
avoided (for LibO / the initial website). I propose to use "problem"
instead of "bug/issue".


My focus is to make it easier for someone who reports a bug for the
second time and to improve the quality of the bug report by making
sure the essential fields are filled in. The first time someone
reports a bug, (s)he will need to register a bugzilla account which is
difficult and there is no way around it.

Okay - that's very important for me, being aware of that. Thanks.

If we consider "normal users", then e.g. the component selection is
still very difficult to understand. 
Michael Meeks has a proposal regarding this aspect ( in
 ). If I had the required graphical elements, I could integrate them into the page. Do you know 
where I could find an image/icon for each components listed at ?

Just tell me the rough size (available: 256,128,48,32,16 px) of the
graphics you need ... I'll export them for you. Here is the page where
we've listed the LibO specific icons:

Mmh, the components list doesn't match exactly the components we use in
LibO. So either:
      * we list only the main components (Writer, Calc, ...)
      * we show the main components prominently and provide a further
        list (e.g. UI, Linguistic component) --> my current favorite
      * we borrow some icons from the LibO UI

And, there might be a need to hide some of them, e.g. "WWW" - but I'm
not sure at the moment.

If it turns out to be redundant, I would appreciate to know as soon as
possible ;-) I will keep going anyway, but I must confess that I'm
worried now.

Oh please, don't! Most important for us is to know what shall be
achieved ... knowing that makes things much easier. Knowing that we
target advanced users is fine, but we need to think about the other
users as well (not necessarily milestone 0.1, but something for 0.3
would be great).

Finally, thanks for your explanations and your work on that! I hope this
mail helped to clarify my point-of-view a bit ...



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.