We may fail to design registration-free user interface

[yegor256]

migrated from Trac, where originally posted by yegor256 on 7-Sep-2010 11:20am

The core idea behind the netbout.com system is the ability to establish online communication "bouts" between people one of who doesn't know anything about netbout, and doesn't have a netbout account. It should work like the following:

1. I have an account with netbout.com
2. I create a new bout with john@example.com
3. John receives an invitation email from netbout.com
4. John clicks the link in the email
5. John answers me in the netbout.com we page just opened
6. I reply to him and we keep talking this way

John never registers an account with netbout.com. He just talks with me, and the system remembers him. Once he wants to register an account, he can do it, and the system will attach everything that happened before to the account created.

I don't know yet how to design this mechanism properly, and what technologies we should use. My key questions:

• shall we use cookies? is it secure enough? is it convenient for the user? what if he/she changes the computer?
• what about OpenID? maybe it will help?
• what if email message is lost? or the link inside it is broken (by mail reader)?
• how about SMS interface, when the user replies without even visiting of netbout.com website? can we take this into account for the future?

There will be more questions once we make a decision about the technology to use.

[yegor256]

migrated from Trac, where originally posted by yegor256 on 7-Sep-2010 11:20am

motivated by #2

[yegor256]

migrated from Trac, where originally posted by yegor256 on 20-Sep-2010 2:34pm

I'm suggesting a mitigation strategy for this risk, with the following response plan:

We identify a number of "entrance scenario", each of which will explain how people may get together in a bout. The list of scenario should be complete, meaning that it has to include all possible scenario. Then we review this list and make sure that SRS has required functionality explained for every scenario. Found inconsistencies will be fixed (in SRS).

If anyone has any other ideas on how to mitigate the risk explained in this ticket, please suggest here.

[yegor256]

migrated from Trac, where originally posted by netcoderpl on 22-Sep-2010 12:57pm

I think we can have this scenarios when somebody want to invite other person

Inviter can be:

• user who was registered' (has record with his 'ID, and optionally email)
• user who was not registered' (was invited earlier - has record with 'email)

Invited person can be:

• somebody who has no account (has no record in user table)
• user who was registered' (has record with his 'ID, and optionally email)
• user who was not registered' (was invited - has record with 'email)

I think during sending invitation, to person with no account we should:

• insert record to user table with email of invited person, and some temporary password
• insert record to invitation with some secretKey
• send email to invited person with this secretKey
• when invited person click on Accept we will basing on invitation secretKey identify invitation and invited user. We will set cookie with temporary password inserted earlier in user table. Thanks for that we can identify users without registration.

Please write what you think about this concept.

[yegor256]

migrated from Trac, where originally posted by yegor256 on 26-Sep-2010 7:25pm

I think that it's good, but let's create a new ticket, where we will "respond" to this risk.

[yegor256]

migrated from Trac, where originally posted by yegor256 on 26-Sep-2010 7:33pm

see ticket #71

[yegor256]

migrated from Trac, where originally posted by yegor256 on 26-Sep-2010 7:38pm

besides that, the idea about invitation table doesn't look very good for me, see ticket #69

[yegor256]

migrated from Trac, where originally posted by yegor256 on 22-Nov-2010 10:49am

see #78 and #75 for OpenID discussion

[yegor256]

migrated from Trac, where originally posted by yegor256 on 22-Nov-2010 10:49am

see UC2 specific section on communication scenarios

[yegor256]

migrated from Trac, where originally posted by yegor256 on 22-Nov-2010 10:52am

Looks like this risk is mitigated:

• we will use cookies for session persistence
• we will use both OpenID and email/password authentication
• we will try to keep netbout behind the scene as much as possible (see UC2)

In all other aspects the site will work as a normal HTTP system.

[yegor256]

migrated from Trac, where originally posted by yegor256 on 23-Nov-2011 9:06am

Milestone JUN11 deleted