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. <maz...@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 > -- To unsubscribe e-mail to: design+unsubscr...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/design/ All messages sent to this list will be publicly archived and cannot be deleted
