5 ms·
This seems to be a common problem, made more visible when using third-party authentication, that your application has taken the concepts of "Account" and "Authe
by persona 6y ago
This seems to be a common problem, made more visible when using third-party authentication, that your application has taken the concepts of "Account" and "Authentication Method" as if they were the same thing.
It appears that the "account ID", "preferred contact method+address" and "authentication ID" are all the same here - which then creates the "account management code into a rat’s nest" scenario they describe in the post.
If an Account is, by design, it's own entity - you should be able to have 100 different authentication methods linked to that same account without impacting any other flow or part of the application.
Turn on and off authentication methods would also allow for seamless transition for users, without worrying about when one method is about to be killed.
- dukoid 6y ago+1 Any authentication method that I have enabled for my email should work -- there shouldn't be a need to remember which one is associated with a particular service...
- dahfizz 6y agoI feel like they address this in the article. What you say makes sense in a technical UML diagram point of view, but that's not how people work. The examples they give are getting support and sharing things with another person with an account. As a user, both of those things are easier for me if there is an email associated with the account. Said another way, the Account needs some human friendly global identifier. The email you use to log in is an obvious choice, and anything else would require extra work from the user to set up. You could have usernames, for example, but that complicates the signup process and still makes sharing things hard. I know my friends emails already, but I don't know what username they ended up with on this site.
- persona 6y agoI'd argue that this makes more sense in the real world than in a diagram, after being burnt in multiple real life experiences :) The assumption both you and AnyList are making is that an email is "THE obvious choice". From a user experience perspective perhaps this "global sharing identifier" should be defined by them. You'll notice that different generations have different online behaviors. For some, email is their main id. For others, it's their phone number (they don't know most of their friends' e-mail, but know their phone). For others, it's either online handles or nothing at all - think about the device set up for grandma with her daily To Do list. Of course, having this approach would add some upfront dev work to them but allow them to navigate this much easier later on. And for anyone starting to develop their new app/site/product thinking about this early on can reduce a lot of future headaches.
- JAlexoid 6y agoThat's a very idealistic opinion. People don't care about usernames and other crap. They want an easy option - enter email, communicate over email and be found using email. This isn't their banking app or anything that important.
- filleduchaos 6y agoNobody "wants to use their email". They just want to start using whatever app or service they're trying to connect to as quickly as possible - why exactly do you think "Sign in with X" became so popular in the first place?
- mr_toad 6y agoI don’t see any technical reason this couldn’t be done, but it would be more work for both the app developers and the user.
- JAlexoid 6y agoTime and value are not "technical", though they can be measured. Technically you can build an app that's purely a AR sticky notes specifically on your fridge... but the value of that app is approximately 0.
- gitgud 6y agoI think the problem is that many apps, use the same form for login/signup. So a user thinks they're logging in, but they're actually creating a new account with a new authentication method...
- nikitaga 6y agoWith rare specialized exceptions, pretty much nobody needs all this complexity. Certainly not a simple app like AnyList. All this flexibility is not free, it comes at the cost of obviousness, as they described. It's not worth it much of the time. The real problem is Apple shoving their proprietary, poorly designed services down everyone's throats. No, I don't want to use icloud email, I already have an email address. No, I don't want to provide a "real" email address after I provided an obfuscated one. No it's not my fault that messages sent to the obfuscated one will go to some icloud inbox that I didn't create and I don't read. No, it's also not my fault that when I contact support I do it from my normal email address and not from the obfuscated one (how would I even do that). It's not the support's fault that they can't connect the two. It's not the user's fault, and it's not the developer's fault. Apple is the sole designer of this mess. There is no excuse.
- dev_tty01 6y agoYou can create an iCloud account with your own email address. That avoids getting another email address. When using Apple login, Apple offers the choice of providing an anonymous email to the third party or your actual email. It's up to you. Its about user choice. More privacy or less. Apple wants you to have a choice. Use it or not.
- nikitaga 6y agoThen why do most of my non-tech relatives have an @icloud.com address that they never needed and never read? Blame the user all you want, but their "choice" was guided by Apple designed UI and Apple provided defaults. Whatever it is, it's producing optimal outcomes for Apple and no one else.
- fnordsensei 6y agoI have one too (which I've since swapped for an email I actually use). I'm not one hundred percent sure, but I think it was the only option for a while (inherited from MobileMe, perhaps), or at least it wasn't clear that you could/should add another email. Either way, Apple could definitely do something with regards to make it easier/more obvious to replace it with a useful email address, especially now as it becomes a federated identity provider.