Simpler version of bug 972992 for MLP

For Talkilla, we used google forms: https://docs.google.com/a/mozilla.com/forms/d/18hE8fjbkktm2E8Q40nJ1heRESVX9McoY2RMmGCjc-TQ/viewform

Mark -- I'm assigning this to you as part of bug 972024 (and bug 974875). Thanks.

We want to do this soon after MLP.

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.

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.

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?

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

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.

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.

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

Initial sound file which may change later.

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.

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.

(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.

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.

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.

As per comment 21, this is now unblocked.

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.

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.

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

(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

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.

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.

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.

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.

Addressed review comments.

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).

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.

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

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

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.