It would help to see what it looks like with multiple users expressing partially overlapping interests.
I think perhaps 'interests' should be, initially, independent from the user(s) that expressed it. Maybe just indicate interests, and a count of many people have expressed them, then clicking on an interest could give you more about those users.
As I user, I would expect to register, and then either '+' the existing interests that I also have, or add new ones. The taxonomy of 'interests' is probably the hardest thing to get right.
You're re-inventing a lot of UI paradigms, like editing an interest by clicking into something which doesn't look like an input field, and then clicking away to save it. You won't need to explain as much how to use it if you stick to more typical CRUD patterns. I'm not a fan of showing each interest in a rounded rectangle, and I don't think it will scale very far...
To verify an account is owned by a given user, you could ask them to (temporarily) add a code into their 'about' field.
You might get more registrations if you didn't ask for an email address.
I added some examples with a throwaway account. My hope is that this would become more intuitive as people use this and there is content available.
I think your second idea is awesome, I'll go ahead and implement this next, thank you!
Can you elaborate a bit on your third point? I'm probably misunderstanding but it sounds like the flow you're describing is currently implemented.
Another great idea here. To anyone else reading this, would you mind temporarily adding a code to your about HN 'about' field? This would replace the need for me to ask for an email (the only thing I use that for is identity verification).
To be secure, your app would tell the user what code to add. So after I tell you I'm 'zaroth', you say please add 'gHypQwnm' to your about (show a link to https://news.ycombinator.com/user?id=zaroth) and a link 'Verify'.
I add it, submit, click back twice, click verify on your site, and then go back to my HN profile and remove it. It sucks from a user interaction standpoint, but better than asking the user for their HN password!
The password I am asking for is completely independant from your HN password. I make note of that in the text underneath the form area but you are not the first person to assume that I'm referring to one's HN password. You are absolutely right though, as a user, I would never give up my HN password to a random 3rd party. Your authentication implementation idea completely sidesteps any ambiguity - I'm going to go ahead and move towards this as soon as I can. Again, thanks for your feedback!
I think perhaps 'interests' should be, initially, independent from the user(s) that expressed it. Maybe just indicate interests, and a count of many people have expressed them, then clicking on an interest could give you more about those users.
As I user, I would expect to register, and then either '+' the existing interests that I also have, or add new ones. The taxonomy of 'interests' is probably the hardest thing to get right.
You're re-inventing a lot of UI paradigms, like editing an interest by clicking into something which doesn't look like an input field, and then clicking away to save it. You won't need to explain as much how to use it if you stick to more typical CRUD patterns. I'm not a fan of showing each interest in a rounded rectangle, and I don't think it will scale very far...
To verify an account is owned by a given user, you could ask them to (temporarily) add a code into their 'about' field.
You might get more registrations if you didn't ask for an email address.