[ForumUX] Change 'Select purpose of your response' from listbox to radio buttons



9 years ago
8 years ago


(Reporter: Noah, Assigned: paulc)


Dependency tree / graph
Bug Flags:
in-litmus +

Firefox Tracking Flags

(Not tracked)


(Whiteboard: sumo_only)


(4 attachments, 1 obsolete attachment)



9 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090420 Firefox/3.0
Build Identifier: 

I believe this would be much easier than the drop down list, 1 click opposed to click, scroll, click. As it has been bugging me from the start of my tenure on the SUMO forums. I should of filed long ago, so I only have myself to blame. :P

Reproducible: Always

Comment 1

9 years ago
Could you show a mockup of how this would look like?
We can make it look however we want if we decide this is the correct mechanism for this choice instead of a drop down. Here's my reasoning for making this change, pasted from my newsgroup post:

Speaking from my own personal experiences I still have to very adamantly say that the drop down is the wrong mechanism for this action. It may make sense from "how to build a form" but it doesn't fit with the experience of someone
filling out a thread.

Here's how I see this experience:

1. I find a thread that I have something to say about
2. I look for a mechanism to leave that comment - I expect a button, or a text box.
3. I look for the mechanism to submit my feedback - I expect a button in doing 3 I may notice
4. Am I logged in, or do I need to provide my username and fill out a captcha
I then go back to 3, or if i had to fill out info it becomes another step
5. Submit my post

The current result of that is I don't see the drop down (and I know it's
there!) and don't choose it.

 Setting a default option will only create the experience that all my posts
will have that status.  Fwiw I find I post most frequently with a solution
(which isn't a good default option) or I'm asking for more info (which means
that a good chunk of the time any default option will be wrong).

Making the dropdown have no default value and making it a required field is
going to add steps:
6. Submit fails and I'm redirected back to my post
7. Find the missing info, fill it in. This will most likely also result in
having to refill the captcha.
8. Submit the information again.

I really believe the right way to handle this is in steps 1 and 3 where we
can present a choice without creating another step.  Especially in the case
of someone who is having the same problem, there is no value in having them
follow all 5 to 8 steps when we don't even *want* them to post in the

Step 1 should be a choice between "I'm having this problem, too" and "I
think I can help."  Not only does this improve the user experience, it
should have a real impact on making the stats a lot more accurate. This can
be done by presenting buttons that a user has to click before the post field
shows up or it can be done like "Get satisfaction" by having a big "I'm
having this problem, too" button somewhere before the option to reply. On GS
it's in the original post.

The next step then is how to differentiate "I think I can help" between "I
need more information to help you" and "I think this answers your question"
Again, my problem with using a dropdown here, is that it's not a choice a
user expects to have to make, and they can't anticipate what the choices
will be.  Dropdowns are great for choosing location eg because the user
knows before they click on the dropdown which option they'll be looking for.
I think the better implementation for the user is to use radio buttons or
regular buttons because this lets the user see the options and the user can
see clearly that they need to make a choice.

Comment 3

9 years ago
Agreed that switching to radio buttons will make it more discoverable. Let's think about how this would look like. I think we need clear descriptions about the selected option, so rather than just switching to radio buttons, I'd like it to become clearer in general what the options are about. Something like:

Select purpose of post:
( ) Proposing a solution to the problem
( ) Asking for more info that is needed to solve the problem
( ) None of the above 

Noah, if you want to provide a mockup of the above, or what you had in mind, that'd be useful.


The "Me too" button is something we've been thinking about too, but that's out of scope for this bug (and would require db changes to track the "me too" count). Someone feel free to file a separate bug for it.

Another thing to consider is that we'll probably need an option for non-Firefox problems. That's also out of scope for this bug, but something to think about. Would be nice with a drop-down button saying "This is not a Firefox support question" with a menu showing options like "Thunderbird" "Other" etc. When selecting an option, a canned response could be inserted and the status would obviously be different. When posting, the thread would automatically be closed/resolved/locked. But how would this whole UI fit together? I don't know yet.

Comment 4

9 years ago
Created attachment 393703 [details]
Radio buttons mockup

Sorry it took me forever to make one. :P

This is what I was thinking. Also I'd like it if clicking any of the radio button words (Neither, Possible solution, etc) also acted the same as clicking the radio button itself. That way one does not need to click exactly in the radio button everytime.

Comment 5

9 years ago
The invalid (not firefox) is bug 501883
Ever confirmed: true
Summary: Change 'Select purpose of your response' from listbox to radio buttons → [ForumUX] Change 'Select purpose of your response' from listbox to radio buttons
Target Milestone: --- → 1.4
I would do them top down, not side to side.  Don't forget there is also the logged out view.

Attach a screenshot should probably be directly below the text area.

In terms of placement, I would actually get rid of "Posting replies" and put them there. The note about html tags not being valid should stay, but that should go under the textbox or above it. Perhaps lengthen it "Posts are formatted using Tikiwiki markup. HTML tags are not allowed" with a link to a tiki markup chart.

I'm not handy enough with Firebug to move this around for a screenshot.

Comment 7

9 years ago
Neil, what's your take on this?
Assignee: nobody → neilio
Priority: -- → P4
Whiteboard: needs ui

Comment 8

9 years ago
I need some context here - where does this appear? The label in the mockup doesn't really provide enough information for me to know where this appears and what it's for.

Comment 9

9 years ago
Neilio: when posting a reply on a forum thread.
No patch = 1.4.1
Target Milestone: 1.4 → 1.4.1

Comment 11

9 years ago
Anything on this Neil?

We're talking about changing the <select> at http://support.mozilla.com/en-US/forum/1/453722#forumpostopen prefixed by "Select purpose" to radio buttons.
Hardware: x86 → All


9 years ago
Priority: P4 → --

Comment 12

9 years ago
I'm all for switching to radio buttons in general - select menus tend to be the most complex form widget for users to manipulate.

I think the radio button alignment needs a bit of tweaking - they should be left-aligned and vertically stacked, like:

Flag your response:    [] Request more information
                       [] Proposed solution

This form in general needs some tidying - when I get into the office I'll attach a quick wireframe with a cleaned up layout.
Sounds great - thanks Neil!
See also comment 3 regarding wording.

Comment 15

9 years ago
Created attachment 403945 [details]
Default state of "reply" area, before a radio button has been selected

I did a full rejig of the layout of this area, but the way I've done it we can implement this in two stages. The select menu can be swapped out with these as a first step.

The way I see this working ultimately is that this (the headline and the radio buttons) is the default state for the "Add a reply" area. Once the user selects a radio button one of two things happens:

1. If they select "I need help with a different issue" a link appears directly beside this text with "Ask a new question". When the user clicks on this. the "ask a question" modal window appears, funneling the user into that process.

2. If any of the other radio buttons are pressed, the full reply form appears - see the next wireframe.

Comment 16

9 years ago
Created attachment 403947 [details]
Expanded reply form with all of the fields visible.

This form appears once the user has selected one of the radio buttons that categorizes their response.
I don't think we should say "different issue" or we won't weed out the "me too" posts. "I need help" or "I need help, too" should be fine for the purpose of the option.

Comment 18

9 years ago
Not sure how I feel about that "different issue" option. I honestly think people can just learn to not post off-topic. And if they're going to do it anyway, we have the "Detach post" option. Cww, what do you think?

Comment 19

9 years ago
Yeah, I was trying to address the paragraph that leads the top of the current form - I doubt most people read that.

Maybe we could remove that option and instead have a link just underneath "None of the above" that says, "Have a different problem? [Ask a new question]".
Priority: -- → P4
Target Milestone: 1.4.1 → 1.4.2
* I agree with others that having a radio option for separate issues isn't necessary but I think Neil's proposal in comment 19 is good, and I would suggest it is placed above the "post subject".

* We've been talking about adding a "me too" option before, and I think that would be very nice to have since that would make the weekly specific issues metrics more useful (instead of just counting threads with specific issues, we would also include the "me too" count). For this option, I would propose something like "I have the [b]same problem[/b]"

Proposed layout would then be:


Have a different problem? [Ask a new question.]

Select a post subject
* I want to [b]suggest a solution[/b] to this problem
* I want to [b]ask for more information[/b] about this problem
* I have the [b]same problem[/b]
* None of the above

For this specific bug, we could leave the "me too" option out and file a separate bug for that.

Comment 21

9 years ago
Created attachment 405004 [details] [diff] [review]

Thanks David. Here's a first iteration:
* rewrites the "Purpose of response" to be similar to mockup (list of radios)
* rephrases the hints for "Adding links"
* resizes the editor area and styles it a bit
* removes the showCaptcha function which seems bad for usability (not a must-have for this patch, but it shouldn't cause problems)

These values should be set on :
Special forum thread status labels (comma-separated):
I have the <b>same problem</b>,I want to <b>suggest a solution</b> to this problem,I want to <b>ask for more information</b> about this problem,None of the above
Special forum thread status values (comma-separated, single character, cannot be n, a, h, s, o, or l):

Note that the order matters for which overrides which. We should either have "me too" not overwrite, or be the first (chosen above).
Assignee: neilio → paulc
Attachment #405004 - Flags: review?(james)
I smell BFT needs here. :)

We need to make sure that a "me too" post doesn't update the status if someone else previously posted a "proposed solution". Essentially, a "me too" post should be treated as a "none of the above" post in most every sense. The only difference would be the count that allows us to get better forum metrics about common issues (aside from the more social way for people to indicate that they're having the same issue). 

One thing to consider for the future: if the original reporter signed up to get an email notification when someone answers, should we really email notifications when someone submits a "me too" post? Maybe, maybe not.

Comment 23

9 years ago
I believe with the above patch, the status changes only if it was previously "n" (normal). We should definitely have a testcase for this whole thing though!
Keywords: testcase-wanted
Whiteboard: needs ui → needs ui
Keywords: testcase-wanted
Whiteboard: needs ui → needs ui, needs litmus
Comment on attachment 405004 [details] [diff] [review]

Without the showCaptcha() function, there's no captcha, so you can't post if you're not logged in. I agree that the current implementation is problematic--but maybe the captcha should just be there onload?
Attachment #405004 - Flags: review?(james) → review-

Comment 25

9 years ago
Created attachment 407457 [details] [diff] [review]

Well. I thought I had removed showCaptcha() and made the captcha show by default, but I guess I forgot. Now should be better :)
Attachment #405004 - Attachment is obsolete: true
Attachment #407457 - Flags: review?(james)
Comment on attachment 407457 [details] [diff] [review]

Now it's working great, and solves bug 523509.
Attachment #407457 - Flags: review?(james) → review+

Comment 27

8 years ago
r54005 (trunk)
I've also updated the preferences on stage, as per comment 21. We will need to change these on prod too (added changepref to whiteboard).

Seems to be working fine, yay!
Last Resolved: 8 years ago
Resolution: --- → FIXED
Whiteboard: needs ui, needs litmus → needs litmus, changepref


8 years ago
Duplicate of this bug: 488724
Flags: in-litmus?
Whiteboard: needs litmus, changepref → changepref


8 years ago
Whiteboard: changepref → changepref (see comment 21 for prod changes)
Verified, FIXED.
"Special forum thread status labels (comma-separated)" is now set on prod to:
I have the <b>same problem</b>,I want to <b>suggest a solution</b> to this problem,I want to <b>ask for more information</b> about this problem,None of the above

"Special forum thread status values (comma-separated, single character, cannot be n, a, h, s, o, or l)" is not set on prod to:
Whiteboard: changepref (see comment 21 for prod changes) → sumo_only
Litmus test- https://litmus.mozilla.org/show_test.cgi?id=9840
Flags: in-litmus? → in-litmus+
You need to log in before you can comment on or make changes to this bug.