Improving UX for bug reporting

[karlcow]

Extracted from a thread on compat mailing-list

---

For example, when we say "desktop site instead of mobile site", it's not clearly obvious what it means. Often it means I guess:
text/pictures looks very tiny on my mobile screen

For mobile, we often lack description and steps to reproduce. It probably can be understood because for two reasons:

1. Typing on mobile keyboard is cumbersome.
2. It's a long form instead of a step by step form (series of screens).

Maybe we should do stats 1st on what has been reported the ~2500 bugs and how.

For Desktop, we have more real estate screen and a real keyboard. It is probably easier for people to report issues with more details. I would discourage to hide some fields on desktop. For example, I usually report the bug for mobile on desktop, because it's just easier. I can have the mobile on the side and describe the steps instead of having to type on the mobile keyboard and/or memorize them. Also my github login is always here on desktop, but never on the mobile.

I would instead a multi-step, multi-screen reporting, something along

• Screen 1: Are you reporting an issue for a mobile, tablet, desktop, others [ ]
• Screen 2: We identified you are using this browser, screen size, etc.
  Is it the device you want to report the issue for.
• Screen 3: Type of issues + screenshot
• Screen 4: Steps to reproduce.

(Needs thinking, not necessary these screens, these wordings in this order, but you get the picture).

See for example https://www.virginamerica.com/book-travel
How the site propose different steps to accomplish the process.
Each screen being focused on 1 task, it becomes a lot clearer.

Or if we do a single form we need a way to make it more progressive, probably with a more vertical linear design with rewarding visual cues. We do visual cues for errors or missing info, but not that much rewarding. When the form has been completed something could appear on the page with love.

---

Then I have also seen this form, quite well done.
http://codepen.io/epilande/pen/eZJGpP

[magsout]

Totaly agree with you. When I reported mobile issue, I use my computer instead of my mobile, easier and faster. Steps like America is interesting. A page for a need,
1)website
2)main issue
3) behavior but with a list ? (
to avoid to write but leaves anyway this possibility)
4) screenshot
5) reported

[miketaylr]

Maybe we should do stats 1st on what has been reported the ~2500 bugs and how.

This could be very cool.

[karlcow]

@locketmm @zoepage to discuss about form redesign issues. This is the right place.

[lockettm]

@zoepage I like the idea of multi-step reporting and think it’s worth testing. It could prove to be less intimidating and may help users provide complete answers.

For “Screen 4: Steps to Reproduce” I’d alter the language on the current form. Maybe something along the following lines:

• What I did
  • Step 1) Go to: "Site URL"
  • Step 2)
• What I saw
• What I expected

[miketaylr]

It would be cool to A/B test a multi-step wizard and our current form to see if bug reporting quality improves. 👍

[zoepage]

== Form Design == We agreed that we need to improve the form. That probably means a simplification of the choices. Probably removing some of the options such as text visibility. The form was designed with a very strong mobile bias because it's where the majority of the issues is. We have also a thought about multi-screen process for filing the issues to make it less intimidating. The labels and instructions are probably too geeky and requires to be refined/simplified, for example "layout" is difficult to understand.

Problem Types:

Desktop site instead of mobile site
The Site is not usable
The Design is broken
Video or audio doesn't play
Something else

---

| 1 url
| 2 problem type
| 3 how did you get there? (str)
| 4 describe what was wrong
| 5 browser version (is this correct)
| 6 did you check in another browser?
| 7 screenshot

multicol view

1 5
2 6
3 7
4

<---- are the notes from our work week.

Very quick Mockup for desktop.

cc @karlcow @adamopenweb @miketaylr

[zoepage]

Mobile view

[zoepage]

Feedback from @adamopenweb && @miketaylr
Let's change How did you get there to Which steps did you take to get there?

[adamopenweb]

For Which steps did you take to get there? maybe the placeholder could mimic the format of steps we are looking for?
Something like: 1.Login 2.Click profile 3.Edit text

[caugner]

First of all, the mock up for the improved design is significantly better than the current form. I like it. 👍

Regarding Describe what was wrong? (versus Describe what behavior you see? and Describe what behavior you expect?) I could imagine that the quality regarding completeness sufficiency varies more due to the question being more open (referring to a diff between expected and actual behavior), but A/B could help to test this hypothesis.

Regarding Did you test in another browser? = Yes, the user could optionally provide information about which browsers were tested with what result, e.g. lines (similar to Is this information correct?) that allow selecting a browser name, a version ("Current version", "Pre-release version", "Long-term-supported version") and a toggle button Works (green check mark) / Same issue (red cross).

Regarding Is this information correct?, logos might contribute to making the form look less "scary".

Similarly, iconic symbols for the issue types might enable users to make a choice faster, reducing the barrier for users to submit an issue.

I notice that the form mentions two words (bug and issue) for the same thing, which might confuse users. Why not Report issue or even Report problem (which might be more suitable for non-natives)?

Also, is the word describe used intentionally?

• Describe what was wrong? vs. What was wrong?
• Describe how you get there? vs. How did you get there?

Last but not least, more specific incomplete labels (incomplete-problem-description vs. incomplete-reproduction-description) in triaging might help providing more concise measures for A/B efforts.

[karlcow]

Found again one of the articles I was looking for
http://tomkenny.design/reviews/learn-from-great-design-virgin-america/

[karlcow]

and probably https://www.smashingmagazine.com/2015/11/airline-websites-2015-front-end-performance-ux-lessons-learned/

[karlcow]

There is work going on by the innovation team about this in.
Mobile: https://miro.com/app/board/o9J_kxX9vL0=/
and Desktop: https://miro.com/app/board/o9J_kxWDuVE=/

[karlcow]

To give a bit more context. There's a project to A/B test, these new possible forms.

[karlcow]

This was addressed in https://github.com/webcompat/webcompat.com/projects/6