Standalone UI for link clickers needs to provide simple feedback at the end of a call.

RESOLVED FIXED in Firefox 34

Status

defect
P1
normal
RESOLVED FIXED
6 years ago
5 years ago

People

(Reporter: standard8, Unassigned)

Tracking

unspecified
mozilla35
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +
in-moztrap +
qe-verify -

Firefox Tracking Flags

(firefox34 fixed, firefox35 fixed)

Details

(Whiteboard: [p=1][standalone-uplift], )

User Story

As a WebRTC browser URL clicker but not on Firefox in a call, I get prompted to provide feedback at the end of a call so that I can let the product owner know how I feel about it.

Attachments

(2 attachments, 4 obsolete attachments)

Simpler version of bug 972992 for MLP
Blocks: 972024, 974875
No longer blocks: loop_mlp
Mark -- I'm assigning this to you as part of bug 972024 (and bug 974875).  Thanks.
Assignee: nobody → standard8
Whiteboard: [est: 1d, assuming simple form/service]
Priority: -- → P3
Priority: P3 → P4
Blocks: 994274, 972014
No longer blocks: 972024, 974875
We want to do this soon after MLP.
Whiteboard: [est: 1d, assuming simple form/service] → [est: 1d, assuming simple form/service][feedback]
Assignee: standard8 → nobody
No longer blocks: 972014
User Story: (updated)
Summary: Provide simple feedback at the end of a call via third-party service → Standalone UI for link clickers needs UI to provide simple feedback at the end of a call.
this was triaged a high priority for desktop client for our early testing so we could get feedback internally on issues quickly - web client had matching priority because Darrin said would likely be developing in tandem.
Priority: P4 → P1
Whiteboard: [est: 1d, assuming simple form/service][feedback] → [est: 1d, p=1, s=ui32, assuming simple form/service][feedback]
Target Milestone: --- → mozilla32
Priority: P1 → P2
Whiteboard: [est: 1d, p=1, s=ui32, assuming simple form/service][feedback] → [est: 1d, p=1, assuming simple form/service][feedback]
Target Milestone: mozilla32 → mozilla33
Summary: Standalone UI for link clickers needs UI to provide simple feedback at the end of a call. → Standalone UI for link clickers needs to provide simple feedback at the end of a call.
Priority: P2 → P1
Whiteboard: [est: 1d, p=1, assuming simple form/service][feedback] → [est: p=1, assuming simple form/service][feedback]
fastest to get in would be google form - OK from teams.  low input from UI.
there's a link to what Talkilla used - need Romain and Shell and ? to discuss if we want to change the form and to gather what additional information.
Flags: needinfo?(sescalante)
Flags: needinfo?(rtestard)
This is an example of what could be done.
https://docs.google.com/a/mozilla.com/forms/d/1KSr1Zy5SupSxXk-6JE2x3pzRulrd4wo6jbcgCvC3rC0/edit#

Darrin what do you think?
Flags: needinfo?(rtestard) → needinfo?(dhenein)
Copying comment from Bug 1003180

We want an experience integrated into the client UX so that at the end of a call the conversation window prompts the user to provide feedback. This is optional for the user.
I discussed with Darrin who will provide UX.

The UX I proposed:
Screen with Happy or Sad displayed at the end of the call in the conversation window
    If happy clicked, thank the user for the feedback and close conversation window
    If Sad clicked display another screen: "What makes you sad? []Bad audio [] Bad Video []Got disconnected []Horrible UI []Other with text field

This although requires server back-end to store the data and I'd like to understand if this is technically complex or not. We will require this back-end also for the mobile application which can't nicely display a Google form on mobile form factor.

If this is likely to take time to implement this, an intermediary step could be to display a link to a Google form at the end of the call in the convresation window, when the user clicks it a new tab with the form opens. An example of the form is: 
https://docs.google.com/forms/d/1KSr1Zy5SupSxXk-6JE2x3pzRulrd4wo6jbcgCvC3rC0/viewform

I needinfo Mark for comments on whether we have a simple way to store that data which should help understand if we need the intermediate Google form step.
This bug is about allowing a Web  UI clicker to provide feedback at the end of a call.
Similarly to the desktop client UI, the user should display:
A screen with Happy or Sad displayed at the end of the call
    If happy clicked, thank the user for the feedback and close feedback form
    If Sad clicked display another screen: "What makes you sad? []Bad audio [] Bad Video []Got disconnected []Horrible UI []Other with text field

If this is likely to take time to implement this, an intermediary step could be to display a link to a Google form at the end of the call. An example of the form is: 
https://docs.google.com/forms/d/1KSr1Zy5SupSxXk-6JE2x3pzRulrd4wo6jbcgCvC3rC0/viewform
Depends on: 1024568
Feedback from Darrin through e-mail:

I think one thing I would add is that we should consider the wording of the feedback options. Madhava and I were looking at them and thought something simpler like “What makes you sad?” and the options:

    Audio Quality
    Video Quality
    Was Disconnected
    Confusing
    Other (w/ text field)

I don’t think users are going to know what UI means (let alone Horrible UI!), or how/whether it was the source of their poor experience.
Blocks: 1003180
Assignee: nobody → dhenein
Status: NEW → ASSIGNED
Whiteboard: [est: p=1, assuming simple form/service][feedback] → [assuming simple form/service][feedback] p=1 s=33.3 [qa-]
No longer blocks: 1003180
Blocks: 1036882
No longer blocks: 994274
After discussions with Darrin, we'll skip the call terminated screen (https://bugzilla.mozilla.org/show_bug.cgi?id=1000259) and implement only this user feedback screen with a call back button along side the report user button. 

This is pending UX amendment from Darrin.
Blocks: 1039962
The re-dial feature part of the user feedback screen is now tracked on https://bugzilla.mozilla.org/show_bug.cgi?id=1039962
Darrin updated UI: https://people.mozilla.org/~dhenein/labs/loop-link-spec/#call-terminated
Assignee: dhenein → nobody
Flags: needinfo?(sescalante)
Whiteboard: [assuming simple form/service][feedback] p=1 s=33.3 [qa-] → p=1 [qa-]
Posted audio Call Ended.mp3
Initial sound file which may change later.
Whiteboard: p=1 [qa-] → [p=1, qa-]
Depends on: 1041439
Assignee: nobody → dmose
Target Milestone: mozilla33 → 34 Sprint 1- 8/4
We're looking at using input.mozilla.org as a place to store the feedback data.

We'll implement the "report user" feature post landing of the feedback form.
When landing the "report user" feature this will probably leverage some client logic to ensure the feedback and "report user" data get stored in a separate place (the "report user" data is anyway subject to data retention policies of 2 years so we'll have to find an appropriate place for this).

So this bug tracks the implementation of the feedback form for the following fields in the link clicker UI (wording as per latest UX available on [1]):
* Happy or Sad face clicked
* If Sad face clicked add some details:
[] Audio quality
[] Video quality 
[] Was disconnected 
[] Confusing
[] Other with text field

Please note that a desktop client UI bug tracks the feedback form implementation - https://bugzilla.mozilla.org/show_bug.cgi?id=1003180 where I added a similar comment.

Matt, can you please provide details regarding how we can integrate with input.mozilla.org for this?

[1]
https://people.mozilla.org/~dhenein/labs/loop-link-spec/#call-terminated
Note: click happy and sad faces to see the flow.
Flags: needinfo?(mgrimes)
Thanks for the info on abuse. Please include me in those conversations as well as Patrick McClard. I'm adding Willkg for Input API details.
Flags: needinfo?(mgrimes) → needinfo?(willkg)
(In reply to Romain Testard [:RT] from comment #15)

> https://people.mozilla.org/~dhenein/labs/loop-link-spec/#call-terminated
> Note: click happy and sad faces to see the flow.

Is there a reason we aren't going to provide a comment box with positive feedback? Understanding what users really like about the product can be just as powerful as understanding what we are lacking.
The API for posting data to Input is documented here:

http://fjord.readthedocs.org/en/latest/api.html#posting-product-feedback-api-v1-feedback

Things we/I would need to do before Input is ready for receiving data:

1. We would need to create a product on Input for Loop to post to.

2. Additionally, since you're asking to provide additional details that don't have fields in the API, we need to implement bug #1041622 and bug #1041664.

Neither are hard to do. It's probably a couple of days of work.
Flags: needinfo?(willkg)
Flags: needinfo?(dhenein)
Depends on: 1046304
Assignee: dmose → nobody
Dan -- I see that this is in the "blocked" column on trello and you removed yourself as the assignee.  What can I do to unblock this?  

I know we talked about some of this at various points during the week, but I would appreciate a brief summary of what's needed to get this moving forward. Thanks.
Flags: needinfo?(dmose)
I have a proposed set of fields described here: https://wiki.mozilla.org/Loop/Data_Collection#Input_Metrics -- I presume the UX at https://people.mozilla.org/~dhenein/labs/loop-link-spec/#call-terminated is complete, so this should pretty much be a matter of implementing those views and hooking them up to an XHR POST.
Bug 972992 has already implemented this for the desktop client, so this work should be based on that.
Depends on: 972992
As per comment 21, this is now unblocked.
Flags: needinfo?(dmose)
Bug 1024568 and bug 1041439 shouldn't block this as they are not part of "simple feedback". We should do them once we've got the simple feedback scenario.

Bug 1046304 also isn't part of this bug, and if anything should be done after this.
Blocks: 1046304
No longer depends on: 1046304
No longer depends on: 1024568, 1041439
While the two dependencies I've just added aren't strictly speaking blockers, after discussing with :NiKo`, it seems clear that we'll avoid mid-air collision work if we treat them that way.
Depends on: 1048785, 1048834
Iteration: --- → 35.1
Whiteboard: [p=1, qa-] → [p=1, qa-][loop-uplift]
Target Milestone: 34 Sprint 1- 8/4 → mozilla35
Assignee: nobody → nperriault
So looking at the spec[0], I'm a little confused with what the actual UX should be:

- The feedback form seems to be displayed on top of the conversation view, after the call has ended; but we're still seeing the local video being actively streaming. Is this intended? Should I keep the local video streaming in there (dunno if actually possible with SDK, need checking)? If not, what should I display in this area? I suggest we simply hide it.

- It seems possible to click the "Call Back" button as well as other buttons from the control bar while the form is possibly being filled; Some options here:

  * Prevent from clicking on the control bar buttons while the form overlay is shown, and provide a way to close it;
  * Hide/disable the audio and video mute buttons when the form overlay is shown, leaving only the "Call Back" one available;
  * Leave it that way.

- How should behave the feedback form overlay after the form has been submitted? Right now in the spec we see the overlay stays in place, leaving the end user possibly confused with what he should do next. Several option here:

  * Remove the overlay after 5 seconds — like what's done for desktop — so the end user can call back from there;
  * Alternatively, provide a "Close" button;
  * Or directly redirect the user to the initial Call Start view[1].

[0]: https://people.mozilla.org/~dhenein/labs/loop-link-spec/#call-terminated
[1]: https://people.mozilla.org/~dhenein/labs/loop-link-spec/#call-start
Flags: needinfo?(dhenein)
(In reply to Nicolas Perriault (:NiKo`) from comment #25)
> - The feedback form seems to be displayed on top of the conversation view,
> after the call has ended; but we're still seeing the local video being
> actively streaming. Is this intended? Should I keep the local video
> streaming in there (dunno if actually possible with SDK, need checking)? If
> not, what should I display in this area? I suggest we simply hide it.
This is fine by me, and does make sense.
> - It seems possible to click the "Call Back" button as well as other buttons
> from the control bar while the form is possibly being filled; Some options
> here:
> 
>   * Prevent from clicking on the control bar buttons while the form overlay
> is shown, and provide a way to close it;
>   * Hide/disable the audio and video mute buttons when the form overlay is
> shown, leaving only the "Call Back" one available;
I like this option ^^
>   * Leave it that way.
> 
> - How should behave the feedback form overlay after the form has been
> submitted? Right now in the spec we see the overlay stays in place, leaving
> the end user possibly confused with what he should do next. Several option
> here:
> 
>   * Remove the overlay after 5 seconds — like what's done for desktop — so
> the end user can call back from there;
This ^^
>   * Alternatively, provide a "Close" button;
>   * Or directly redirect the user to the initial Call Start view[1].
> 
> [0]: https://people.mozilla.org/~dhenein/labs/loop-link-spec/#call-terminated
> [1]: https://people.mozilla.org/~dhenein/labs/loop-link-spec/#call-start
Flags: needinfo?(dhenein)
This is clearly WiP, but I'd like to get feedback before pursuing. Most of stuff to be improved is identified with XXX in the patch. Tests are to be written, styles to better match the specs.
Attachment #8491632 - Flags: feedback?(standard8)
Updated WiP patch to have an EndedConversationView component, and added it to the UI showcase. This is still missing tests and polish, hence why still asking for feedback.
Attachment #8491632 - Attachment is obsolete: true
Attachment #8491632 - Flags: feedback?(standard8)
Attachment #8491888 - Flags: feedback?(standard8)
This is now ready for review. Please note that until the "Retry a call" feature is implemented, we're falling back to displaying the StartConversationView after the feedback form has been submitted (and we can actually restart the call from there).

I also fixed a few issues with coding style, obsolete configuration values and unnecessary jshint rules.
Attachment #8491888 - Attachment is obsolete: true
Attachment #8491888 - Flags: feedback?(standard8)
Attachment #8492112 - Flags: review?(standard8)
Comment on attachment 8492112 [details] [diff] [review]
Add feedback form to Loop standalone conversation window.

Review of attachment 8492112 [details] [diff] [review]:
-----------------------------------------------------------------

Looking good, just a few things need addressing I think.

::: browser/components/loop/standalone/content/js/webapp.jsx
@@ +412,5 @@
> +            feedbackApiClient={this.props.feedbackApiClient}
> +            onAfterFeedbackReceived={this.props.onAfterFeedbackReceived}
> +          />
> +          <sharedViews.ConversationView
> +            initiate={false}

Don't we also need to disable the buttons? They seem to be clickable at the moment, even if they don't do anything.

@@ +462,5 @@
>        this.props.conversation.off(null, null, this);
>      },
>  
> +    shouldComponentUpdate: function(nextProps, nextState) {
> +      // Only rerender if current state has actually changed

What else causes this to re-render currently?

@@ +756,5 @@
>      var conversation = new sharedModels.ConversationModel({}, {
>        sdk: OT
>      });
> +    var feedbackApiClient = new loop.FeedbackAPIClient(
> +      loop.config.feedbackApiUrl, {

The #init tests are failing because loop.config.feedbackApiUrl isn't stubbed.

@@ +758,5 @@
>      });
> +    var feedbackApiClient = new loop.FeedbackAPIClient(
> +      loop.config.feedbackApiUrl, {
> +        product: loop.config.feedbackProductName,
> +        user_agent: navigator.userAgent

According to https://wiki.mozilla.org/Loop/Data_Collection#Example_Payloads we should also be submitting the main part of the url.

::: browser/components/loop/standalone/content/l10n/loop.en-US.properties
@@ +61,5 @@
> +## LOCALIZATION NOTE (feedback_window_will_close_in2):
> +## Semicolon-separated list of plural forms. See:
> +## http://developer.mozilla.org/en/docs/Localization_and_Plurals
> +## In this item, don't translate the part between {{..}}
> +feedback_window_will_close_in2=This window will close in {{countdown}} second;This window will close in {{countdown}} seconds

Ok, here comes the really fun bit. This doesn't work for the gaia l10n.js that we use.

I believe we need to use the format that is indicated here:

https://github.com/mozilla-b2g/gaia/blob/f108c706fae43cd61628babdd9463e7695b2496e/apps/email/locales/email.en-US.properties#L387

message-download-images-tap={[ plural(n) ]}
message-download-images-tap[one] = This email contains one image. Tap to download.
message-download-images-tap[two] = This email contains {{ n }} images. Tap to download.
message-download-images-tap[few] = This email contains {{ n }} images. Tap to download.
message-download-images-tap[many] = This email contains {{ n }} images. Tap to download.
message-download-images-tap[other] = This email contains {{ n }} images. Tap to download.
Attachment #8492112 - Flags: review?(standard8) → review-
Addressed review comments.
Attachment #8492112 - Attachment is obsolete: true
Attachment #8492248 - Flags: review?(standard8)
Comment on attachment 8492248 [details] [diff] [review]
Add feedback form to Loop standalone conversation window.

Review of attachment 8492248 [details] [diff] [review]:
-----------------------------------------------------------------

Ok, I think this is good, bar sorting out the remaining small issue below that I picked up in testing.

::: browser/components/loop/standalone/content/js/webapp.jsx
@@ -455,5 @@
>       */
>      render: function() {
>        switch (this.state.callStatus) {
>          case "failure":
> -        case "end":

I just noticed, this is wrong in some situations:

- If the call is ended because the callee selects cancel (aka reject)
- If the call ringing times out

We probably need to rename "_handleCallTerminated" to something like "_handleCallConnectionTimeout" (or something better), and then special case that result to go back to the start page (or the call failed page when we get it).
Attachment #8492248 - Flags: review?(standard8) → feedback+
Patch rebased on top of latest fx-team, fixes the issue with feedback form being displayed on call rejection and timeout. For now we simply switches back callStatus to "start" so the end user can restart a call and skip the feedback form view.
Attachment #8492248 - Attachment is obsolete: true
Attachment #8493002 - Flags: review?(standard8)
Comment on attachment 8493002 [details] [diff] [review]
Add feedback form to Loop standalone conversation window.

Review of attachment 8493002 [details] [diff] [review]:
-----------------------------------------------------------------

That's great, r=Standard8
Attachment #8493002 - Flags: review?(standard8) → review+
Whiteboard: [p=1, qa-][loop-uplift] → [p=1, qa-][standalone-uplift]
https://hg.mozilla.org/mozilla-central/rev/0f46a8e4b012
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Flags: qe-verify-
Whiteboard: [p=1, qa-][standalone-uplift] → [p=1][standalone-uplift]
Comment on attachment 8493002 [details] [diff] [review]
Add feedback form to Loop standalone conversation window.

Approval Request Comment
Uplift request for patches staged and tested on Fig
Attachment #8493002 - Flags: approval-mozilla-aurora?
Comment on attachment 8493002 [details] [diff] [review]
Add feedback form to Loop standalone conversation window.

I worked with Randell and Maire on uplifting a large number of Loop bugs at once. All of the bugs have been staged on Fig and tested by QE before uplift to Aurora. As well, all of the bugs are isolated to the Loop client. Randell handled the uplift with my approval. I am adding approval to the bug after the fact for bookkeeping.
Attachment #8493002 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Flags: in-moztrap+
You need to log in before you can comment on or make changes to this bug.