In-page Documentation for Accounts and Notifications as a User

[QuincyLarson]

Account & Notifications

• Organizer subscriptions
• Notification settings
• Basic profile info for when other users view your account
• The ability to make your profile private

[allella]

@chrismgonzalez

• If the MVP is using Google for authentication, then is documenting an account page or password reset still applicable? I guess we could document the fact that your email and password are managed by Google, so visit https://myaccount.google.com or https://myaccount.google.com/security "Signing in to other sites" section?
• The MVP hasn't mentioned an account page, but if we do have one then can we imagine what is needed for an MVP? As a user, I can unsubscribe from a specific chapters emails. #274 and the suggestions about subscribing and unsubscribing may avoid the need for an account page to managed subscriptions, at least for MVP.
• What are we thinking with "Organizer subscriptions"? If it's for the organizer, then we probably need to move that item to Documentation for How to Use Chapter as an Organizer or Administrator #260. Or, was this intended to be "Organize Subscriptions"? If so, the previous bullet may mean we don't need a separate UI
• If we don't have an account page then documentation for Notification settings would be a matter of explaining opt-in and opt-out at the time of RSVP, or else clicking the unsubscribe link for any chapter-specific notification email.

[QuincyLarson]

@allella These are great points. I've updated the bullet points above to reflect this by removing the need for password management.

We should have a profile/settings page, and the ability to make it private. If you can document what specific attributes the page should have, we can ask @madaleneaza-design if she can create a layout for this.

[allella]

I would agree that a basic profile management page is necessary IF any of the following are true:

• we're not pulling a user's name from Google's profile or we use the Google name, but allow the user to override their name
• the user needs a public profile page. The alternative is we simply show the user's name on the RSVP list.
• privacy is set at the user profile level. If privacy is set at the chapter-level or event-level, then it's possible we don't need a user level setting. Though, it might be nice to offer at least user and event level privacy settings with a "Keep My RSVP Private" setting on the RSVP defaulting to the user-level privacy value.

I've shared my opinion that a subscription management / settings page is not a necessary MVP feature for a number or reasons outlined earlier.

I've figured out that "Organizer subscriptions" in the checklist above was likely copied from Meetup's settings page. If that's the case then "Organizer Dashboard" and "Admin Dashboard" are more appropriate to #260 since everything is free and organizers don't pay a subscription.

[allella]

Alright, to summarize the conversation from today related to the Settings / Account / Notifications page a user will see:

• We'll want to have links to the ToC and Privacy pages somewhere in the app. Are we going to have a footer, or shall we add links to the account page?
• Related to GDPR, we should have a section on the settings / account page showing what personal information (name, email) has been collected
• For alpha, we'll add a button for Account Deletion requests that emails fCC support for manual deletion until we can create a more automated approach. When an account is deleted, we'll likely show something like "Deleted Member" on event pages where deleting the record would otherwise distort attendance counts and such
• Rather than having a separate document explaining the user's controls and settings, we'll use a GitHub settings and fCC settings style of "self-documenting" pages (example below)

Example of Github's settings page

Example of freeCodeCamp's settings page