<div dir="ltr"><div><div>Hi guys,<br></div><div>I'd really like to get the process passed as official, put it on our wiki page, and encourage people to report UX bugs.<br></div>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.<br>
<br></div>(It will, of course, still be modifiable afterwards, but not as easily.)<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Sep 11, 2013 at 7:02 PM, Mirek M. <span dir="ltr"><<a href="mailto:mazelm@gmail.com" target="_blank">mazelm@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi guys,<br></div><div>I'd like there to be a clear step-by-step guide on how to report UX bugs.<br>
</div><div>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.<br>
</div><div>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 "G<span><span>ive non-printing characters a color different from the text</span></span>", 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.<br>
</div><div><br></div><div>As a start, I'd propose these guidelines:<br><br></div><div>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".</div>
<div><br></div><div><i>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:<br></i><br>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.<br>
</div><div><br>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 (<a href="https://wiki.documentfoundation.org/User:%5Byour" target="_blank">https://wiki.documentfoundation.org/User:[your</a> user name]) and provide a link to it in the comment instead.<br>
<br><br><br></div><div>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.<br>
<br></div><div>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.<br>
</div><div><br></div><div>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?<br>
<br><br></div><div>P.S. elementary's UX bug process is also worth a look: <a href="http://elementaryos.org/journal/so-you-fancy-yourself-a-designer" target="_blank">http://elementaryos.org/journal/so-you-fancy-yourself-a-designer</a></div>
<br>[1]<a href="http://www.superlectures.com/guadec2013/how-to-not-report-your-ux-bug" target="_blank"> http://www.superlectures.com/guadec2013/how-to-not-report-your-ux-bug</a><br>[2] <br><div>* What were you trying to do?<br>
</div><div>* Why did you want to do it?<br></div><div>* What did you do?<br></div><div>* What happened?<br></div><div>* What were your expectations?<br></div><div>* What are you running?<br>[3] <a href="https://www.libreoffice.org/get-help/bug/" target="_blank">https://www.libreoffice.org/get-help/bug/</a><br>
</div><div>[4] <a href="https://wiki.documentfoundation.org/Design/Principles" target="_blank">https://wiki.documentfoundation.org/Design/Principles</a><br>[5] <a href="https://wiki.documentfoundation.org/Design/Guidelines" target="_blank">https://wiki.documentfoundation.org/Design/Guidelines</a><br>
</div></div>
</blockquote></div><br></div>