[meta] Improve feedback form to let users submit comments more freely

RESOLVED FIXED

Status

defect
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: cww, Unassigned)

Tracking

unspecified
x86
All
Points:
---
Dependency tree / graph
Bug Flags:
qe-verify -

Firefox Tracking Flags

(firefox36-)

Details

Attachments

(1 attachment)

Reporter

Description

5 years ago
When providing feedback, we are only allowing users to provide details when they select "Other". When reading through "other" feedback, it's clear that people are often selecting it just so they can give us more details on another category.

We should just leave the text box available all the time and submit its contents when submitting feedback even if the user doesn't select "Other".
Fair point.
Hopefully there is a way to do that without adding new strings.
Please check out the attached and let me know what you think.

Please also confirm input.mozilla.org can support it (effectively a user could attach a comment to any category or no category at all if no option is selected and text is just entered).

I also NI Darrin and Matej to validate we can do it in Fx35 (I don't think it impacts the strings we already agreed on but seeking validation) and that there are no UX sensitivities.
Blocks: 1074659
Flags: needinfo?(dhenein)
Flags: needinfo?(Mnovak)
Whiteboard: [rooms]
Target Milestone: --- → mozilla35
This seems reasonable, no objections from me.
Flags: needinfo?(dhenein)
Looping in Will. Can you confirm Romain's question in Comment 1?
Flags: needinfo?(willkg)
Is this part of Hello? It's the first time I'm seeing these strings.

Really it feels like the question should be "What made you sad?" ("What makes you sad?" sounds awfully existential.)

Also, "Confusing" is confusing in itself. It should be something like "Confusing controls."

Is it possible to make those updates?
Flags: needinfo?(Mnovak)
> (effectively a user could attach a comment to any category or no category 
> at all if no option is selected and text is just entered).

That should be fine in input.
Flags: needinfo?(willkg)
(In reply to Matej Novak [:matej] from comment #5)
> Is this part of Hello? It's the first time I'm seeing these strings.
> 
Yes it is part of Hello, these strings are not new ones for Fx35, they are in Fx34 already.

> Really it feels like the question should be "What made you sad?" ("What
> makes you sad?" sounds awfully existential.)
> 
> Also, "Confusing" is confusing in itself. It should be something like
> "Confusing controls."
> 
> Is it possible to make those updates?
I agree with your suggested changes. Shell is this something possible to amend in Fx35?
Flags: needinfo?(sescalante)
35 is string frozen. We can change them on the standalone UI (and for 36 & onwards).
Let's definitely make these changes, then. I didn't see this as part of the string creation and review I did. As it is, the language isn't ideal and not in line with the rest of the copy.
Depends on: 1079225
Depends on: 1079227
(In reply to Matej Novak [:matej] from comment #9)
> Let's definitely make these changes, then. I didn't see this as part of the
> string creation and review I did. As it is, the language isn't ideal and not
> in line with the rest of the copy.

I renamed this bug to become a meta for optimization of the feedback form
Bug 1079216 created to track standalone link clicker UI string changes.
Bug 1079225 created to track standalone link clicker UI feedback form changes.
Bug 1079227 created to track desktop client UI feedback form changes.
No longer depends on: 1079225, 1079227
Flags: needinfo?(sescalante)
Summary: Keep text box and submit contents when submitting feedback → [meta] Improve feedback form to let users submit comments more freely
Depends on: 1086237
Target Milestone: mozilla35 → ---
backlog: --- → -
Reporter

Comment 11

5 years ago
Wait, why does this depend on bug 1086237? This is a completely different thing, we don't need to collect metadata to make this work. Input already supports this just fine.
Flags: needinfo?(rtestard)
Reporter

Comment 12

5 years ago
Also, we had a conversation this morning about what kind of feedback would be most useful for general release and it seemed that this was going to be on the list for Firefox 35 beta so we could provide useful insights about what is causing user pain. I'm surprised that this got marked as not blocking given that we just discussed this less than 6 hours ago.
We didn't have "backlog" for blocking-loop until this morning, so "-" indicated the backlog.  

Do we need to target Fx35 for this?
backlog: - → backlog
Flags: needinfo?(cwwmozilla)
Reporter

Comment 14

5 years ago
Decision ultimately rests with a product manager. Generally, you want to have feedback almost fully working as soon as you make a big push for users (or before) if you want to capture first impressions and discover places where poor experiences may turn users away from the product. 

This feature (and the other feedback related features that were similarly pushed back) are going to allow us to make much better use of feedback and convert it more easily to actionable items such as bug reports and prioritizations. Otherwise, you're going to just get info like 15% of users find the UI confusing without any info about what is confusing and what they expect.
Flags: needinfo?(cwwmozilla)
(In reply to [:Cww] from comment #11)
> Wait, why does this depend on bug 1086237? This is a completely different
> thing, we don't need to collect metadata to make this work. Input already
> supports this just fine.

You're right, dependency removed.
No longer depends on: 1086237
Flags: needinfo?(rtestard)
(In reply to [:Cww] from comment #14)
> Decision ultimately rests with a product manager. Generally, you want to
> have feedback almost fully working as soon as you make a big push for users
> (or before) if you want to capture first impressions and discover places
> where poor experiences may turn users away from the product. 
> 
> This feature (and the other feedback related features that were similarly
> pushed back) are going to allow us to make much better use of feedback and
> convert it more easily to actionable items such as bug reports and
> prioritizations. Otherwise, you're going to just get info like 15% of users
> find the UI confusing without any info about what is confusing and what they
> expect.

I discussed this with Shell yesterday and yes we want it for Fx35 as it's key to collect better user feedback.
Ok, we'll want to re-triage Fx35 bugs on Monday (Shell has it scheduled for 10am Pacific on Monday) to make sure this can get in.
backlog: backlog → Fx35?
No longer blocks: 1074659
Whiteboard: [rooms]

Updated

5 years ago
backlog: Fx35? → Fx35+
Priority: -- → P3
Note: we should not clear the text field when the user selects a different option.
Duplicate of this bug: 1088884

Updated

5 years ago
Priority: P3 → P2

Comment 20

5 years ago
just validating as we looked at the UX - it's clear that we want the open feedback to go with any radial button selection. Did you mean to get rid of the "other" option, in case the feedback wasn't on one of those listed areas?
Flags: needinfo?(rtestard)
Reporter

Comment 21

5 years ago
No, let's leave the Other category as well.
Agreed
Flags: needinfo?(rtestard)

Updated

5 years ago
backlog: Fx35+ → Fx36+
Priority: P2 → P1
[Tracking Requested - why for this release]:
For reporting reasons, we'd like to improve this for Fx36.
Not tracking. We won't block the release for this but we could take a patch during the aurora cycle (don't forget that we freeze string in beta).
Unmarking this since this is a meta.
backlog: Fx36+ → ---
Priority: P1 → --
(In reply to Maire Reavy [:mreavy] (Plz needinfo me) from comment #25)
> Unmarking this since this is a meta.

Should bug 1088884 be un-duped, then? That's a pretty annoying bug, when it happens (and is not a metabug), and it was duped here.
(Its STR do match comment 0 here, but it seems this bug was directed away from that specific issue in comment 10.)
[needinfo=Romain to reply to comment 26, since he did the duping & conversion-to-metabug. Roman, do you know if the issue described in bug 1088884 is tracked anywhere?]
Flags: needinfo?(rtestard)
(In reply to Daniel Holbert [:dholbert] from comment #28)
> [needinfo=Romain to reply to comment 26, since he did the duping &
> conversion-to-metabug. Roman, do you know if the issue described in bug
> 1088884 is tracked anywhere?]

It should have been tracked on bug 1079227 which changes the way the free text field is handled (free text field allowed with any selected option).
I has although been marked as dupe of this bug. I'll go ahead and re-open 1079227 and make it clear that the text field should not be cleared if text is entered and then another option gets selected.
Flags: needinfo?(rtestard)
Depends on: 1113540

Updated

5 years ago
backlog: --- → -
We've now fixed all the bugs this depends on, hence marking as fixed.
Status: NEW → RESOLVED
Closed: 5 years ago
Flags: qe-verify-
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.