Hi, I'll just dive right in and say what I think about the issues sandy brought up. > == Do We Need Unique User Names? == > > If we already have display names, which are the names shown everywhere > in the UI, then are unique user names necessary? We could just refer > to unique users by their internal user ID, and use that in URLs. What > do we lose if we do that? > > * Our URLs become less human-readable, which could be irritating when > searching web or URL bar history > * We have no human-readable unique name for our users. Two users > could pick the display name of "John Thomas", and then one day you > might get a sharing request from "John Thomas" and not know who is > meant. "John Thomas (jthom)" might be more useful? This isn't a > problem for Facebook, but they collect a lot of information that makes > it possible to verify a stranger's identity. > * If we ever have a feature (in Tomboy or Snowy, whatever) where > typing in a unique user name is necessary, numbers are much more of a > pain > * Reading JSON responses becomes more tedious for developers > > I don't know if it's less work to have unique user names now, or to > allow them as a future option. I think unique usernames are important, especially for sharing. For sync-only users who mainly want to backup their notes and maybe look at it them occasionally, it doesn't really matter that much I think. From a technical perspective, the user account gets created with an auto-generated ID anyway. Sandy suggested on IRC that the user account should not be created until after the user has given some details. I think it would be a better idea to create the user account with an ID at first and require the user change his username in the next step. That way if we decide not to require a username in the future, we simply remove the form field to change the username. In the far future, we could even remove the requirement for an email address so the user could just enter his OpenID and start syncing his notes! Another option for the future would be to only require user details once the user actually starts using the site. That way we could keep the sign-up process for syncing-only users clean. (Also this solution is way easier because putting in another registration step after the OpenID login is not that easy to do) > When the user comes back from authorizing their OpenID, we do need > some information from them: > > * Email address > * Some human-readable name for them, unique or otherwise > > We could potentially ask for other (optional) information, but the two > items above are all that we absolutely need (although the question of > whether or not we really require an email address is perhaps worthy of > a separate discussion). > > But I propose we ask for three things, because I think a unique > human-readable user name is important: > > * Email address (can be mined from some OpenID providers) > * Display name (for example, "John Smith", can be mined from some > OpenID providers) > * Unique user name (initially generated from from one of the above values) We don't actually need the human-readable name (I only created that as a workaround because I thought changing the username was impossible, turns out it works perfectly fine). I agree that requiring a unique username would be a good idea as well. Technically, none of the information is required though. > If the email address and display name can be mined from the OpenID, > all that's left before a user is done registering is a unique user > name. This could be initially generated from everything before "@" in > the email address, or from the display name, or something. Interested > users could modify it, others could just ignore it and use the > generated value. The library we use currently doesn't support the protocol that Google uses but that could be added. I think that having as much of the registration process auto-filled is important for a smooth sign-up process. All in all, I agree with sandy that we should require a username, a display name and the email address for now. I'll adapt my code in the next few days (an extra form field + a lot of polish is needed). Leon
Attachment:
signature.asc
Description: This is a digitally signed message part