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

It's official then:

On Sat, Sep 28, 2013 at 10:59 PM, Mirek M. <> wrote:

Hi guys,
I'd really like to get the process passed as official, put it on our wiki
page, and encourage people to report UX bugs.
Since none of you replied to the original message, please give input
before next Saturday 17:00 UTC. If nobody has any problems with it by then,
I'll just pass it off as official.

(It will, of course, still be modifiable afterwards, but not as easily.)

On Wed, Sep 11, 2013 at 7:02 PM, Mirek M. <> wrote:

Hi guys,
I'd like there to be a clear step-by-step guide on how to report UX bugs.
Unfortunately, I don't really know how to report these bugs myself, so
I'd like to work with all of you to devise a clear process.
Fabiana Simoes lays out the ground rules in her "How to not report your
UX bug" GUADEC talk [1]. Her presentation talks about how UX bugs should
center on a problem rather than on a proposed solution. To give a real-life
example, the summary of a UX bug should be "Non-printing Characters are Not
Set Apart from Text" rather than "Give non-printing characters a color
different from the text", as the former describes the problem,
encourages discussion around the best solution, and makes the reasoning
behind the picked solution clear, whereas the latter proposes a solution
right away without questioning if it is the best solution.

As a start, I'd propose these guidelines:

1) In the Summary/Subject field, describe the problem, not the solution.
Rather than saying "X should be Y", say "I can't figure out how to X" or "I
expected X, but Y happened".

*The pieces of information that Fabiana says a user should provide [2]
are basically covered by the Bug submission assistant [3], but should be
mentioned in the guidelines nevertheless:
2) In the Description, mention what you were trying to accomplish, how
you tried to accomplish it, what you expected to happen, and what actually

3) In an additional comment, feel free to propose a solution. If your
proposal is long or includes mockups, put it on your user page on the TDF
wiki ([your user name]) and
provide a link to it in the comment instead.

In regard to Whiteboards, the design team may decide to make one for a
bug, but I'd rather leave them out of the guidelines, as I don't want to
see a load of whiteboards being created without approval.

The solution should be agreed upon based on discussions in the bug
comments, on the design list, and on our IRC chats (all of which should be
linked to in the bug comments), using our UX principles [4] and guidelines
[5] to resolve controversies.

I'd also like to ask: What is the role of the ux-advise mailing list? Is
it a place for devs to ask designers for UX help or a place where designers
and devs can ask each other questions? When should a bug be tagged
"ux-advise"? Is it a component that should be used for all UX/UI bugs, both
confirmed and unconfirmed, until a solution is agreed upon?

P.S. elementary's UX bug process is also worth a look:

* What were you trying to do?
* Why did you want to do it?
* What did you do?
* What happened?
* What were your expectations?
* What are you running?

To unsubscribe 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.