[Libreoffice-qa] UX bug process

[Mirek M.]

It's official then: https://wiki.documentfoundation.org/Design


On Sat, Sep 28, 2013 at 10:59 PM, Mirek M. <mazelm at gmail.com> 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. <mazelm at gmail.com> 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
>> happened.
>>
>> 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 (https://wiki.documentfoundation.org/User:[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:
>> http://elementaryos.org/journal/so-you-fancy-yourself-a-designer
>>
>> [1] http://www.superlectures.com/guadec2013/how-to-not-report-your-ux-bug
>> [2]
>> * 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?
>> [3] https://www.libreoffice.org/get-help/bug/
>> [4] https://wiki.documentfoundation.org/Design/Principles
>> [5] https://wiki.documentfoundation.org/Design/Guidelines
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/libreoffice-qa/attachments/20131012/a3feeea5/attachment.html>