search

Joystream / atlas

Whitelabel consumer and publisher experience for Joystream
https://www.joystream.org
GNU General Public License v3.0
100 stars 44 forks source link

User accounts #1820

Closed bedeho closed 1 year ago

bedeho commented 2 years ago

Dependency

https://github.com/Joystream/orion/issues/60

Background

Here is the backend description of the issue for Orion: https://github.com/Joystream/orion/issues/60

The two basic goals are to

  1. Introduce proper notions of server-side accounts.
  2. Introduce a new web2.0 friendly key managment solution as low-mid security option for onboarding new users, so that external signer install and management can be postponed.

Proposal

As mentioned we will have three account modes

  1. Ephemeral: Here the changes to the product will mainly involve
  2. Off-chain: This will be the primary authentication step for all non-ephemeral accounts. So it makes sense that the only auth action in the product is "Login", rather than "Connect Wallet", and any action in the product that currently triggers a wallet flow, like "Buy NFT", should first trigger this login flow. The login flow should be a very typical login vs. account creation flow, with normal email+password capture. We should probably make the password requirements stringent, as these may later end up being used as part of the web2 based key managment. I don't think it makes sense to build any sort of personae or profile associated with the the off-chain membership. This is because it should basically be invisible to any other user, as all interaction sshould be mediated by the chain - which implies a membership account, and also because it would make the productt very confusing to have two personaes active at once for some users: the membership + the off-chain account personae. So it's best to give the the off-chain account a more of an anonymous and private feeling.
  3. Membership: As before, doing any sort of on-chain action requires a membership, but when it comes to creating such a membership we now have to give people the option between an "Easy" (web2 based) and "Safe" (external signer) alternative, and properly explain the tradeoff and when each case is recommended, and what benefits are. Likewise, when trying to select a membership which the user claims already exists, then they have to chose between the two modes of managing keys. There also has to be flows for allowing a user to graduate from one form the easy to the safe form of key management.

The new primary source of complexity will be that we now in essence have more complex flows when a user goes from an ephemeral or no account while interacting with some blockchain level action, and the product is supposed to guide the user in a reliable way through both levels of account creation and management: off-chain + membership. It seems entirely solvable, but it does require keeping in mind the entire exprience, both from the consumer and studio side, and make sure we have sold flows for all combinations of user actions and initial account status.

KubaMikolajczyk commented 1 year ago

Questions:

  1. Ephermal - means without an account right? Are requirements for this type still not clear?
  2. Log in - email + password - it may be a good idea to explore login with social media such as google accounts, Facebook, apple as this lowers the effort user has to take in order to register
  3. User who has off chain account what actions can they do?
  4. What actions are strictly reserved for Memberships?
  5. What are the steps of easy option of creating a membership?
  6. What are the steps of Safe option of creating a membership?
  7. What is the tradeoff and when each case is recommended? And what are the benefits?
  8. What does it mean „two modes of managing keys”?
  9. What is the scenario in which user has a membership already and they have to claim already existing one? Where they can create it other than in the app?
  10. What are the steps of graduating from easy to safe?
  11. Is it possible to get back from safe to easy?
  12. At one point Dina mentioned that notifications settings will be a part of user accounts as well? Are they?
  13. What can user manage in their off chain account?
  14. What can user manage change in their membership?
dmtrjsg commented 1 year ago

Agreed to

  1. Merge Off chain and on chain account creation to one journey.
  2. For new users sign up will entail adding email+password and that would automatically create "managed" wallet (account address) for their memberships.
  3. Existing users will be directed to account settings to provide email+password on any tx requiring backend or chain tx (follow/like/comment/buy or sell asset/ claim rewards)
  4. Membership accounts are portable between apps (gleev -> l1.media/pioneer) via same mechanics: Seed will be exported. This would require user to provide email+password again before exporting seed in json format.
  5. Users can upgrade from managed crypto wallet to signer experience. That would require to create new account (polkadot adddress) in the signer and bind membership to this account. Username and password would be required to get entered before this binding tx can be signed and user transfers signing to extension.
  6. Signup is a single journey requiring membership creation with password and login. Signing in will have an option to do so with the signer browser extension.
  7. Email and password can get changed in Account settings.
dmtrjsg commented 1 year ago

Login

  1. Add verification email in the end of the flow
  2. Create Membership> address+Seed to show at the point only when it comes into play (signing transaction).
  3. Add screen to Login for users who have account and signer so they don’t provide password. In this case they don’t need to add memebrship handle.
  4. Login/ Sign up served as an overlay.
  5. Sign T&Cs

Membership drop down menu

  1. Switch member and Disconnect wallet is hidden for ones who do not have a signer (who have internal wallet).
  2. Move “connect signer” from Profile Menu to My profile > settings > Wallet Management
  3. Move settings to My profile> Settings
  4. “Login/ Logout” shown for internally managed wallets. When they logout wallet is disconnected.

Advising to use signer

  1. Use signer for your extra protection would depend on diff valuables. You have [x tokens, y nfts]..
  2. It would be delivered in the banner showing on: My portfolio/ Channel > NFTs/ My Profile > NFts.
  3. We need to add the info that their comments and likes will need to now be signed.

Connecting Signer when you are already logged in

TO be revisited at later stage depending on the schema (export keys / json/. seed?)

Profile settings

Separate tabs with CTA = Publish Changes Public Profile> Private Profile> Notifications >

Some explanation for blockchain level data that persists across apps/ app level acc that is private

Add Reveal Seed

Use account on the other platform (w.o. signer eg L1.media)

No importing, there is no way to use same membership without signer.

KubaMikolajczyk commented 1 year ago

The first hi-fi iteration of the work for user accounts is ready to be reviewed ✅ 🎥 Loom video: https://www.loom.com/share/cae156ec703a4ece927566a2ef9f5bff

dmtrjsg commented 1 year ago

Qs from Leszek

9:38 - What if the user already has an existing blockchain membership, but just wants to create an account on Gleev and connect it to it? Reply

9:58 - I this case the password provides access to user's funds, so I'm not sure if it's a good idea to show it by default. We could also require it to be repeated it to reduce the possibility of a mistake. Reply

12:05 - Can't this step be skipped? If not, does this imply there would be no possibility to create an account w/o a respective blockchain membership? (ie. the Off-chain account, as described in the original proposal) Reply

15:05 - When the user clicks the link in their e-mail, a new browser tab / window will be opened. So at this point the user will (usually) have 2 separate tabs:

  1. The tab where the login flow was initiated
  2. The tab showing e-mail confirmation success message I assume they will continue on the 1st tab, so the 2nd tab will have to inform them that they should close it and do just that. Is there a design which shows how this 2nd tab, ie. e-mail confirmation success screen, will look like? Reply

24:04 - I don't fully understand this flow. Are the memberships shown here just all on-chain memberships the user has or only those that are connected to an existing Gleev account? So fundamentally: Is this flow just for logging in to an existing Gleev account or does it include a possibility of creating a new Gleev account and automatically connecting it to a chosen on-chain membership, which wasn't previously connected with any Gleev account? Reply

24:37 - Actually I don't think we previously considered logging in without using e-mail & password in the original User Accounts spec issue, so this is a new territory for me. However, surely in this case the user would be required to sign some kind of a message using their external wallet. Reply

26:42 - JOY is also a very important asset to consider here.

Lezek123 commented 1 year ago

32:28

Unfortunately I don't think we can allow changing the e-mail and password so freely, because the internal wallet seed is encrypted using those. This means that if the user changes any of this information, Gleev would no longer be able to decrypt their wallet seed upon logging in (as it was intially encrypted using the old e-mail/password combination) and they will lose all their assets and memberships associated with the previous wallet. The only way to prevent this would be to migrate all assets and membership(s) to a new wallet, created an encrypted using the new e-mail & password, but this may in some cases not be possible, because some assets may be staked or locked in which case they cannot be moved to a different account. This will actually be a recurring problem throughout the current designs, so I'll mention it in a few other places as well, as this may have substantial impact on many of the flows.

Another issue, which is relatively smaller, is that there is no functionality to change the account's e-mail address currently designed in the Orion API, but bear in mind the new e-mail would need to be confirmed through a link, just like the old one, before we allow the user to connect it to their account.

35:48

The way I was imagining it was that it would be actually possible to use a combination of internal wallet and external wallet for example. Becasue, as mentioned in one of the previous comments, it would be difficult to just migrate all assets and membership(s) to a different account, as some of the assets may not be moveable.

36:56

Showing user the seed like this is always at the cost of lower security, because this means the seed has to enter the main thread of the app, which has access to the UI, but is also most susceptible to all kinds of XSS attacks. Additionally, it increases the risk of the seed being seen by someone from the "outside world", so ideally we wouldn't show it unless the user explicitly asks for that, being aware of those risks.

41:32

I'm afraid we won't have enough data to encrypt an internal wallet seed for the user that just signs up with Google, unless they provide some additional secret (like a password for example). I think Google will only provide us with the e-mail and public user profile information. And even if they could provide us with some kind of a secret for each user, this would break the assumption of the hybrid key management scheme, as Google would in that case effectively be in posession of a secret which provides access to user's funds.

51:09

Again, I think it's worth repeating here that this implies we'll be moving all assets and membership(s) from the old address (internal wallet) to a selected external wallet address, which is tricky to achieve for the reasons previously mentioned (locked/staked funds cannot be moved etc.)

51:55

In reality, if the user forgets their password and they've been using an internal wallet, their membership and all assets are effectively lost, as their old password is required to decrypt the internal wallet seed. They could still preserve other, off-chain data associated with their Gleev account, like channel follows, information about videos watched, recommendations etc., but they'll lose access to everything they had stored on chain.

dmtrjsg commented 1 year ago

Sign up

Membership drop down panel

 Upgrading wallet

Ypp Login

bedeho commented 1 year ago

Please excuse this wall of text.

Overview

Thank you for making this monumental explainer, there was a lot here, which does indeed make it super hard to review well, but I also don't think it would be so easy to split this up, as decisions here are interrelated. Is there something like a chapter feature on YT, or at least something where you can add timeline milestones for when you start some new part of the review?. Often I need to go back when writing final feedback and reorganise my notes from first viewing, and this would help me a lot, at least when its this long.

I suspect we may need a meeting here once you have had time to review all of this, in particular because you are getting 3+ reviews, and we probably all need to get on the same page both on design, Orion (Leszek) and yt-synch (Zeeshan).

NB: Great if you can remember to include link to actual Figma as well, I'm kind of hesitant to enter Figma to find stuff, because its just so vast, but in the end I had to go and find it, which I probably should have worked up the courage to do earlier. Having just linked would have made it easier.

Screens & Components

Here I make some remarks about screens and components that apply across a broad range of user stories.

Email verification

There are three very large costs to having email verification in the middle of the flows as we currently do

This benefit of having the verification seems to me to be two-fold:

  1. Avoid someone using our infra to send out irrelevant emails to third parties. I have a really hard time thinking anyone would really bother doing this, because you would have to a go through a lot of work to break the CAPTCHA at some scale, then to and operate all those memberships to generate notification events, and through that spam someone. Financial payoff would be 0.
  2. The tiny share of sessions where people have a fat finger incident with their email will result in them not being able to login again.

I think the first point is essentially a non-problem. If it becomes a problem, we can deal with it, for example by not starting to send out notifications before the user actually verifies an email at a later time. The second point is a real problem, but we can just solve that more gracefully by requiring the user to enter the email twice in two separate input fields, and we indeed will be forced to do this with the password anyway, as you will see in my remark under As a not logged in user I want to create a new membership.

So as a conclusion, I suggest we entirely remove all notions of email verification steps inserted in these signup flows.

Login/Signup Modals

There is no need to place the logo Gleev in such a large prominent position and in competition with the actual explainer of the dialog. Everyone knows they are on Gleev, it's not like you are sent to some new screen, popup or iframe where people may be confused about where they are, so this does not solve a real problem and crowds the space. Likewise the subtitle does no real work, and will not be read, so lets drop that as well.

Membership+Channel Drop Down

I have for a long time been really confused by the drop down, like badly. I don't know if we should fix this now or not, but I feel there are serious UX issues, so if we are layering in new concepts now, perhaps we should just do it now: https://github.com/Joystream/atlas/issues/4115

NB: Can we drop all the My .., and just call it Portfolio.

Missing Screen: Logged out

When users have logged in, whether using a either kind of key management, all calls to the backend which involve accessing or updating private user specific data require that the app sends an authentication token along to the server. These tokens are obtained during login, however they expire, hence there needs to be a way to show a sort of state or screen that tells the user they have been logged out. This would for example happen if someone logged in, closed the lid on their laptop, and then came back sufficiently late.

NB: Here we must confirm with @Lezek that indeed he plans to use auth token scheme for all API calls, regardless of key management for the user. I think this is the best approach, benefitting from uniformity and simplicity.

Improper use of Snackbar

In my opinion we are using the snackbar for many unrelated types of events, not all of which make sense for the snackbar. In my opinion, they should be used for notifying user of events may occur at unpredictable time in the future w.r.t. triggering user action and that we want the user to be able to proceed and do other things in the interim. Here are some examples of things where we are using it which are inappropriate.

  1. Result of login failure when the login screen is still fully blocking the users ability to engage with anything else. In this case, error should in inline as prominent message in the login modal, not off in the corner, just like we do with form validation.
  2. Similar errors during membership creation.
  3. Membership creation success: The user should not be able to go off any do anything else as result of triggering the final step for the membership creation flow, they have to wait for the final outcome. Otherwise user will mistakenly believe they can do various actions despite creation possibly failing, or being backed logged - e.g. because transaction confirmation takes a long time.
  4. Telling the user they have logged in: Welcome back .... Again, they cannot proceed before login has worked, hence should not be a snackbar by the principle above, but more importantly I don't even think it serves any real user objective, they know they have logged in when they progress.
  5. Telling the user that something is being created.

NB: realise that we may already be breaking this principle from before, and I certainly don't want us to now simultaneously try to introduce user accounts and changes this behaviour across the app, but I would certainly not want to pile on.

Flows

As a not logged in user I want to engage with platform

A problem here is that when people launch into this flow and they don't have an account, they will need to do the email confirmation step, which will take them out of the app and continuing in a new window, this breaks the overlay assumption that you are in the context of your past action. I don't think there is really any solution to this, perhaps with the exception of embedding more context in the verification email link so as to open with the correct background. Please consult tech team how much work this will be. We already know it is unlikely to be perfect, as there will be browser or app level UI state which will be too complex to capture (e.g. browser scrollbar, browser magnification, opened nested comments, whatever).

As a not logged in user I want to create a new membership

I am here assuming that this user story is specifically for users trying to login in the context of all actions except signing up for YPP, which is captured in the distinct user story As a not logged in user I want to go through YPP log in process.

As a not logged in user I want to log in to my membership

As a not logged in user I want to use my wallet to log in

I suggest that for 1 & 2, we just tell user they have to go make a new membership from scratch. For 3 this would also have been nice, but it risks alienating all current creators, so better to give them an option to connect their on-chain membership with a new Orion membership, which basically means they will need to provide password only (for which we don't bother with verification, as its not used for authentication), and then they will need to sign to login. So we need new flow for this.

As a logged in user who is not using a external wallet I want to know that a external wallet is a safer option when I have assets

I think this can be improved a bit, there is just tons of small text, people will think this is just like an error or something.

As a logged in user I want to manage settings of my membership

As a logged in user I want to buy my first asset

I suggest we just entirely drop this and go with alert approach based on hitting a certain state of ownership, not tied to a user action specifically.

As a not logged in user I want to go through YPP log in process

Requirements

Let us just kill this screen and instead show the failure if one of the actually verifiable metrics are not satisfied after the Google auth step. The content suitability can only be checked manually anyway, and there is lots of judgement there.

We have to show sign in with google on all screens

I don't see why this is the case. Sign in with google is not an actually way to authenticate in general, its a way to get someone started in YPP using non-signer key management, so they would use normal email+password. The steps are described here if you have not seen https://github.com/Joystream/youtube-synch/issues/182#issuecomment-1515086206.

Email+password skippable

No this is not accurate, I think this is what is confusing you here. The role of google is not to serve as the way in which you authenticate on Atlas in general, it is as a way to setup YPP synching and capture minimal metadata to generate your on-chain presence.

Public profile

I disagree with showing them any of this, people are at this stage not interested in populating it, this is sort of my point. Populating it is a chore, and actually a membership handle is even less useful for creators than consumers, as creators are always presented using their channel avatar in most cases. While using their channel avatar may seem like a good idea, this means they will get confused about the two concepts, and will in some places see the same image side by side in Atlas, so I don't think this is a good approach. I don't think Google exposes your actual google account avatar, as distinct from the YouTube avatar, however, even if it did, I don't think we can just race ahead and use this, because the person may not be expecting this will be used and put in the public, it may be sensitive. I suppose we could in this case present them with this as a default selection, which they can choose, but honestly its not worth the engineering effort to bother with any of this. I suggest we have some sort of classic alphabet style avatar we can use or something, or the default unset one. When they want to do stuff as a member in public, then they will have a reason to care.

So we drop this entirely, no screen is shown. I suggest the membership handle is just autogenerated to be something that has no conflicts and is a derivative of their youtube handle or channel name.

YouTube Sync

Lets slim this down to ask them what category it should be put in. Obviously they want to synch it, no need to ask that at any point, we just do it.

Creation Screen

Just like normal signup case, there has to be a blocking creation screen which is informing the user that a channel is being created, you cannot progress to a congratulations screen before that time, because this process can fail or take an arbitrarily long period of time due to

Success Screen

Just like normal signup case, we have to tell them the good new, but also, we need to tell them that synchronisation is ongoing and may take time. As captured in this issue https://github.com/Joystream/atlas/issues/4092, users risk being confused about status due to a proper success signal. Perhaps the model can have to stages, first one says congrats and the normal stuff about success, and the next stage focuses on the singular message that synchronisation is happening and it may take time before videos appear. I think, realistically, even with this, people are likely to ignore and move forward and still be confused, so we probably need some explicit information about this on the video page, however, this can help.

As a not logged in user I want to reset my password

By reset, I here assume you mean being able to change the password without having the current one, so recover the membership. This is not possible. The user can change their password, or their email for that matter, but that requires knowing both. If you forget them you are out of luck, if this was not the case, then it would mean the server can access your funds directly at all times, which we wanted to avoid.

As a logged in user I want to reset my password

I assume you are here talking about changing the password while knowing the current one, which is indeed possible, but recall that this requires a transaction which takes time, and can fail, so some sort of blocking dialog is needed here. There needs to be an identical story for changing email, which also requires the same sort of interaction. Importantly, same safety around inputing two times as during signup is needed, so a flow probably is needed, not inline editing. Perhaps just a single edit button would do it. As before, no email confirmation should be a blocker.

Lezek123 commented 1 year ago

This benefit of having the verification seems to me to be two-fold:

  1. Avoid someone using our infra to send out irrelevant emails to third parties. I have a really hard time thinking anyone would really bother doing this, because you would have to a go through a lot of work to break the CAPTCHA at some scale, then to and operate all those memberships to generate notification events, and through that spam someone. Financial payoff would be 0.
  2. The tiny share of sessions where people have a fat finger incident with their email will result in them not being able to login again.

I think there is another problem related to lack of e-mail verification, which is a DoS attack where someone can just create accounts using e-mails they don't own and effectively prevent the actual owner of the e-mail to use it when creating an account.

If we had "reset password" functionality this wouldn't be much of an issue, because the owner of the e-mail address would be able to use it to regain control over the account someone created for them, but it's not clear whether we'll have such functionality provided that resetting the password means that the membership and all internal-wallet assets are going to be lost.

I also think that 1. is actually more of an issue than it would seem. From my experience spambots and abuse of registration forms etc. are quite common problems and very difficult to deal with once the website gains some popularity, even when there is no clear indication of how exactly someone is benefiting from it. And it can easily damage the reputation of a website, for example, the e-mails we send can start being marked as spam by the spam detection software etc.

Also, I forgot to mention this earlier, although it seems quite obvious, but in case we're going to send any e-mails, we're going to need designs for those e-mails too.

bedeho commented 1 year ago

effectively prevent the actual owner of the e-mail to use it when creating an account.

This is a really bizarre activity, because you would effectively be wasting usafe of an email pool you somehow compiled, to just spam them, rather than abuse in some more deliberate way. Also, Keep in mind that whomever is doing this would need to actually know that this password recovery thing was not feasible to do this to even cause any long standing problem for these future users.

The UX & engineering cost + the fact that we can respond to this later, weighs quite heavy in my mind, but perhaps some product research can be done on best practices for this stuff, because I must assume someone has done some more empirical and systematic evaluation of this. Everyone is trying to simplify their signup flows after all.

For what its worth Audius does not require email confirmation during signup.

What do you think @KubaMikolajczyk , are you up for this?

KubaMikolajczyk commented 1 year ago

Thank you @bedeho @Lezek123 @dmtrjsg for huge amount of feedback 🙌🙇🫣 There is still a lot of work to improve this flow but with all your suggestions Im sure we are on a right track to achieve the perfect flow which will fit our particular scenario.

As there are just too many comments I will respond only to those where I see some room to add my 5 cents or share another point of view on some issue raised here. For all other comments, I already made a list of tasks needed to implement all improvements that you guys suggested into the designs for iteration v2, so if I don't address something here then I agree and the task is created on my backlog. ( Dont worry I have everything turned into action points :) ) image

@Lezek123

Thank you for all of the comments. As far as I can tell all of the issues you raised were addressed or also raised by Bedeho in his feedback so not to repeat my answers I will address them there, hope it's ok with you. If there is something that I missed and was not raised or answered by Bedeho please tell me and I will do my best to address that as well.

@dmtrjsg

7:38 can we not go with something more generic just to save time on implementation? E.g. This action requires to be logged in. CTA= Login

I would argue that the value we bring to the user by acknowledging what they just tried to do (while we rudely stopped them) is big and the implementation cost is low - its just copy changes in the very same component, not multiple custom components. So I would vote to keep the custom copy for each action type.

I would swap membership handle and T&Cs (place it right before email confirmation)

Wouldn’t it be better to just have a checkbox with I agree to T&C at the point of creating membership - it looks like Bedeho do agree with this notion - so if we are in clear on the legal side we could approach it this way to reduce the number of dialogs shown to the user.

address, could we see if placing it below the acc is not a visually more compact placement? 😇

I will explore different placements for it as Bedeho suggested a total rework of those dropdowns

37:04 I recall we agreed not to show anything on their first purchase, but simply show a banner overlay on top of the contextual screen when the value of the portfolio reaches X JOY. From that banner we would redirect to the user accounts where pros and cons of upgrade to signer would be explained with sufficient real estate

I agree - also see Bedeho’s remarks about the first purchase modal here and the changes suggested to the banner which effectively also includes removing separate section for it on the settings page

@bedeho

Improper use of Snackbar In my opinion we are using the snackbar for many unrelated types of events, not all of which make sense for the snackbar. In my opinion, they should be used for notifying user of events may occur at unpredictable time in the future w.r.t. triggering user action and that we want the user to be able to proceed and do other things in the interim. Here are some examples of things where we are using it which are inappropriate. Result of login failure when the login screen is still fully blocking the users ability to engage with anything else. In this case, error should in inline as prominent message in the login modal, not off in the corner, just like we do with form validation. Similar errors during membership creation. Membership creation success: The user should not be able to go off any do anything else as result of triggering the final step for the membership creation flow, they have to wait for the final outcome. Otherwise user will mistakenly believe they can do various actions despite creation possibly failing, or being backed logged - e.g. because transaction confirmation takes a long time. Telling the user they have logged in: Welcome back .... Again, they cannot proceed before login has worked, hence should not be a snackbar by the principle above, but more importantly I don't even think it serves any real user objective, they know they have logged in when they progress. Telling the user that something is being created. NB: realise that we may already be breaking this principle from before, and I certainly don't want us to now simultaneously try to introduce user accounts and changes this behaviour across the app, but I would certainly not want to pile on.

I don't know if I share the same view on snackbars. Snackbars are mostly used across various systems to give easy feedback to the users about the process that an app has performed or will perform. (See different snackbar documentations: material design, Lightning design system ) So as I understand it snackbars (or toasts) is just a tool we have to give user some non-intrusive feedback. Is is the right tool to use in each scenario? Definitelly not and each scenario should be considered individually.

I will look into each of those examples but I wouldn't discard the snackbar feedback so soon as it gives us a lot more options to inform user about an error in any other case then simple validation errors which we can handle with simple inline error, but that's only one example.

A notice to use a password manager? is it worth it?

I don't know if this is something we need (or should) include here. If a user is already using a password manager then this tip is not new for them, and if someone doesn't - I doubt we can influence them to go out and start using one at the point of membership creation. So from my POV I don't think its needed.

Remember that when the user picks a membership, they will need to sign a message that will be sent to Orion to prove that the user genuinely controls relevant member, and only then expose data in backend that is for this user, or allow user to set settings

Do you mean that the user will have to sign the transaction after choosing membership?

Notifications for channels should not be here, they should be under the settings for that channel, not only for UX reasons, but also just because a single member may have many channels.

I will try to include them on the studio side then and in the channel dropdown. Let me explore this and suggest a solution.

Is it really needed to have distinct setting for email and in-app? I know we did that in Pioneer, but I don't recall seeing that in other apps, perhaps double checking on that makes sense?

Yes, it is generally considered a standard pattern to allow users to manage their notification settings for both email and in-app notifications in a web app. This gives users greater control over their experience and allows them to tailor the notifications to their preferences and needs. Providing users with the ability to customize their notification settings can also reduce the likelihood of them becoming overwhelmed or frustrated by too many notifications, which can lead to them disengaging with the app.

It is also a standard pattern used across many web apps:

Facebook - Push, email and SMS (separately)

image

Linkedin - Push, email and in app

image image

Twitter - email and push (when enabled)

Twitter divides it to two separate pages though image image

I assume the notification list here is just symbolic, but can we pin down the precise list? Weekly summaries, payouts, there are many we can consider.

Yes we should do this. The effort to collect all of the options will be big enough for an issue of its own though.

The UX & engineering cost + the fact that we can respond to this later, weighs quite heavy in my mind, but perhaps some product research can be done on best practices for this stuff, because I must assume someone has done some more empirical and systematic evaluation of this. Everyone is trying to simplify their signup flows after all.

While having a CAPTCHA included in the process of creating an account can help to prevent automated bots from creating accounts, it is still recommended to include an email confirmation step as an additional security measure. With that said lets look at the PROs and CONs of including an email confirmation as a step in account creation flow:

PROS

  1. Verifies the user's email address: Email confirmation ensures that the email address entered during the account creation process is valid and belongs to the user.

  2. Prevents fake accounts: Email confirmation helps to prevent fraudulent or fake accounts from being created, as users must confirm their email address before being able to access the account.

  3. Provides additional security: Email confirmation can serve as an additional layer of security in case the CAPTCHA is bypassed or fails to detect automated bots.

  4. Improves account management: Email confirmation can ensure that users can receive important account-related notifications and password reset emails.

  5. Improves user experience: Email confirmation can provide users with a sense of security and trust in the web app, which can improve their overall experience.

CONS

  1. Adds an extra step to the account creation process: Including an email confirmation step can make the account creation process longer and more complex, which may deter some users from completing the process.

  2. Can result in email delivery issues: Some email services may mark the confirmation email as spam or delay its delivery, which can create a frustrating experience for users.

  3. Can result in lost or mistyped email addresses: Users may mistype their email address or enter an invalid email address, which can result in lost accounts or require additional support to correct.

  4. Can result in abandonment: Some users may abandon the account creation process if they do not receive the confirmation email in a timely manner or encounter other issues with the confirmation process.

  5. Can be perceived as intrusive: Some users may perceive the email confirmation process as intrusive or unnecessary, which can create a negative perception of the web app.

Conclusion

Overall, including email confirmation in a web app can provide important benefits in terms of security, verification, and account management, but it can also create additional complexity and potential issues. In our specific scenario, I feel that the cons outweigh the pros and if we feel that our CAPTCHA is giving us enough protection we can resign from email confirmation pattern to reduce complexity of the flow. Wdyt?

bedeho commented 1 year ago

I will look into each of those examples but I wouldn't discard the snackbar feedback so soon as it gives us a lot more options to inform user about

I think the best way for me to understand is to see some example cases in our current product, or even a hypothetical product, where it makes intutitive sense to me to use a snackbar, despite violating the principle I stated.

I think though, in some cases, having a consistent rule has considerable value for the user across a range of use cases, because it creates a very clear set of unstated expectations about how the product works. Even if you in one isolated case can see that a snackbar works fine, or is even optimal, the cost of not having an overarching simple principle of communicating witht he user across all cases in the product may be too high.

Do you mean that the user will have to sign the transaction after choosing membership?

Correct, because the server does not know that the user has the credentials for this membership, the browser could simply "fake it" can thereby have access to private data on the server for that member.

It is also a standard pattern used across many web apps:

Ok, lets keep then.

Wdyt?

I appreciate that you did this breakdown, I don't entirely agree with all points here, but this further reinforced my conviction about starting without email confirmation. Let me review the points

PROS

Verifies the user's email ... ensures that the email address entered during the account creation process is valid and belongs to the user

This is not a direct benefit, it just restates what happens.

Prevents fake accounts

This is not really true, you can make fake accounts in that they are all controlled by a bot or something even with email confirmation, its 100x harder to break captcha then to setup a new mail server or just buy 100000 gmail accounts for 50 bucks. So this really boils down to what exactly we mean by fake here, and what the person is trying to do that we consider bad.

Provides additional securit

If you by security here mean for operator, then I guess this is just restating the same as the prior point? its hte same hypothetical benefit.

Improves account management.. can receive important account-related notifications and password reset emails

Firstly, importantly be aware that password reset - in the recovery sense, is not possible. just have to make sure you are catching that. Second, recall that I am proposing that user inputs email twice, just as password is inputted twice, now - that does not make it impossible for the user to input an incorrect email, so this is a PRO, the magnitude of this seems extremely low given how unlikely that seems.

Improves user experience: Email confirmation can provide users with a sense of security and trust in the web app

Ok, I don't subjectively feel this applies to me, but I guess this can be true for some people? Is this a known thing?

CONS

Can result in lost or mistyped email addresses: Users may mistype their email address or enter an invalid email address, which can result in lost accounts or require additional support to correct.

I strongly doubt it, see my point above.

Can be perceived as intrusive: Some users may perceive the email confirmation process as intrusive or unnecessary, which can create a negative perception of the web app.

Yeah this is more me than the other one, it sets me up to expect I'm going to receive a shit ton of emails from these people. :D

KubaMikolajczyk commented 1 year ago

@bedeho @dmtrjsg @Lezek123 @attemka The first part of implementing the above comments into the designs is ready to be reviewed ✅ Still there are parts of this issue that needs to be addressed like settings or external wallets, but If there will be no bigger changes then sign in & sign up flows will be ready to be implemented when I'm off, please leave your feedback here and I will tackle it when I come back. 🎥 Loom video: https://www.loom.com/share/2b5cf29d0ccc401eb1ce48deb3a3df93 📄 Figma file: https://www.figma.com/file/C3hvYPVkZ7TcjAsXfqizSD/User-accounts?node-id=2076%3A106193&t=pr1CoPkxLNk9Fp7d-1

bedeho commented 1 year ago
  1. Thank you for this @KubaMikolajczyk
  2. Logo+subtitle: I was actually just referring to the long flows, not the initial pages. I agree with you that it looked more appealing, and I also think there is some utility for individual apps to show off their brand a bit. While you did not show the diff. in how this appears for all the other deeper screens which have more content, I'm cool with sticking to it as you said.
  3. Celebration variation #2 looked better, at least if the user set the avatar.
  4. Logging in with external signer also requires interaction with backend, which may have arbitrarily long delays or fail, so a logging in dialog would be needed.
  5. It occurs to me that it would be better ot have some motion or someting in the logging in dialog, so as to signal to the user that the app has not frozen or stalled when it takes a while.

Enjoy your trip 🗺️ !

KubaMikolajczyk commented 1 year ago

Thank you @bedeho for the feedback 🙇 below I post a list of actionable tasks from your feedback, discord conversations and figma comments:

KubaMikolajczyk commented 1 year ago

Tasks above ready to be reviewed ✅ 🎥 Loom walkthrough (10min) : https://www.loom.com/share/e8a318c95f61451c8e93023fc3af081a 📄 Figma file:https://www.figma.com/file/C3hvYPVkZ7TcjAsXfqizSD/User-accounts?type=design&node-id=2076%3A106193&t=iRl0ti8IjCbeYnDu-1

KubaMikolajczyk commented 1 year ago

Hi @bedeho @dmtrjsg the next round of explorations with feedback implemented Is ready to be reviewed for following parts:

  1. Membership settings
  2. Channel settings
  3. External wallet banner 🎥 Loom video: https://www.loom.com/share/6369f1ea9e9a4bd69e58b07be768e230 📄 Figma file: https://www.figma.com/file/C3hvYPVkZ7TcjAsXfqizSD/User-accounts?type=design&node-id=2333-70682&t=JMMpyZ6V44gG9VlX-4
bedeho commented 1 year ago

Wow, that was quick? did not even have time to review the other one yet!

bedeho commented 1 year ago

Ok, here is my feedback to both

Update 1

Update 2

dmtrjsg commented 1 year ago

Update 2 my 5 cents:

  1. Notiffs on channels are better as well.
  2. Customisation -> General (not sure if Profile is the right one for the channel mgt.. )
  3. Banner, liked the one with icons as looks more convincing.
  4. For notifications design I am not sure if we need those grey bars to seaprate the sections or the header, looked a bit too heavy for me. Perhaps was better placed when we had to distinguish member vs channel notiffs on one page, but since its now departed we could make the styling it a little lighter imho.
KubaMikolajczyk commented 1 year ago

After feedback from you @bedeho I updated the already existing "sign in flows" with all those changes which we arrived at during the work on user accounts. So now here is the final update where I show the new updated file and talk about small changes made to the flows and your feedback implemented: 🎥 Loom video: https://www.loom.com/share/6a79ef0562f14b08a20157b54052857b 📄 Figma file: https://www.figma.com/file/ymHYOFItrmFaLeBC5Z4tpQ/Sign-up-%2F-Log-in?type=design&node-id=2013-33819&t=gELGmRrytcvLKj93-4

(Should be watched by anyone who is currently implementing this - @drillprop ? 🫣 )

bedeho commented 1 year ago

Looks good, seems like there is nothing for answer here 👍

KubaMikolajczyk commented 1 year ago

Hello @dmtrjsg @bedeho the next part of the work is ready - which is the full update of the membership profile page along with the implementation check where I found a few minor bugs and areas for improvement. (The video cuts unnaturally at the end because loom crashed 🫣 but I was just about to end so its fine)

🎥 Video update: https://www.loom.com/share/dc3ab342a7c74aa781311470dcb24741 📄 Figma file: https://www.figma.com/file/yhZpTHdf1sxJx13uRZ71GV/Membership-profile?type=design&node-id=2912-46498&t=JbEjRyNfaEhbN1WF-4

The next part of work coming which I'm currently working on will be the membership settings user stories and its RWD 🙇‍♂️

bedeho commented 1 year ago

Great work, I don't think I have anything which can help you in terms of remarks or review.

KubaMikolajczyk commented 1 year ago

Hello @dmtrjsg @bedeho the work on membership settings is done and ready to be reviewed :) We have final designs, pages, flows, RWD and components to talk about. 🎥 Loom video: https://www.loom.com/share/3f695a0e18c3482a811ebe4eb5ed65ad 📄 Figma changelog: https://www.figma.com/file/yhZpTHdf1sxJx13uRZ71GV/Membership-profile?type=design&node-id=2912-46498&t=Av2IycF5ecJcNIka-4

Next will be coming the updated "my channel" page along with channel notifications settings added to that :)

KubaMikolajczyk commented 1 year ago

Hello @bedeho @dmtrjsg my channel update is here ready to be reviewed ✅ Updated my channel pages, flows, RWD, components, new simple way to create channel and new ways to access channel settings page & my videos page for the channel owner - all of that is here :)

🎥 Loom video: https://www.loom.com/share/cfe74250346c451c9f68e5e6195b3a03 📄 My channel figma changelog: https://www.figma.com/file/zi5siPUXme0Fivq2i40XBd/My-channel?type=design&node-id=703-5383&t=pko14pd4Ay5u1DXI-4 📄 Channel figma changelog: https://www.figma.com/file/POw4j95jszfIP5bGfas2IC/Channel?type=design&node-id=2386-171791&t=undP2CiNqHPBoRxH-4