Page MenuHomePhabricator

Allow users to provide feedback from within the app
Closed, ResolvedPublic

Description

Why are we doing this?

We would like to have a way for users to provide feedback to the development team via the app. Users can report bugs, issues or general comments.

Acceptance criteria

  • A user can submit feedback through an open text field within the feedback menu on the app
  • They will not be required to provide any identifiable information and can submit feedback anonymously
  • The user will receive a comment letting them know that we are thankful for their feedback. "Thank you for your feedback!"
  • As feedback is anonymous, we will not communicate back to the user with responses to their questions/comments
  • Will need to work without a user providing/having an email address or phone number
  • As there is no rating or comments on the KaiStore at this point, the feedback will be stored by and for the product dev team only
  • A user understands that by giving feedback, they accept the privacy policy and terms of use

Proposed designs

Zeplin ➡ https://app.zeplin.io/project/58dc46f4a83d1e477dd83859/dashboard?seid=5eafd44fb7bd22b0d503847c

Empty stateReady to sendConfirmation
01.Feedback & Help Updated home screen.png (640×480 px, 48 KB)
02.Feedback & Help_v1.png (640×480 px, 49 KB)
Feeback confirmation.png (640×480 px, 36 KB)
Focused StateUpdated Settings Menu
02.Feedback & Help.png (640×480 px, 50 KB)
App settings updated.png (778×480 px, 44 KB)

Design details

  • "Send" softkey is not visible to users before entering the feedback.
  • If control is on text box then cursor keeps blinking until users start writing feedback.
  • If there is multiline text then allow for scrolling within the text box.
  • Confirmation message appears in popup form on main feedback screen.
  • When other links are focused then text box becomes inactive.
  • When device is offline, "No internet connection" error screen is displayed immediately after selecting "send feedback" on the menu
  • Use up/down keys on D-PAD to switch control between the text box and fine print and use left/right keys to switch between links

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

Terms of survey statement
Privacy policy
Terms of use

Could we make a note in thread of the URLs these hyperlinks should route to?

SGautam_WMF updated the task description. (Show Details)
SGautam_WMF updated the task description. (Show Details)

@eamedina Updating our offline discussion here, I have made some minor design changes. Also, I have updated note on zeplink with the links for the privacy policy, survey statement, etc.

Awesome, thanks Sudhanshu.

Leaving the PR link here, at this point it's only a draft PR (so still work in progress):

https://github.com/wikimedia/wikipedia-kaios/pull/216

Hey @SGautam_WMF, surfacing this again after picking up the PR again. A couple of feedback points came up during our code review, this is regarding what happens when a user attempts to send the feedback message:

I don't think we should let the users select RSK (send) before there's any text in the textarea. We can easily handle that by looking at message. I find the "error" message completely unnecessary.

On success, we should direct people away from the form. Filling a form successfully never leads to the same empty form (unless it's a repetitive task by nature). It should lead to a confirmation and then to wherever the user was before (settings menu?). I suggest showing the confirmation message in our regular popup, on top of the feedback form, and going back to /settings when the user OKs the popup.

Also, I found the links in Zeplin 👍. Any update on the terms of survey statement?

Terms of survey statement 
tbu

Privacy policy 
https://foundation.m.wikimedia.org/wiki/Privacy_policy

Terms of use
https://foundation.m.wikimedia.org/wiki/Terms_of_Use/en

On the survey statement, we should have that soon from the legal team now that we decided how we'll store responses. I'll follow up again next week if we don't have it by Monday.

Hey @SGautam_WMF, surfacing this again after picking up the PR again. A couple of feedback points came up during our code review, this is regarding what happens when a user attempts to send the feedback message:

I don't think we should let the users select RSK (send) before there's any text in the textarea. We can easily handle that by looking at message. I find the "error" message completely unnecessary.

That's a good point, how are we imagning to do it? Does the text "Send" still shows to users but RSK physical key is not functioning? or "Send" is disabled but only gets active when users start writing inside the text box?

On success, we should direct people away from the form. Filling a form successfully never leads to the same empty form (unless it's a repetitive task by nature). It should lead to a confirmation and then to wherever the user was before (settings menu?). I suggest showing the confirmation message in our regular popup, on top of the feedback form, and going back to /settings when the user OKs the popup.

It make sense and we can bring back the control to settings menu. The reason I chose to keep the control on "feedback form" as typing long text is not easy on small phones and therefore keeping control there to let users continue to share more but now suggested flow make sense to me while rethinking on it. Regarding confirmation message, for consistency we can keep a regular popup, however, that requires an aditional step(pressing OK) from users before returning to settings menu, instead can we show current confirmation message in the bottom or top of settings menu? Happy to share mockups if required.

Also, I found the links in Zeplin 👍. Any update on the terms of survey statement?

Terms of survey statement 
tbu

Privacy policy 
https://foundation.m.wikimedia.org/wiki/Privacy_policy

Terms of use
https://foundation.m.wikimedia.org/wiki/Terms_of_Use/en

Does the text "Send" still shows to users but RSK physical key is not functioning? or "Send" is disabled but only gets active when users start writing inside the text box?

Yea I think both options are feasible here and achieve the same goal, I can follow your advice on what you think is best. To clarify, by "Send is disabled" I understand you are saying the RSK appears empty/blank at first, and then only when there's text written in textarea does the button appear. This can be similar to how 'SELECT' appears on home search bar as user navigates down the search results

Regarding confirmation message, for consistency we can keep a regular popup, however, that requires an aditional step(pressing OK) from users before returning to settings menu, instead can we show current confirmation message in the bottom or top of settings menu? Happy to share mockups if required.

Okay, yea I think in the spirit of getting this important feature right it would be helpful to update mockups so we can all agree on newer version. For example, this point you make...

therefore keeping control there to let users continue to share more

...got me thinking that to give control to the user, another alternative would be:

  • user writes out message, and then presses 'Send'
  • upon successful send, the native half-popup appears with confirmation message and presents the user with two softkey options:
    • one that's to 'OK', which would send the user back to settings
    • another that's 'More feedback?', which would brings the user to the same sending feedback page with the textarea cleared/blank, allowing the user to submit one more time if she so desires

@eamedina I have updated the design based on the initial feedback. Let me know if you require any further clarification on it. Shall we also consider a popup( attached draft mockup) when users press "Cancel" softkey while they're in the middle of writing feedback?

Discard.png (640×480 px, 39 KB)

@SGautam_WMF awesome, thanks for updating these! I think the updated flow on successful send looks good, I will start working towards that unless the rest of the team would like further updates.

Regarding the cancel confirmation popup, I think it's not a bad idea and suppose it wouldn't hurt. I will let the @AMuigai chime in on that though. I would ask/clarify however: it probably makes sense for that cancel confirmation popup to be displayed only if the user has already type in something, otherwise just show previous page directly.

@eamedina Yes, cancel confirmation popup to be displayed only if the user has already has typed in something, otherwise show the previous page directly.

@AMuigai noted, already included now under code review

On the survey statement, we should have that soon from the legal team now that we decided how we'll store responses. I'll follow up again next week if we don't have it by Monday.

@AMuigai where are the responses going to be stored? went through the comments and couldn't find the decision.

@eamedina if you are in an article page, the right arrow goes through the links in a page, the down/up arrow flips pages.
on the send feedback window, the down/up arrow goes through the links.
is there a reason for this behaviour to be different from the rest of the app?
I get it that in order to leave the text box the right arrow is not the best option but once we have the focus on the links we can use the same behaviour as on the rest of the app, no?

found a bug: if you select "send" and, once the "Feedback sent" popup is showing, you use the back button the whole navigation gets crazy:

  • the ok button has no action
  • the cancel button takes us to the Discard popup
  • the send button has no action (expected)

basically, once the "Feedback sent" popup is showing, the back button should have the same behaviour has the OK button as to avoid the user being stuck in this page.

this also happens when the Discard popup is on top, basically the back button needs to be tamed on the popups 😄

I think we miss another scenario when the user in offline mode, should we update the popup form to allow resend action?

Oh right, forgot about that.
QA NOTES:
Test offline mode while on the feedback form and the path to the feedback form

found a bug: if you select "send" and, once the "Feedback sent" popup is showing, you use the back button

@Jpita good find Pita! I have proposed a solution for this bug now, thanks

This comment was removed by AMuigai.

where is the feedback being sent to?

SBisson added subscribers: nshahquinn-wmf, SBisson.

where is the feedback being sent to?

It is sent to EventLogging. @nshahquinn-wmf and I have validated that it is received.

There are a few ideas regarding what to do when the phone is offline, we should decide how we want to move forward in this thread or in a daily meeting. Some approaches would probably need further design work, one (perhaps temporary) approach I can think of for us to stay most agile is reusing the same offline panel if there's no wifi when the feedback screen is displayed.

Screen Shot 2020-05-31 at 10.59.20 AM.png (492×472 px, 21 KB)

waiting for the decision on the offline mode

Sharing some of my thoughts on it, on Android and web, mostly I have seen two patterns being used while using feedback feature in offline mode.

a. Some apps let you write & submit the feedback in offline mode, it gets synch later when users connect with the internet. I am not sure if on KaiOS we do have a way to synch it similarly, also does this require us to ask for additional permission to do so?
Btw, in offline mode, our app let users change the language and retain their choice when they connect to the internet.

b. Another approach used is to show "not connected to the internet" message once users try to submit the feedback, It might make sense on touch devices where writing is not difficult but for KaiOS devices showing "not connected to the internet" screen first would make more sense as it would avoid some writing labor.

@eamedina @Jpita For this release, when device is offline, and user goes to the feedback screen, they will see the "No internet connection" screen/panel.

Sounds good, I have updated the branch the following user-friendly behavior:

  • if user is offline from the time she first lands on feedback screen, app shows offline panel and saves the user the trouble of writing feedback (that she won't be able to send)
  • if user becomes offline while writing:
    • the offline panel is shown, as well as the yellow bar offline indicator at the top for a few seconds. This is consistent with the behavior in the search home screen
    • and was able to confirm that whatever had been written until then does not get lost if users stays in the feedback screen. So if the user lost connection only momentarily, she would still be able to continue writing from where she left off and submit afterwards

@Jpita I merged the PR but this still needs to be tested.

@eamedina if you are in an article page, the right arrow goes through the links in a page, the down/up arrow flips pages.
on the send feedback window, the down/up arrow goes through the links.
is there a reason for this behaviour to be different from the rest of the app?
I get it that in order to leave the text box the right arrow is not the best option but once we have the focus on the links we can use the same behaviour as on the rest of the app, no?

@eamedina I still see this behaviour, should we fix it or leave it?

I would let Angie or Stephane make that call. PR is now merged though, so I think we would need another ticket

I like Pita's suggestion here, we can use up/down keys on D-PAD to switch control between the text box and fine print and use left/right keys to switch between links.

Sharing my takeaways here after having looked at the code. The current app behavior regarding navigation with up/down and right/left keys is:

  • up/down keys essentially perform a scroll up/down action, which in the case of reading an article it's represented as a ‘page flip’. When you get to the bottom of the article, there’s no more to scroll and hence page flipping ends.
  • right/left keys switch between the selectable items that are seen in the screen at each present moment (each page)
  • take the quick facts screen for example: same behavior, up/down keys perform a up/down scroll and right/left switch between what’s selectable on the page.

With the above in mind, having the navigation of the feedback screen perform both up/down and right/left for a single screen (nothing to scroll down or flip to next) actually seems to go slightly against the overall app behavior consistency. This became evident to me only after looking at the code (the code "told me" this, if you will). I'm bringing this up now just so we are all in the same page, the PR is below if we want to go through with it. I encourage everyone to deploy that branch (T236317-feeback-component-follow-up) and play with the feedback navigation to see how it feels

https://github.com/wikimedia/wikipedia-kaios/pull/252

It actually makes sense that we are talking about such navigation now because I believe with this new feedback component this is the first time when we have this scenario in the app: a single screen (as in non-scrollable) with selectable items. The only similar case I can think of (but couldn't find) is maybe a quick facts that’s small enough to fit in one page (in which case, should there be selectable items in it, they would be selectable with right/left arrow).

@eamedina, Thanks for bringing this case. Indeed, this screen is different than any other single screen we have in the app. In my opinion, it might take some time for users to learn that left/right keys are there to switch links while they are reading the article so it's good to keep the same behavior while they are on feedback screen. However, after installing the branch I felt the current controls are less intuitive, therefore, one suggestion could be, keeping navigations free-flowing and allow users to use the entire DPAD(left, right, up, down) on the screen to move in and out of the box and switching between links.

Agree this is a good opportunity for users to 'learn' that they can switch between links with right/left keys. I like the idea of keeping it more free flowing to make it more intuitive, how about the following to try to achieve that sweet spot, middle ground:

  • Up/down keys allow you to traverse all selectable items
  • Right/left allow you to switch between links and
  • Also keeping in mind navigation within the text, right/left allow the user to move through the characters of the message she's writing

The above behavior is now active in the same branch. You wanna redeploy and play with that to see how it feels?

I think this middle ground makes sense to me as in my earlier proposal I forgot to consider the role of left/right to navigate within the text.
Unrelated to this, I think we need to tweak the position of the discard dialog box as some text is hidden in the Hindi language on all three devices also our usual adjustment for Jio-2.

Discard dialog boxFineprint on Jio-2
20200619_164642.jpg (4×1 px, 242 KB)
20200619_164656.jpg (4×1 px, 305 KB)

oops, thought this was on QA already.
should I move it back?

Yea moving it back to Code Review so I can address Sudhanshu's last comment

Unrelated to this, I think we need to tweak the position of the discard dialog box as some text is hidden in the Hindi language on all three devices also our usual adjustment for Jio-2

Thanks for catching this @SGautam_WMF, I pushed the updates to branch T236317-feeback-component-follow-up-2, could you check it out on across devices again?

New PR here just for bookmarking: https://github.com/wikimedia/wikipedia-kaios/pull/257

This comment was removed by Jpita.

Found out confirmation and discard messages are left-aligned which doesn't look good on devices. @eamedina is working to center align them.

Screen Shot 2020-06-29 at 2.11.46 PM.png (648×478 px, 33 KB)
Screen Shot 2020-06-29 at 2.14.44 PM.png (634×474 px, 39 KB)

PR now created: https://github.com/wikimedia/wikipedia-kaios/pull/260

@SGautam_WMF we will wait for your final confirmation before merging

@eamedina this looks fine now, I'll move it to product signoff once you merge it.