Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Android policy compliance improvements: links to account deletion, privacy policy #497

Closed
lcjohnso opened this issue Dec 13, 2023 · 10 comments · Fixed by #506
Closed

Android policy compliance improvements: links to account deletion, privacy policy #497

lcjohnso opened this issue Dec 13, 2023 · 10 comments · Fixed by #506

Comments

@lcjohnso
Copy link
Member

lcjohnso commented Dec 13, 2023

As described in Google's Play Console Policy doc on User Data, apps that allow account creation from within the app (we do; internal registration form is provided) are asked to provide a "readily discoverable option to initiate app account deletion from within your app". The current platform-wide mechanism for account deletion is to visit https://panoptes.zooniverse.org/profile and confirm one's intent to delete by entering the current account password (backup option: email [email protected] and a team member can delete account on behalf of account holder via admin page).

Google Policy also states that all app should provide "a privacy policy link...within the app itself" (here, the Zooniverse privacy policy: https://www.zooniverse.org/privacy).

I propose the following improvements:

  1. Add a link within the app to the Panoptes profile page used for account deletion. Make this link visible to logged-in users, possibly on the Settings page.
  2. Add a link to the privacy policy in a highly visible location. Make the link visible to all users, possibly in the navigation menu under the "Connect" options.

I envision the links opening in a default browser (rather than via Webview internal to the app).

@seanmiller26 -- Can you propose placement locations for these two links?

@seanmiller26
Copy link

seanmiller26 commented Dec 15, 2023

Ideally these links shouldn't be too buried, so I have added subsections. These should be an intuitive place for users to find these specific links. (1/12/24 Update based on a chat w @lcjohnso)

Screen Shot 2024-01-12 at 12 50 18 PM Screen Shot 2024-01-12 at 12 50 24 PM

Within the Settings menu

Screen Shot 2024-01-12 at 12 58 23 PM

Preview here (click the side menu) https://www.figma.com/proto/QC931orjhCdGoQogVg7iDZ/Mobile-App?type=design&node-id=2-201&t=uRGS1RPjRZzCbGg0-1&scaling=min-zoom&page-id=0%3A1&starting-point-node-id=2%3A201&mode=design

@coryzoon
Copy link
Contributor

@lcjohnso @seanmiller26 A few questions about this ticket:

  1. Do both "Zooniverse account information" and "Delete my account" go to the same link "https://panoptes.zooniverse.org/profile"?
  2. Do we want to show the "Delete my account" option to Android users only, or both Android and iOS. I assume both, but want to double check since it's an Android compliance item.
  3. I noticed in the designs that "Settings" and "Notifications" are not shown when the user is logged out but currently these are shown when the user is logged out because logged out users can still receive and view push notifications. I can just hide the links on the "Settings" screen if that works for you.
  4. Should I update the fonts and toggle switches to reflect the designs or leave as is for now?

@lcjohnso
Copy link
Member Author

Hi @coryzoon --

  1. No. Zooniverse account info = https://www.zooniverse.org/settings; delete my account = https://panoptes.zooniverse.org/profile
  2. Show link to both iOS and Android users (while prompted by policy, it's a useful convenience thing that we should make available to all.
  3. I lean towards hiding the Settings and Notifications links when not logged in. However, there's one thing to check regarding this: am I correct that not-logged-in users will not receive notifications because their device ID is never synced to any list?
    • If I'm correct, then it is good to hide the settings and notifications links/pages and it simplifies the meaning of toggled/edited notifications preferences in settings while logged out (i.e., no complication at all if user can't make these changes).
    • If I'm not correct and not-logged-in users are receiving notifications, then proceed with your above plan: keep showing notifications and settings on the main menu, but hide the "platform settings" section on the settings page.
  4. Go ahead and swap in the new toggle switches (as long as it isn't prohibitively difficult). As for fonts: I'd rather not mix-and-match -- if rest of app is still using orig font, stick with current. If straightward to switch everything at once, that sounds good to me. @seanmiller26 -- what do you think?

@seanmiller26
Copy link

I think Cliff handled these questions nicely and I can only weigh in on:

  1. I agree with the argument of - if it's easy enough to switch to the new font, let's do it. We'll eventually get to the rest of the pages, so best to update it while we're working on it.

@coryzoon
Copy link
Contributor

@lcjohnso They would not be synced to any project specific list but they would still be subscribed to general notifications like "New projects", "New beta project", and "Urgent help alerts". By default those are all toggled on if the user enables push notifications.

@lcjohnso
Copy link
Member Author

@lcjohnso They would not be synced to any project specific list but they would still be subscribed to general notifications like "New projects", "New beta project", and "Urgent help alerts". By default those are all toggled on if the user enables push notifications.

@coryzoon OK -- then, it looks like we shouldn't hide setting or notifications on the main menu in the case of logged out user. Sounds good to me!

@coryzoon
Copy link
Contributor

coryzoon commented Feb 1, 2024

@lcjohnso @seanmiller26 This ticket is complete and PR approved but @mcbouslog asked a good question in the PR in relation to the white zoon icon in the upper left of the settings & notifications screens. The other screens currently have the back button but these two screens have this icon. Is the idea that over time they will all have this icon and that the user should use the hamburger menu icon to navigate? Should anything happen when the user clicks on the zoon icon? I just wanted to clarify this before merging the PR in case I need to make an adjustment. Also, I wanted to note that the "Contact us" link went to https://www.zooniverse.org/about#contact which doesn't take the user to the correct tab so I used "https://www.zooniverse.org/about/contact" instead which appears to work.

@lcjohnso
Copy link
Member Author

lcjohnso commented Feb 1, 2024

Hi @coryzoon --

Re: navigation = I'll let @seanmiller26 confirm, but yes, for pages listed in the hamburger menu, I lean towards shifting to "hamburger only" navigation where the Zooniverse logo is displayed rather than a back arrow.

Re: contact link = the about#contact version of the URL is assuming a new page structure that will be adopted as part of a FEM homepage build Mark is leading. Go ahead and use the "old" link for now (https://www.zooniverse.org/about/contact) and either we can update it in the app when the page launches. Or better yet (because nobody likes broken links), we'll set up a redirect in FE routing or at the domain level to redirect to the new URL. Either way, we'll sort out a solution later.

@seanmiller26
Copy link

Just popping in to mirror what Cliff mentioned and that the Zooni logo will eventually be on all pages. I'd like it to always link to the app homepage as this will become useful in the future as we touch on that area.

@github-project-automation github-project-automation bot moved this from High Priority to Low Priority in Mobile Effort Feb 3, 2024
@lcjohnso lcjohnso moved this from Low Priority to Complete in Mobile Effort Feb 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

3 participants