Closed ChristinaSi closed 5 years ago
I assigned the issue to you, @dboehmer because you have to check the necessary fields first.
Currently the database design and the registration process actually needs all of these fields. I am not quite sure which one we could drop.
I've been thinking about the properties of a user for a long time because it seems to be hard for people to understand username and display name. I copied this concept from Twitter: People will need one's username to grant them permissions on their projects. That's why usernames need to be
But human names aren't–so many platforms allow to set a display name that might
Of course we need an e-mail address to provide simple account management like password reset or notifications.
Is it a good idea to require users to enter other users' e-mail address to identify them? They shouldn't need to know that, I think.
What else could be used to identify other users? At Facebook there's no such thing as a username (I believe) but Facebook knows your known contacts AKA "friends". I think Coocook won't benefit from connecting users as "friends" in order to give them permissions.
So currently the database requires that all of username, display name and e-mail address. Because I have no idea how to save a property, I return this issue.
Currently the database design and the registration process actually needs all of these fields. I am not quite sure which one we could drop.
I've been thinking about the properties of a user for a long time because it seems to be hard for people to understand username and display name.
Right, that’s the point … If you’re not sure about which criterion to drop, what about solving the issue by slightly changing the label. E. G. "user name" is already far more clear and personal than „login name“.
I copied this concept from Twitter: People will need one's username to grant them permissions on their projects. That's why usernames need to be
* unique, * unambigious and * easy to type on any keyboard and * should be static.
But human names aren't–so many platforms allow to set a display name that might
* change, * include special characters or * be non-unique.
Of course we need an e-mail address to provide simple account management like password reset or notifications.
Is it a good idea to require users to enter other users' e-mail address to identify them? They shouldn't need to know that, I think.
… yeah, but they mostly do. Moreover, from a users gut feeling, entering one’s email adress allows drawing far less conclusions than typing a first and last name. On the other hand, mentioning a whatever name on the platform will trigger a far more individual impression as we can adress people directly. It’s perfect to referring Twitter here as they implemented exactly this idea, as far as I can see (pls see https://twitter.com/i/flow/signup). I completely agree with you about creating unique user names. But if they’re not, what about providing users with corresponding notifications and help? This is an even more conversational approach.
Of course, we could also collect additional user data as a follow-up, but I don’t consider this an ideal solution in this context.
What else could be used to identify other users? At Facebook there's no such thing as a username (I believe) but Facebook knows your known contacts AKA "friends". I think Coocook won't benefit from connecting users as "friends" in order to give them permissions.
So currently the database requires that all of username, display name and e-mail address. Because I have no idea how to save a property, I return this issue.
If you have doubts, it's fine for me to keep the process as it is, maybe with the label slightly changed (pls see above). Or let’s simply rethink about it when meeting next time. Just thought about demanding to many user data.
@dboehmer Is there still something to do here? I moved the labels to the left today.
I didn't close the issue earlier in case you had any concerns:-)
@cncpl suggested we should simplify the register page according to the picture.
Important:
Check which fields could be omitted
Rearrange register page according to the picture