Terms of survey statement
Privacy policy
Terms of use

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

@eamedina sure, I will update it.

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

In T236317#6135109, @eamedina wrote:

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?

@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

In T236317#6135907, @AMuigai wrote:

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

where is the feedback being sent to?

In T236317#6175479, @Jpita wrote:

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.

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.

In T236317#6151706, @Jpita wrote:

@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 box	Fineprint on Jio-2

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

@eamedina looks fine on all 3 devices.

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

We are working on the final details in branch T236317-feeback-component-css-tweak

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.

Merged now, thanks