suggested User ID's

23 Nov 2005 - 1:21am
9 years ago
57 replies
1762 reads
Tricia (Bluesky...
2005

Hi everyone,

I am investigating the possibility of using suggested user ID's for a
registration system.

My gut feel says that users would still opt for creating their own user
ID's even if it takes them quite some time to find one that is
available. I also feel it will be easier for the user to remember his
User ID if he creates it himself.

So far I've found the following suggested User ID variations:

- The user is given x number of suggestions based on the User ID he
asked for, the variations consisting of numbers that are attached to the
end of the requested User ID
- The user is asked to name 3 favourite things, for example sport,
animal, color and then x number of suggested User ID's are presented to
the user for choosing.
- The user is presented with x number of suggested user ID's that are
generated by the system using two adjectives and a noun from a large
dictionary.

Does anyone know of any reports or studies that have been done on this?

Any help you could forward on will be much appreciated
Thanks
Trish

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
Furthermore, the information contained in this message, and any attachments thereto, is for information purposes only and may contain the personal views and opinions of the author, which are not necessarily the views and opinions of the company.

Comments

23 Nov 2005 - 1:39am
dszuc
2005

It is possible to allow the user to use an email address as the User ID? It
may also be one less field you need to include on the registration (as the
UserID doubles as an ID to login and email address - which is unique)

Daniel Szuc
Principal Usability Consultant
Apogee Usability Asia Ltd
www.apogeehk.com
'Usability in Asia'

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com
[mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of Tricia
(Bluesky Consult)
Sent: Wednesday, November 23, 2005 3:21 PM
To: discuss at ixda.org
Subject: [IxDA Discuss] suggested User ID's

[Please voluntarily trim replies to include only relevant quoted material.]

Hi everyone,

I am investigating the possibility of using suggested user ID's for a
registration system.

My gut feel says that users would still opt for creating their own user ID's
even if it takes them quite some time to find one that is available. I also
feel it will be easier for the user to remember his User ID if he creates it
himself.

So far I've found the following suggested User ID variations:

- The user is given x number of suggestions based on the User ID he asked
for, the variations consisting of numbers that are attached to the end of
the requested User ID
- The user is asked to name 3 favourite things, for example sport, animal,
color and then x number of suggested User ID's are presented to the user for
choosing.
- The user is presented with x number of suggested user ID's that are
generated by the system using two adjectives and a noun from a large
dictionary.

Does anyone know of any reports or studies that have been done on this?

Any help you could forward on will be much appreciated
Thanks
Trish

The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you received
this in error, please contact the sender and delete the material from any
computer. Furthermore, the information contained in this message, and any
attachments thereto, is for information purposes only and may contain the
personal views and opinions of the author, which are not necessarily the
views and opinions of the company.

________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss at ixda.org
(Un)Subscription Options ... http://subscription-options.ixda.org/
Announcements List ......... http://subscribe-announce.ixda.org/
Questions .................. lists at ixda.org
Home ....................... http://ixda.org/
Resource Library ........... http://resources.ixda.org

23 Nov 2005 - 2:03am
Navneet Nair
2004

>
> It is possible to allow the user to use an email address as the User ID?
> It
> may also be one less field you need to include on the registration (as the
> UserID doubles as an ID to login and email address - which is unique)

As an additional advantage, people are less likely to forget their emails
(or at least won't have more than 3-4 to choose from). More often than not,
I forget the user IDs and sometimes, there are password retrieval systems
that force you to enter the user ID, so I pretty much have had to abandon
those accounts...

----------------------------------------------------
Navneet Nair
Interaction Architect
onClipEvent: form follows function();
----------------------------------------------------
Website: http://www.onclipevent.com
Blog: http://www.onclipevent.com/enterframe/

23 Nov 2005 - 2:13am
Tricia (Bluesky...
2005

Unfortunately for this system the User ID identifies the user to others
users so it can't be the e-maail address. I do agree that e-mail address
is the better of the User ID's if it is used just to sign in with.

Thanks for the comments so far
Trish

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com
[mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of
Navneet Nair
Sent: Wednesday, November 23, 2005 10:04 AM
To: Daniel Szuc
Cc: discuss at ixda.org
Subject: Re: [IxDA Discuss] suggested User ID's

[Please voluntarily trim replies to include only relevant quoted
material.]

>
> It is possible to allow the user to use an email address as the User
ID?
> It
> may also be one less field you need to include on the registration (as

> the UserID doubles as an ID to login and email address - which is
> unique)

As an additional advantage, people are less likely to forget their
emails (or at least won't have more than 3-4 to choose from). More often
than not, I forget the user IDs and sometimes, there are password
retrieval systems that force you to enter the user ID, so I pretty much
have had to abandon those accounts...

----------------------------------------------------
Navneet Nair
Interaction Architect
onClipEvent: form follows function();
----------------------------------------------------
Website: http://www.onclipevent.com
Blog: http://www.onclipevent.com/enterframe/
________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss at ixda.org (Un)Subscription Options
... http://subscription-options.ixda.org/
Announcements List ......... http://subscribe-announce.ixda.org/
Questions .................. lists at ixda.org Home .......................
http://ixda.org/ Resource Library ........... http://resources.ixda.org
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
Furthermore, the information contained in this message, and any attachments thereto, is for information purposes only and may contain the personal views and opinions of the author, which are not necessarily the views and opinions of the company.

23 Nov 2005 - 2:38am
Ripul Kumar
2005

Hi Tricia,

The sad truth is that humans are really forgetful creatures. Our neurons need strong cues for a strong synaptic connection.

The other sad truth is that computer users have accounts with many websites and they need to remember username and password for each. However, we have seen that users typically have a small bank of usernames (and email addresses) and passwords that they use. Any deviation from this results in clicking "forgot password" link. In any system prompted change in the password, the user usually forgets the new password. And, the cycle continues.

There are only a few of us who maintain an Excel record of the website, username, and password or use PostIt notes to remember. Those who do this ensure that they remember usernames, but on the other hand make themselves very vulnerable.

Tricia, after examining each of your suggestions, I can clearly see that many users WILL forget their username within no time. This is especially true for people with common names (go figure!). This will also be true for people who do not log in frequently--higher frequency enhances synaptic bonds between ne.

I am sure there would be a lot of flame this suggestion, but here it is anyway:

As username and the corresponding password make a unique key together, why should the system ask for a unique username? Many user problems lie in making the username unique. Can we do away with unique usernames? Let the combination be unique. This may solve "remembering the username" problem to an extant.

Some have tried to solve unique username problem by replacing usernames with email addresses. This is a better solution in many ways but also has its fair share of usability issues.

- Ripul

--
Ripul Kumar
Director, Usability Consulting
Kern Communications Pvt Ltd, India
www.kern-comm.com

23 Nov 2005 - 2:55am
Tricia (Bluesky...
2005

I am still tied in to the requirement that the User ID needs to identify
the user to other users on the system. I can't have two users with the
same User ID.

Assuming I didn't have this requirement, does your suggestion mean that
one could have the instance of two users with the same user name and
password? Surely if security was a requirement then this would be an
issue?

On another note, where the user ID isn't needed to identify to the user
to other users I have also seen the suggestion of having only a unique
password to login to a system. It is true that only 1 unique unknown
input is needed to identify a user to a system.

Looking forward to further respsonses
Thanks
Trish

-----Original Message-----
From: Ripul Kumar [mailto:ripulk at gmail.com]
Sent: Wednesday, November 23, 2005 10:38 AM
To: discuss at ixda.org
Cc: Tricia (Bluesky Consult)
Subject: Re: [IxDA Discuss] suggested User ID's

Hi Tricia,

The sad truth is that humans are really forgetful creatures. Our neurons
need strong cues for a strong synaptic connection.

The other sad truth is that computer users have accounts with many
websites and they need to remember username and password for each.
However, we have seen that users typically have a small bank of
usernames (and email addresses) and passwords that they use. Any
deviation from this results in clicking "forgot password" link. In any
system prompted change in the password, the user usually forgets the new
password. And, the cycle continues.

There are only a few of us who maintain an Excel record of the website,
username, and password or use PostIt notes to remember. Those who do
this ensure that they remember usernames, but on the other hand make
themselves very vulnerable.

Tricia, after examining each of your suggestions, I can clearly see that
many users WILL forget their username within no time. This is especially
true for people with common names (go figure!). This will also be true
for people who do not log in frequently--higher frequency enhances
synaptic bonds between ne.

I am sure there would be a lot of flame this suggestion, but here it is
anyway:

As username and the corresponding password make a unique key together,
why should the system ask for a unique username? Many user problems lie
in making the username unique. Can we do away with unique usernames? Let
the combination be unique. This may solve "remembering the username"
problem to an extant.

Some have tried to solve unique username problem by replacing usernames
with email addresses. This is a better solution in many ways but also
has its fair share of usability issues.

- Ripul

--
Ripul Kumar
Director, Usability Consulting
Kern Communications Pvt Ltd, India
www.kern-comm.com
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
Furthermore, the information contained in this message, and any attachments thereto, is for information purposes only and may contain the personal views and opinions of the author, which are not necessarily the views and opinions of the company.

23 Nov 2005 - 3:57am
Ripul Kumar
2005

Tricia,

To redesign the user interface, we were conducting contextual inquiry for one of the largest credit card call center in the US. There were many objects that we observed with almost everybody: many PostIt notes on the pin-up board with photographs, memos, and performance certificates. The PostIt notes contained strange numbers. We discovered that they were passwords to many systems that the call center executives use. The system forced users to change passwords frequently.

On one hand the security is world class--each user must change password regularly. But, on the other hand you cant expect the users to remember login information that changes regularly. Isn't this situation is very similar to a user who logs in infrequently to many sites who force user to remember a unique username?

In yet another design exercise with a large wireless service providers' PoS shops, we found an interesting story. Everyone's "latest" password was printed in a weekly password sheet. This sheet was prominently displayed in the back room. And, we found out that it was necessary to conduct daily business smoothly.

In the above stories, to conduct daily business smoothly, users do have workarounds to "security" problems in such a way that they become highly vulnerable. Do we really want highly secure systems that force users to make systems highly vulnerable?

Can we find ways so that users need not remember multiple usernames and worry about changed passwords?

- Ripul

--
Ripul Kumar
Director, Usability Consulting
Kern Communications Pvt Ltd, India
www.kern-comm.com

23 Nov 2005 - 4:04am
dszuc
2005

Interestingly HSBC in Hong Kong have introduced a "Security Device" that you
hang on your key chain. So when you use internet banking the user is
required to enter:

1. Username

2. Password

3. Security code on the device

Be interesting to see how this progresses.

http://www.hsbc.com.hk/hk/personal/security/security_device.htm?wtfrom=amhma
in_e

Daniel Szuc
Principal Usability Consultant
Apogee Usability Asia Ltd
www.apogeehk.com
'Usability in Asia'

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com
[mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of Ripul
Kumar
Sent: Wednesday, November 23, 2005 5:58 PM
To: discuss at ixda.org
Subject: Re: [IxDA Discuss] suggested User ID's

[Please voluntarily trim replies to include only relevant quoted material.]

Tricia,

To redesign the user interface, we were conducting contextual inquiry for
one of the largest credit card call center in the US. There were many
objects that we observed with almost everybody: many PostIt notes on the
pin-up board with photographs, memos, and performance certificates. The
PostIt notes contained strange numbers. We discovered that they were
passwords to many systems that the call center executives use. The system
forced users to change passwords frequently.

On one hand the security is world class--each user must change password
regularly. But, on the other hand you cant expect the users to remember
login information that changes regularly. Isn't this situation is very
similar to a user who logs in infrequently to many sites who force user to
remember a unique username?

In yet another design exercise with a large wireless service providers' PoS
shops, we found an interesting story. Everyone's "latest" password was
printed in a weekly password sheet. This sheet was prominently displayed in
the back room. And, we found out that it was necessary to conduct daily
business smoothly.

In the above stories, to conduct daily business smoothly, users do have
workarounds to "security" problems in such a way that they become highly
vulnerable. Do we really want highly secure systems that force users to make
systems highly vulnerable?

Can we find ways so that users need not remember multiple usernames and
worry about changed passwords?

- Ripul

--
Ripul Kumar
Director, Usability Consulting
Kern Communications Pvt Ltd, India
www.kern-comm.com
________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss at ixda.org
(Un)Subscription Options ... http://subscription-options.ixda.org/
Announcements List ......... http://subscribe-announce.ixda.org/
Questions .................. lists at ixda.org
Home ....................... http://ixda.org/
Resource Library ........... http://resources.ixda.org

23 Nov 2005 - 3:45am
Ganesh Gayakwad
2005

Tricia (Bluesky Consult) wrote:

>> On another note, where the user ID isn't needed to identify to the user
>> to other users I have also seen the suggestion of having only a unique
>> password to login to a system. It is true that only 1 unique unknown
>> input is needed to identify a user to a system.

This kept me thinking whether user ID has crept in from the need of the
system (database) to associate the password with user? In real life, at many
places just the name of the user is enough to conduct business. Do we need a
password to open our house? It is just a key.
It is interesting to note how almost habitually systems are designed with a
need to enter user IDs. In your case, isn't name or first name + last name
enough? I agree that you will achieve ease of remembering at the cost of
slightly increased text input, but most users can quickly type their names.

Thanks and Regards,

Ganesh Gayakwad

*********************************************************
Disclaimer:

The contents of this E-mail (including the contents of the enclosure(s) or attachment(s) if any) are privileged and confidential material of MBT and should not be disclosed to, used by or copied in any manner by anyone other than the intended addressee(s). In case you are not the desired addressee, you should delete this message and/or re-direct it to the sender. The views expressed in this E-mail message (including the enclosure(s) or attachment(s) if any) are those of the individual sender, except where the sender expressly, and with authority, states them to be the views of MBT.

This e-mail message including attachment/(s), if any, is believed to be free of any virus. However, it is the responsibility of the recipient to ensure that it is virus free and MBT is not responsible for any loss or damage arising in any way from its use

*********************************************************

23 Nov 2005 - 5:36am
Ripul Kumar
2005

> In real life, at many
> places just the name of the user is enough to conduct business. Do we need a
> password to open our house? It is just a key.

Ganesh, you are absolutely correct. The password is just a key. However, system designers due to "fear of security" have been making username the key. And, we have seen this repeatedly--chaos and frustration!

> It is interesting to note how almost habitually systems are designed with a
> need to enter user IDs. In your case, isn't name or first name + last name
> enough? I agree that you will achieve ease of remembering at the cost of
> slightly increased text input, but most users can quickly type their names.

I go with you all the way! Systems must be designed simple. And, in my opinion, your solution seems to be simple, secure, and highly workable. And, the costs are not really much considering that users will save repeated frustration.

I will definitely suggest "first name + middle initial + last name" and password combination to a willing web application client. Tricia, what are your views about this?

- Ripul

--
Ripul Kumar
Director, Usability Consulting
Kern Communications Pvt Ltd, India
www.kern-comm.com

23 Nov 2005 - 5:57am
Ben Hunt
2004

Tricia's problem:

1) The database needs to identify a user account uniquely. (This is
equivalent to the address of Ganesh's house.)
2) The account needs a private key/password that provides authority to
enter. It does not have to be unique. (This is the equivalent of the key to
Ganesh's house.)
3) The system needs a name that identifies users to other users. This can
not be the email address. It must also be unique to prevent identity
confusion. The nearest equivalent to this is the person's name.

Because (1) and (3) both must be unique, they could be the same thing.

However, (1) also needs to be memorable. Your email address is the most
memorable unique ID, however (3) cannot be email address.

I would suggest the following solution:
- You log in with your email address and a password
- You are known by a third identifier, a unique "friendly name"

This adds one field to the registration process, but meets all the
requirements.

- Ben

23 Nov 2005 - 6:28am
Tricia (Bluesky...
2005

My main concern at this stage is that the User ID has to be unique as it
identifies the user.

Surely First Name + Middle Name + Last Name won't necessarily be unique?

Tricia

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com
[mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of
Ripul Kumar
Sent: Wednesday, November 23, 2005 1:37 PM
To: discuss at ixda.org
Subject: Re: [IxDA Discuss] suggested User ID's

[Please voluntarily trim replies to include only relevant quoted
material.]

> In real life, at many
> places just the name of the user is enough to conduct business. Do we
> need a password to open our house? It is just a key.

Ganesh, you are absolutely correct. The password is just a key. However,
system designers due to "fear of security" have been making username the
key. And, we have seen this repeatedly--chaos and frustration!

> It is interesting to note how almost habitually systems are designed
> with a need to enter user IDs. In your case, isn't name or first name
> + last name enough? I agree that you will achieve ease of remembering
> at the cost of slightly increased text input, but most users can
quickly type their names.

I go with you all the way! Systems must be designed simple. And, in my
opinion, your solution seems to be simple, secure, and highly workable.
And, the costs are not really much considering that users will save
repeated frustration.

I will definitely suggest "first name + middle initial + last name" and
password combination to a willing web application client. Tricia, what
are your views about this?

- Ripul

--
Ripul Kumar
Director, Usability Consulting
Kern Communications Pvt Ltd, India
www.kern-comm.com
________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss at ixda.org (Un)Subscription Options
... http://subscription-options.ixda.org/
Announcements List ......... http://subscribe-announce.ixda.org/
Questions .................. lists at ixda.org Home .......................
http://ixda.org/ Resource Library ........... http://resources.ixda.org
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
Furthermore, the information contained in this message, and any attachments thereto, is for information purposes only and may contain the personal views and opinions of the author, which are not necessarily the views and opinions of the company.

23 Nov 2005 - 6:39am
Tricia (Bluesky...
2005

So then we're back to the original discussion, the one about suggesting
unique names.

When creating the third identifier, the unique "friendly name", is it a
good idea to suggest alternatives when the users requested name is
unavailable or is it better to let the user keep on trying to create his
own unique name.

Tricia

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com
[mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of Ben
Hunt
Sent: Wednesday, November 23, 2005 1:57 PM
To: 'Ripul Kumar'; discuss at ixda.org
Subject: Re: [IxDA Discuss] suggested User ID's

[Please voluntarily trim replies to include only relevant quoted
material.]

Tricia's problem:

1) The database needs to identify a user account uniquely. (This is
equivalent to the address of Ganesh's house.)
2) The account needs a private key/password that provides authority to
enter. It does not have to be unique. (This is the equivalent of the key
to Ganesh's house.)
3) The system needs a name that identifies users to other users. This
can not be the email address. It must also be unique to prevent identity
confusion. The nearest equivalent to this is the person's name.

Because (1) and (3) both must be unique, they could be the same thing.

However, (1) also needs to be memorable. Your email address is the most
memorable unique ID, however (3) cannot be email address.

I would suggest the following solution:
- You log in with your email address and a password
- You are known by a third identifier, a unique "friendly name"

This adds one field to the registration process, but meets all the
requirements.

- Ben

________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss at ixda.org (Un)Subscription Options
... http://subscription-options.ixda.org/
Announcements List ......... http://subscribe-announce.ixda.org/
Questions .................. lists at ixda.org Home .......................
http://ixda.org/ Resource Library ........... http://resources.ixda.org
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
Furthermore, the information contained in this message, and any attachments thereto, is for information purposes only and may contain the personal views and opinions of the author, which are not necessarily the views and opinions of the company.

23 Nov 2005 - 6:54am
Ben Hunt
2004

The only reason ever to keep people in a blind guessing loop is for
security. That doesn't apply here.

For the user name, if my first choice is not available, the next view can
combine multiple approaches:

1) Suggestions using incremented numbers, e.g. benhunt9
2) Suggestions using any other data you know about me (could be derived
safely from my email address), e.g. benhuntuk or ben.hunt
3) What about a further five text boxes, where I can type up to 5 preferred
choices, in order of priority.
4) ..or a combination of the above..

What we're looking for here is a name that is applicable to me, so I'd
probably prefer the multiple option (3).

AJAX would be even better, so when I exit the field, or click 'Check', I see
a "Checking name" label, then if the name is unavailable, I'm alerted and
focus returns to the field.

- Ben

-----Original Message-----
From: Tricia (Bluesky Consult) [mailto:tricia at blueskyconsult.com]

So then we're back to the original discussion, the one about suggesting
unique names.

When creating the third identifier, the unique "friendly name", is it a good
idea to suggest alternatives when the users requested name is unavailable or
is it better to let the user keep on trying to create his own unique name.

Tricia

23 Nov 2005 - 7:01am
Larry Marine
2005

We've done a lot of work in security related UI's and Ben's suggestion is
the one that performed the best over the years. As Daniel Scuz pointed out,
users maintain a small set of memorable user names and passwords. Forcing
them to adopt an arcane one from a list of suggestions doesn't work well. As
others pointed out, in such cases, users must write these anomalous
usernames and passwords down, which defeats the purpose altogether.

So, I would highly suggest that you follow Ben's suggestions.
Larry

----- Original Message -----
From: "Ben Hunt" <ben at scratchmedia.co.uk>
To: "'Ripul Kumar'" <ripulk at gmail.com>; <discuss at ixda.org>
Sent: Wednesday, November 23, 2005 4:57 AM
Subject: Re: [IxDA Discuss] suggested User ID's

> [Please voluntarily trim replies to include only relevant quoted
> material.]
>
> Tricia's problem:
>
> 1) The database needs to identify a user account uniquely. (This is
> equivalent to the address of Ganesh's house.)
> 2) The account needs a private key/password that provides authority to
> enter. It does not have to be unique. (This is the equivalent of the key
> to
> Ganesh's house.)
> 3) The system needs a name that identifies users to other users. This can
> not be the email address. It must also be unique to prevent identity
> confusion. The nearest equivalent to this is the person's name.
>
> Because (1) and (3) both must be unique, they could be the same thing.
>
> However, (1) also needs to be memorable. Your email address is the most
> memorable unique ID, however (3) cannot be email address.
>
> I would suggest the following solution:
> - You log in with your email address and a password
> - You are known by a third identifier, a unique "friendly name"
>
> This adds one field to the registration process, but meets all the
> requirements.
>
> - Ben
>
>
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>

23 Nov 2005 - 7:27am
dszuc
2005

Another approach:

http://www.uie.com/brainsparks/2005/11/23/check-user-id-button/

Is there a way the UserID could be linked to the email address. So the user
enters their unique email address (easy to remember) and the system assigns
a UserID for identification purposes? i.e. let the technology do the work to
assign the UserID, AND the user only has to remember the email address.

Perhaps I am over simplifying?

Rgds,

Daniel Szuc
Principal Usability Consultant
Apogee Usability Asia Ltd
www.apogeehk.com
'Usability in Asia'

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com
[mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of Larry
Marine
Sent: Wednesday, November 23, 2005 9:02 PM
To: discuss at ixda.org
Subject: Re: [IxDA Discuss] suggested User ID's

[Please voluntarily trim replies to include only relevant quoted material.]

We've done a lot of work in security related UI's and Ben's suggestion is
the one that performed the best over the years. As Daniel Scuz pointed out,
users maintain a small set of memorable user names and passwords. Forcing
them to adopt an arcane one from a list of suggestions doesn't work well. As

others pointed out, in such cases, users must write these anomalous
usernames and passwords down, which defeats the purpose altogether.

So, I would highly suggest that you follow Ben's suggestions. Larry

----- Original Message -----
From: "Ben Hunt" <ben at scratchmedia.co.uk>
To: "'Ripul Kumar'" <ripulk at gmail.com>; <discuss at ixda.org>
Sent: Wednesday, November 23, 2005 4:57 AM
Subject: Re: [IxDA Discuss] suggested User ID's

> [Please voluntarily trim replies to include only relevant quoted
> material.]
>
> Tricia's problem:
>
> 1) The database needs to identify a user account uniquely. (This is
> equivalent to the address of Ganesh's house.)
> 2) The account needs a private key/password that provides authority to
> enter. It does not have to be unique. (This is the equivalent of the
> key to Ganesh's house.)
> 3) The system needs a name that identifies users to other users. This can
> not be the email address. It must also be unique to prevent identity
> confusion. The nearest equivalent to this is the person's name.
>
> Because (1) and (3) both must be unique, they could be the same thing.
>
> However, (1) also needs to be memorable. Your email address is the
> most memorable unique ID, however (3) cannot be email address.
>
> I would suggest the following solution:
> - You log in with your email address and a password
> - You are known by a third identifier, a unique "friendly name"
>
> This adds one field to the registration process, but meets all the
> requirements.
>
> - Ben
>
>
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org (Un)Subscription Options
> ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>

________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss at ixda.org
(Un)Subscription Options ... http://subscription-options.ixda.org/
Announcements List ......... http://subscribe-announce.ixda.org/
Questions .................. lists at ixda.org
Home ....................... http://ixda.org/
Resource Library ........... http://resources.ixda.org

23 Nov 2005 - 7:58am
Todd Warfel
2003

Good goal. Bad execution.

How many Mikes do you know? Or Marys? You can distinguish each one by
something other than their name...

On Nov 23, 2005, at 3:55 AM, Tricia (Bluesky Consult) wrote:
> I am still tied in to the requirement that the User ID needs to
> identify
> the user to other users on the system. I can't have two users with the
> same User ID.

The goal is to make sure each individual (account) signed can be
uniquely identified by others, on the business side.

The goal of the customer is a waterfall (we've done a lot of work
with registration services, even worked on the first Single Sign On
service I know of). What relates to your situation from our
experience is this.

Customers hate signing in. They simply don't want to do it, first and
foremost - it's a barrier to entry, plain and simple. So, what's
next? Well, make it easy to sign-in (this impacts registration
setup). Make the username easy (pick it myself, not too many
complications like "Must have letters and numbers, no spaces"). Make
sure I can pick it w/o out too much complication so I can remember it
next time I come back. Same thing goes for my password.

Consider allowing something other than their User ID being what
distinguishes them. Maybe they use their email address, password, and
something like a nickname or phrase that is the unique identifier.
This allows them to be identified by others, but not have a huge
barrier to entry to get in initially and upon return.

Cheers!

Todd R. Warfel
Partner, Design & Usability Specialist
Messagefirst | making products & services easier to use
--------------------------------------
Contact Info
Voice: (607) 339-9640
Email: todd at messagefirst.com
AIM: twarfel at mac.com
Blog: http://toddwarfel.com
--------------------------------------
In theory, theory and practice are the same.
In practice, they are not.

23 Nov 2005 - 6:56am
VenkatVijay
2005

How about thumb impression? More proven unique identifier.

vijay

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com
[mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of Tricia
(Bluesky Consult)
Sent: Wednesday, November 23, 2005 6:10 PM
To: Ben Hunt; Ripul Kumar; discuss at ixda.org
Subject: Re: [IxDA Discuss] suggested User ID's

[Please voluntarily trim replies to include only relevant quoted material.]

So then we're back to the original discussion, the one about suggesting
unique names.

When creating the third identifier, the unique "friendly name", is it a
good idea to suggest alternatives when the users requested name is
unavailable or is it better to let the user keep on trying to create his
own unique name.

Tricia

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com
[mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of Ben
Hunt
Sent: Wednesday, November 23, 2005 1:57 PM
To: 'Ripul Kumar'; discuss at ixda.org
Subject: Re: [IxDA Discuss] suggested User ID's

[Please voluntarily trim replies to include only relevant quoted
material.]

Tricia's problem:

1) The database needs to identify a user account uniquely. (This is
equivalent to the address of Ganesh's house.)
2) The account needs a private key/password that provides authority to
enter. It does not have to be unique. (This is the equivalent of the key
to Ganesh's house.)
3) The system needs a name that identifies users to other users. This
can not be the email address. It must also be unique to prevent identity
confusion. The nearest equivalent to this is the person's name.

Because (1) and (3) both must be unique, they could be the same thing.

However, (1) also needs to be memorable. Your email address is the most
memorable unique ID, however (3) cannot be email address.

I would suggest the following solution:
- You log in with your email address and a password
- You are known by a third identifier, a unique "friendly name"

This adds one field to the registration process, but meets all the
requirements.

- Ben

________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss at ixda.org (Un)Subscription Options
... http://subscription-options.ixda.org/
Announcements List ......... http://subscribe-announce.ixda.org/
Questions .................. lists at ixda.org Home .......................
http://ixda.org/ Resource Library ........... http://resources.ixda.org
The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you received
this in error, please contact the sender and delete the material from any
computer.
Furthermore, the information contained in this message, and any attachments
thereto, is for information purposes only and may contain the personal views
and opinions of the author, which are not necessarily the views and opinions
of the company.

________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss at ixda.org
(Un)Subscription Options ... http://subscription-options.ixda.org/
Announcements List ......... http://subscribe-announce.ixda.org/
Questions .................. lists at ixda.org
Home ....................... http://ixda.org/
Resource Library ........... http://resources.ixda.org

23 Nov 2005 - 8:01am
Todd Warfel
2003

This is common in US banking or large corporations with sensitive
data (e.g. CitiGroup, Xerox, Ikon). Can't tell you the number of
times I'm with people from these groups who can't sign into their
system because they can't find their security device. Having it on a
keychain would lessen that to a degree, but I still think that's
going down a bad path - very unnatural.

On Nov 23, 2005, at 5:04 AM, Daniel Szuc wrote:

> 1. Username
>
> 2. Password
>
> 3. Security code on the device
>
> Be interesting to see how this progresses.
>
> http://www.hsbc.com.hk/hk/personal/security/security_device.htm?
> wtfrom=amhma
> in_e

Cheers!

Todd R. Warfel
Partner, Design & Usability Specialist
Messagefirst | making products & services easier to use
--------------------------------------
Contact Info
Voice: (607) 339-9640
Email: todd at messagefirst.com
AIM: twarfel at mac.com
Blog: http://toddwarfel.com
--------------------------------------
In theory, theory and practice are the same.
In practice, they are not.

23 Nov 2005 - 11:01am
Gomez, Marla A
2005

I agree - it seems to me the move for the future should be some kind of system that doesn't even require the user to "remember" anything. Thumb impression or eye scan should be considered as serious future possibilities. This keeps the user from having to remember a device and/or password/unique identifier combinations.

Marla Gómez
Ethnographer/Human Factors Engineer
Phone: 503.712.6851
Email/IM: marla.a.gomez at intel.com

***The information contained in this message, and any attachments
thereto, is for information purposes only and contains the personal views
and opinions of the author, which are not necessarily the views and opinions
of the company.***

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com [mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of VenkatVijay
Sent: Wednesday, November 23, 2005 4:56 AM
To: discuss at ixda.org
Subject: Re: [IxDA Discuss] suggested User ID's

[Please voluntarily trim replies to include only relevant quoted material.]

How about thumb impression? More proven unique identifier.

vijay

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com
[mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of Tricia
(Bluesky Consult)
Sent: Wednesday, November 23, 2005 6:10 PM
To: Ben Hunt; Ripul Kumar; discuss at ixda.org
Subject: Re: [IxDA Discuss] suggested User ID's

[Please voluntarily trim replies to include only relevant quoted material.]

So then we're back to the original discussion, the one about suggesting
unique names.

When creating the third identifier, the unique "friendly name", is it a
good idea to suggest alternatives when the users requested name is
unavailable or is it better to let the user keep on trying to create his
own unique name.

Tricia

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com
[mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of Ben
Hunt
Sent: Wednesday, November 23, 2005 1:57 PM
To: 'Ripul Kumar'; discuss at ixda.org
Subject: Re: [IxDA Discuss] suggested User ID's

[Please voluntarily trim replies to include only relevant quoted
material.]

Tricia's problem:

1) The database needs to identify a user account uniquely. (This is
equivalent to the address of Ganesh's house.)
2) The account needs a private key/password that provides authority to
enter. It does not have to be unique. (This is the equivalent of the key
to Ganesh's house.)
3) The system needs a name that identifies users to other users. This
can not be the email address. It must also be unique to prevent identity
confusion. The nearest equivalent to this is the person's name.

Because (1) and (3) both must be unique, they could be the same thing.

However, (1) also needs to be memorable. Your email address is the most
memorable unique ID, however (3) cannot be email address.

I would suggest the following solution:
- You log in with your email address and a password
- You are known by a third identifier, a unique "friendly name"

This adds one field to the registration process, but meets all the
requirements.

- Ben

________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss at ixda.org (Un)Subscription Options
... http://subscription-options.ixda.org/
Announcements List ......... http://subscribe-announce.ixda.org/
Questions .................. lists at ixda.org Home .......................
http://ixda.org/ Resource Library ........... http://resources.ixda.org
The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you received
this in error, please contact the sender and delete the material from any
computer.
Furthermore, the information contained in this message, and any attachments
thereto, is for information purposes only and may contain the personal views
and opinions of the author, which are not necessarily the views and opinions
of the company.

________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss at ixda.org
(Un)Subscription Options ... http://subscription-options.ixda.org/
Announcements List ......... http://subscribe-announce.ixda.org/
Questions .................. lists at ixda.org
Home ....................... http://ixda.org/
Resource Library ........... http://resources.ixda.org

________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss at ixda.org
(Un)Subscription Options ... http://subscription-options.ixda.org/
Announcements List ......... http://subscribe-announce.ixda.org/
Questions .................. lists at ixda.org
Home ....................... http://ixda.org/
Resource Library ........... http://resources.ixda.org

23 Nov 2005 - 11:42am
penguinstorm
2005

On Nov-23-2005, at 2:04 AM, Daniel Szuc wrote:

> Interestingly HSBC in Hong Kong have introduced a "Security Device"
> that you
> hang on your key chain. So when you use internet banking the user is
> required to enter:

Banks have a fairly unique capacity to impose severe security
restrictions like this on their users. I wouldn't take this as a
typical example.

I think the thread's gotten a bit off topic - Tricia's pretty clearly
said she "needs a unique user ID" and is looking for suggestions on
how to implement recommended ID's. Maybe I'm wrong, but I don't think
she's looking for alternative UserID/Password suggestions.

FWIW, I've never once used a recommended ID. I've always chosen my own.

I've found the key to registration systems is getting the user
registered - quickly. In this sense, email makes a great deal of
sense - it's fairly unique and easy to remember. I use it whenever
possible, and if it were possible to implement I'd suggest using
Email/Username as login/pass and implementing a "screenname" type
system in order to speed registration along.

Someone suggested that username/password be keyed unique in
combination: this doesn't satisfy Tricia's need to have a unique
UserID, nor is it guaranteed to be unique on an ongoing basis (people
can, presumably, change passwords.) It's always best to have at least
one unique key.

If not, I'd provide at least a list of recommended alternatives with
a default (name entered + number appended to make it unique). Default
should be selected, as well as an option to try to select another.

(I somehow wound up with penguinstorm2000 @ yahoo this way: ugh. I
registered it in 2000 - how silly was that? I've since adopted a new
yahoo ID.)

Gmail's "is it available" checker is a highly recommended tool,
except I've yet to see it on a Mac. Still, I suspect most people
aren't going to click it - they'll fill out the form, choose an ID
and proceed.
--
Scott Nelson
skot at penguinstorm.com
http://www.penguinstorm.com/

skype. skot.nelson

23 Nov 2005 - 11:45am
penguinstorm
2005

On Nov-23-2005, at 3:36 AM, Ripul Kumar wrote:

>> places just the name of the user is enough to conduct business. Do
>> we need a
>> password to open our house? It is just a key.
>
> Ganesh, you are absolutely correct. The password is just a key.
> However, system designers due to "fear of security" have been
> making username the key. And, we have seen this repeatedly--chaos
> and frustration!

You also have to make sure you're at the right house.

That's what your userID does.

Unless you're in a fully controlled environment, multi-factor
authentication is a reality: in controlled environments (i.e. office
with all fixed IPs) other possibilities exist.

But this is the wild wild web; woo hoo! I need to be able to login
not just from home, but also when I visit my mother who lives over
4,000km away (certainly not the same house...unless it's really
really big.)
--
Scott Nelson
skot at penguinstorm.com
http://www.penguinstorm.com/

skype. skot.nelson

23 Nov 2005 - 6:15am
Ganesh Gayakwad
2005

Ripul,

> In real life, at many
> places just the name of the user is enough to conduct business. Do we need
a
> password to open our house? It is just a key.

In my sentence above, please read user ID. As Ripul has pointed out, the key
is a password. My mistake!

Thanks and regards,
-Ganesh Gayakwad

*********************************************************
Disclaimer:

The contents of this E-mail (including the contents of the enclosure(s) or attachment(s) if any) are privileged and confidential material of MBT and should not be disclosed to, used by or copied in any manner by anyone other than the intended addressee(s). In case you are not the desired addressee, you should delete this message and/or re-direct it to the sender. The views expressed in this E-mail message (including the enclosure(s) or attachment(s) if any) are those of the individual sender, except where the sender expressly, and with authority, states them to be the views of MBT.

This e-mail message including attachment/(s), if any, is believed to be free of any virus. However, it is the responsibility of the recipient to ensure that it is virus free and MBT is not responsible for any loss or damage arising in any way from its use

*********************************************************

23 Nov 2005 - 7:30pm
penguinstorm
2005

right. is there a web application for this? you can fool microsoft's
finger print scanner quite easily anyway. i'm assuming this was a
facetious suggestion, but if not it should be taken as such.

On Nov-23-2005, at 4:56 AM, VenkatVijay wrote:

> How about thumb impression? More proven unique identifier.

--
Scott Nelson
skot at penguinstorm.com
http://www.penguinstorm.com/

skype. skot.nelson

23 Nov 2005 - 7:32pm
penguinstorm
2005

On Nov-23-2005, at 4:28 AM, Tricia (Bluesky Consult) wrote:

>> In real life, at many
>> places just the name of the user is enough to conduct business. Do we
>> need a password to open our house? It is just a key.
>
> Ganesh, you are absolutely correct. The password is just a key.
> However,
> system designers due to "fear of security" have been making
> username the
> key. And, we have seen this repeatedly--chaos and frustration!

This is categorically foolish in a modern system environment; the key
metaphor would apply only if you were logging onto a unique system.

on my laptop i could secure it with only a single password. Not, as I
said in another message, in a world where the system can be connected
to from multiple locations.
--
Scott Nelson
skot at penguinstorm.com
http://www.penguinstorm.com/

skype. skot.nelson

23 Nov 2005 - 8:32pm
penguinstorm
2005

On Nov-23-2005, at 6:01 AM, Todd Warfel wrote:

> Having it on a
> keychain would lessen that to a degree, but I still think that's
> going down a bad path - very unnatural.

Biopassword has a beautiful solution because it requires *no special
hardware* to my understanding yet adds seamless biometric
authentication to desktop apps.
--
Scott Nelson
skot at penguinstorm.com
http://www.penguinstorm.com/

skype. skot.nelson

23 Nov 2005 - 11:23pm
Ganesh Gayakwad
2005

On Nov-23-2005, at 3:36 AM, Ripul Kumar wrote:

>> places just the name of the user is enough to conduct business. Do
>> we need a
>> password to open our house? It is just a key.
>
> Ganesh, you are absolutely correct. The password is just a key.
> However, system designers due to "fear of security" have been
> making username the key. And, we have seen this repeatedly--chaos
> and frustration!

Skot Nelson wrote:

> You also have to make sure you're at the right house.

> That's what your userID does.

No, that is what url of the web application does.

Thanks and Regards,

Ganesh Gayakwad

*********************************************************
Disclaimer:

The contents of this E-mail (including the contents of the enclosure(s) or attachment(s) if any) are privileged and confidential material of MBT and should not be disclosed to, used by or copied in any manner by anyone other than the intended addressee(s). In case you are not the desired addressee, you should delete this message and/or re-direct it to the sender. The views expressed in this E-mail message (including the enclosure(s) or attachment(s) if any) are those of the individual sender, except where the sender expressly, and with authority, states them to be the views of MBT.

This e-mail message including attachment/(s), if any, is believed to be free of any virus. However, it is the responsibility of the recipient to ensure that it is virus free and MBT is not responsible for any loss or damage arising in any way from its use

*********************************************************

23 Nov 2005 - 11:29pm
penguinstorm
2005

On Nov-23-2005, at 9:23 PM, Ganesh Gayakwad wrote:

> Skot Nelson wrote:
>
>> You also have to make sure you're at the right house.
>> That's what your userID does.
>
> No, that is what url of the web application does.

No. It doesn't. Unless you're generating 100% unique URLs, in which
case you are essentially encoding the user ID into the URL. It's
still there there.

I am a strong advocate for the use of cookies to stash one part of
logins; still the same issue though - the UserID exists, you're just
saving it.

Your house analogy doesn't really hold: think of Yahoo as being like
an apartment building - home to millions. You've got a front door
key, and a key for your door.

That's a horrible analogy too though. Username/Password is a
necessity in most environments.
--
Scott Nelson
skot at penguinstorm.com
http://www.penguinstorm.com/

skype. skot.nelson

23 Nov 2005 - 11:52pm
Ganesh Gayakwad
2005

>> In real life, at many
>> places just the name of the user is enough to conduct business. Do we
>> need a password to open our house? It is just a key.
>
> Ganesh, you are absolutely correct. The password is just a key.
> However,
> system designers due to "fear of security" have been making
> username the
> key. And, we have seen this repeatedly--chaos and frustration!

Scott Nelson wrote:
> This is categorically foolish in a modern system environment; the key
> metaphor would apply only if you were logging onto a unique system.

I don't think so. I suppose when you are logging on to a web based system,
its url is unique. Hence it is not user ID which ensures that you are
logging in to a particular system, it is the url.

> on my laptop i could secure it with only a single password. Not, as I
> said in another message, in a world where the system can be connected
> to from multiple locations.

In this scenario, there are multiple mechanisms such as digital certificates
issued to laptops etc.

- Ganesh Gayakwad

*********************************************************
Disclaimer:

The contents of this E-mail (including the contents of the enclosure(s) or attachment(s) if any) are privileged and confidential material of MBT and should not be disclosed to, used by or copied in any manner by anyone other than the intended addressee(s). In case you are not the desired addressee, you should delete this message and/or re-direct it to the sender. The views expressed in this E-mail message (including the enclosure(s) or attachment(s) if any) are those of the individual sender, except where the sender expressly, and with authority, states them to be the views of MBT.

This e-mail message including attachment/(s), if any, is believed to be free of any virus. However, it is the responsibility of the recipient to ensure that it is virus free and MBT is not responsible for any loss or damage arising in any way from its use

*********************************************************

23 Nov 2005 - 11:59pm
Navneet Nair
2004

>
>
> I don't think so. I suppose when you are logging on to a web based system,
> its url is unique. Hence it is not user ID which ensures that you are
> logging in to a particular system, it is the url.

Ganesh,

If you're application does not have a concept of 'Personal Space' you're
right. Else what Scott says makes sense...

Navneet

24 Nov 2005 - 12:05am
penguinstorm
2005

On Nov-23-2005, at 9:52 PM, Ganesh Gayakwad wrote:

> Scott Nelson wrote:
>> This is categorically foolish in a modern system environment; the key
>> metaphor would apply only if you were logging onto a unique system.
>
> I don't think so. I suppose when you are logging on to a web based
> system,
> its url is unique. Hence it is not user ID which ensures that you are
> logging in to a particular system, it is the url.

Sure. It's semantic, is my point. You're still creating a dual
authentication mechanism, you're just changing the nature of one of
them.

Instead of telling me to go to yahoo.com and login as skotnelson/
password you're asking me to go to yahoo.com/skotnelson and login
with password

i still need to remember skotnelson - granted, I can bookmark it, but
this is just another way of remembering it (less secure, I might add,
unless you obfuscate the URL to the point I can't remember it and
then when I loose it you need to provide some method for recovery.)

>> on my laptop i could secure it with only a single password. Not, as I
>> said in another message, in a world where the system can be connected
>> to from multiple locations.
>
> In this scenario, there are multiple mechanisms such as digital
> certificates
> issued to laptops etc.

Sure. So the digital certificate replaces the UserID, but I'm still
required to create a password. You're still doing two part
authentication, not simply a password. (I realize certs without
passwords are possible, but again only in closed environment; every
cert I've ever used has required password entry as well.)

You're argument that "to get into my house I only need a key" implied
a "single key" authentication method; this is not so, you also need
to know the address that the key corresponds too - and you probably
wouldn't hang it from a keychain that said "This key opens the door
to my house at 52 Snowden Crescent"

Two part methods of authentication have existed for a long time; I'm
not suggesting that there aren't better ways to do it (even better is
adding a third layer, if you can do it easily - see my earlier
reference to Biopassword). I'm just suggesting that your goal of
"single key" authentication is dis-ingenuous and unnecessary.
--
Scott Nelson
skot at penguinstorm.com
http://www.penguinstorm.com/

skype. skot.nelson

24 Nov 2005 - 1:46am
penguinstorm
2005

On Nov-23-2005, at 3:57 AM, Ben Hunt wrote:

> I would suggest the following solution:
> - You log in with your email address and a password
> - You are known by a third identifier, a unique "friendly name"

Always a good choice.
--
Scott Nelson
skot at penguinstorm.com
http://www.penguinstorm.com/

skype. skot.nelson

25 Nov 2005 - 5:24am
Pierre Abel
2004

Hi,
Concerning the screen name, I would even generate a default unique
screen name based upon the email address entered as login. e.g for me it
would be pierre abel, or pierre abelxx (xx is a number) if pierre.abel
already exists as a screen name.
Note that that I don't mean changing the UI: This screen name would
still be editable (i.e the field would only be filled automatically by
the generated unique screen name).
If the user edit the screen name and then creates an already existing
screen name, then you suggest other possibilities as described in
previous posts.

Of course, it only works if you assume that most users don't want a
special screen name (such as Snoopy or Toto ;-) ). And this depends on
your context...

Pierre

Ben Hunt wrote:

>[Please voluntarily trim replies to include only relevant quoted material.]
>
>The only reason ever to keep people in a blind guessing loop is for
>security. That doesn't apply here.
>
>For the user name, if my first choice is not available, the next view can
>combine multiple approaches:
>
>1) Suggestions using incremented numbers, e.g. benhunt9
>2) Suggestions using any other data you know about me (could be derived
>safely from my email address), e.g. benhuntuk or ben.hunt
>3) What about a further five text boxes, where I can type up to 5 preferred
>choices, in order of priority.
>4) ..or a combination of the above..
>
>What we're looking for here is a name that is applicable to me, so I'd
>probably prefer the multiple option (3).
>
>AJAX would be even better, so when I exit the field, or click 'Check', I see
>a "Checking name" label, then if the name is unavailable, I'm alerted and
>focus returns to the field.
>
>- Ben
>
>
>-----Original Message-----
>From: Tricia (Bluesky Consult) [mailto:tricia at blueskyconsult.com]
>
>So then we're back to the original discussion, the one about suggesting
>unique names.
>
>When creating the third identifier, the unique "friendly name", is it a good
>idea to suggest alternatives when the users requested name is unavailable or
>is it better to let the user keep on trying to create his own unique name.
>
>Tricia
>
>
>
>________________________________________________________________
>Welcome to the Interaction Design Association (IxDA)!
>To post to this list ....... discuss at ixda.org
>(Un)Subscription Options ... http://subscription-options.ixda.org/
>Announcements List ......... http://subscribe-announce.ixda.org/
>Questions .................. lists at ixda.org
>Home ....................... http://ixda.org/
>Resource Library ........... http://resources.ixda.org
>
>
>

25 Nov 2005 - 8:30am
sajid saiyed
2005

Hi All,
Lets face this, dont we have people with same names in real world?

Mike could be working with another Mike in the same office. Right?

And still we know the difference because their faces are different.

You can apply he saame principle here.

Let the users have similar ID's but validate based on their Email address.

Does it help?

Sajid
http://www.ssdesigninteractive.com/ssdesign

On 11/25/05, Pierre Abel <abel at castify.net> wrote:
> [Please voluntarily trim replies to include only relevant quoted material.]
>
> Hi,
> Concerning the screen name, I would even generate a default unique
> screen name based upon the email address entered as login. e.g for me it
> would be pierre abel, or pierre abelxx (xx is a number) if pierre.abel
> already exists as a screen name.
> Note that that I don't mean changing the UI: This screen name would
> still be editable (i.e the field would only be filled automatically by
> the generated unique screen name).
> If the user edit the screen name and then creates an already existing
> screen name, then you suggest other possibilities as described in
> previous posts.
>
> Of course, it only works if you assume that most users don't want a
> special screen name (such as Snoopy or Toto ;-) ). And this depends on
> your context...
>
> Pierre
>
> Ben Hunt wrote:
>
> >[Please voluntarily trim replies to include only relevant quoted material.]
> >
> >The only reason ever to keep people in a blind guessing loop is for
> >security. That doesn't apply here.
> >
> >For the user name, if my first choice is not available, the next view can
> >combine multiple approaches:
> >
> >1) Suggestions using incremented numbers, e.g. benhunt9
> >2) Suggestions using any other data you know about me (could be derived
> >safely from my email address), e.g. benhuntuk or ben.hunt
> >3) What about a further five text boxes, where I can type up to 5 preferred
> >choices, in order of priority.
> >4) ..or a combination of the above..
> >
> >What we're looking for here is a name that is applicable to me, so I'd
> >probably prefer the multiple option (3).
> >
> >AJAX would be even better, so when I exit the field, or click 'Check', I see
> >a "Checking name" label, then if the name is unavailable, I'm alerted and
> >focus returns to the field.
> >
> >- Ben
> >
> >
> >-----Original Message-----
> >From: Tricia (Bluesky Consult) [mailto:tricia at blueskyconsult.com]
> >
> >So then we're back to the original discussion, the one about suggesting
> >unique names.
> >
> >When creating the third identifier, the unique "friendly name", is it a good
> >idea to suggest alternatives when the users requested name is unavailable or
> >is it better to let the user keep on trying to create his own unique name.
> >
> >Tricia
> >
> >
> >
> >________________________________________________________________
> >Welcome to the Interaction Design Association (IxDA)!
> >To post to this list ....... discuss at ixda.org
> >(Un)Subscription Options ... http://subscription-options.ixda.org/
> >Announcements List ......... http://subscribe-announce.ixda.org/
> >Questions .................. lists at ixda.org
> >Home ....................... http://ixda.org/
> >Resource Library ........... http://resources.ixda.org
> >
> >
> >
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>

25 Nov 2005 - 8:56am
Ben Hunt
2004

The problem with this in online communities is the risk of people pretending
to be someone else, possibly maliciously.

The risk exists because other users have no other data to go off to check
whether "CrazyHorse" is the site moderator CrazyHorse or some kid who's just
causing trouble.

That's because we can't see the person's face, hear their voice, or know
where they are in the physical world.

- Ben

-----Original Message-----
Lets face this, dont we have people with same names in real world?

Mike could be working with another Mike in the same office. Right?

And still we know the difference because their faces are different.

You can apply he saame principle here.

Let the users have similar ID's but validate based on their Email address.

Does it help?

Sajid

25 Nov 2005 - 10:18am
Jared M. Spool
2003

As for the idea that email addresses are unique, we've run into problems in
our testing. 1/3 of all email addresses change each year. We've seen many
folks who can't remember *which* email address they used to sign up, since
they often have many, some of which have gone obsolete. (That makes the
"send your password" functionality fail.)

This conversation keeps butting up against the Identity problem, as
discussed very nicely here http://www.identity20.com/media/OSCON2005/ by
Dick Hardt of Identity 2.0

Unfortunately, I don't have a solution for the problem.

Jared

Jared M. Spool, Founding Principal, User Interface Engineering
4 Lookout Lane, Unit 4d, Middleton, MA 01949
978 777-9123 jspool at uie.com http://www.uie.com
Blog: http://www.uie.com/brainsparks

25 Nov 2005 - 11:46pm
Andy Kirkwood, ...
2005

Ben: The ability to view posts attributed to each Crazy Horse would
address this issue. From the history you could confirm the identity
of the Crazy Horse that's 'running wild'.

It has to be acknowledged that what causes offense is determined by
the values of the individual. Online discussions are notorious for
perpetuating misunderstanding, often because contributors don't have
a shared frame of reference. In some cases the understandings of a
single word can be the root cause of dissent.

There's also the role of moderators who act on behalf of a community
to 'preserve the peace'. Even though you might meet one Crazy Horse
that you disagree with, you might meet another with whom you concur.
In the real world there are also those occasional situations where
people agree to disagree.

The practice of requiring personalised account names (handles) to be
unique is likely to be the result of early systems that stored the
handle as a primary key. (In terms of database structure at a
technical level a primary key cannot be duplicated.) A system that
prioritises the interests of people over the efficiencies of
technology would be more inclined to have four parts: ID (number),
email address, password and handle. Where the number is the primary
key automatically assigned by the system. Email address and password
used for authentication, and handle displayed to other community
members for the purposes of social responsibility.

--
Andy Kirkwood | Creative Director

Motive | web.design.integrity
http://www.motive.co.nz
ph: (04) 3 800 800 fx: (04) 970 9693
mob: 021 369 693
93 Rintoul St, Newtown
PO Box 7150, Wellington South, New Zealand

26 Nov 2005 - 6:18am
Ben Hunt
2004

Yes, it seems the discussion is centring on the cost/benefit balance of
requiring a unique Screen name / Handle / Friendly name.

I think there are enough words for a discrete site population to be able to
find a representative and useful unique screen name each.

And the argument that it's possible to differentiate two users with the same
screen name - by forensic processes - is not strong enough for me. It's
always possible to find out who's who, but confusion and the possibility of
causing offence or passing-off through impersonation can still happen before
that discovery is made.

On balance, I'm sticking with unique screen names.

- Ben

(p.s. Andy, I'm going to be in Leeds tonight to see NZ vs Oz in the
Tri-Nations final. I'll give a shout for the All Blacks..)

-----Original Message-----

Ben: The ability to view posts attributed to each Crazy Horse would address
this issue. From the history you could confirm the identity of the Crazy
Horse that's 'running wild'.

It has to be acknowledged that what causes offense is determined by the
values of the individual. Online discussions are notorious for perpetuating
misunderstanding, often because contributors don't have a shared frame of
reference. In some cases the understandings of a single word can be the root
cause of dissent.

There's also the role of moderators who act on behalf of a community to
'preserve the peace'. Even though you might meet one Crazy Horse that you
disagree with, you might meet another with whom you concur.
In the real world there are also those occasional situations where people
agree to disagree.

The practice of requiring personalised account names (handles) to be unique
is likely to be the result of early systems that stored the handle as a
primary key. (In terms of database structure at a technical level a primary
key cannot be duplicated.) A system that prioritises the interests of people
over the efficiencies of technology would be more inclined to have four
parts: ID (number), email address, password and handle. Where the number is
the primary key automatically assigned by the system. Email address and
password used for authentication, and handle displayed to other community
members for the purposes of social responsibility.

--
Andy Kirkwood | Creative Director

26 Nov 2005 - 7:46am
penguinstorm
2005

On Nov-26-2005, at 4:18 AM, Ben Hunt wrote:

> Yes, it seems the discussion is centring on the cost/benefit
> balance of
> requiring a unique Screen name / Handle / Friendly name.
>
> On balance, I'm sticking with unique screen names.

I thought this was defined as a requirement of the application? If it
is, and presuming the application design is completed, it no longer
becomes a cost/benefit issue.
--
Scott Nelson
skot at penguinstorm.com
http://www.penguinstorm.com/

skype. skot.nelson

26 Nov 2005 - 7:56am
penguinstorm
2005

On Nov-26-2005, at 5:46 AM, Skot Nelson wrote:

>
> On Nov-26-2005, at 4:18 AM, Ben Hunt wrote:
>
>> Yes, it seems the discussion is centring on the cost/benefit
>> balance of
>> requiring a unique Screen name / Handle / Friendly name.
>>
>> On balance, I'm sticking with unique screen names.

Sorry - I realize you may mean this in a more abstract, generalized
scenario rather than a specific comment on the app that this thread
was discussing. I hope that didn't sound too snippy.
--
Scott Nelson
skot at penguinstorm.com
http://www.penguinstorm.com/

skype. skot.nelson

25 Nov 2005 - 6:49pm
Anthony Colfelt
2005

> As for the idea that email addresses are unique, we've run into
> problems in
> our testing.

I agree with Jared's skepticism about email as a unique identifier.
When doing research to inform the design process to deliver a single
sign on system, we found that email is quite frequently not unique.
Aside from Jared's concerns, many families share one email address and
I don't think this is as small a number as we tend to think. Also,
some people don't have an email address. OK, so I can practically hear
the groans audibly about that statement, but its true. There are folks
who choose not to use email – admittedly they're in the minority of web
users. To make a authentication system open to anyone, you can't assume
that everyone has their own email address. Don't use it to authenticate
if uniqueness is a requirement.

The crux of the matter is to make the username memorable (regardless of
whether it becomes the screen name or not). This is because of all the
issues others have raised so far pertaining to one user – many online
accounts etc. We can assume that most people will not get their desired
username if they type in something they will easily remember (e.g.
their first name) because someone else will have got to it first. To
make this disappointment a little less frustrating, sophisticated
authentication systems append your chosen user name with some other
piece of personal data (e.g. birth year) as a suggested valid username.
They do this so that you don't endlessly keep trying and failing name
after name, building to a boiling point that results in a head-shaped
dent in your keyboard. However, this idea fails to create a name that
the user can truly identify with and remember. The solution we came up
with was to suggest names that were more emotionally engaging and
likely memorable. Instead of numbers, we appended the user's chosen
username with adjectives like 'Wicked', 'Marvelous' and 'Smelly'. I'd
rather be called 'AwesomeAnthony' than 'Anthony1976'. We allowed
different business units to customize their area's list of suggested
adjectives to closely reflect their brand identity. So for the News
site, they may choose to provide serious adjectives like 'Informed' or
'Aware'. The Kids site could offer 'Bodacious' or 'Gnarly' to their
registrants.

One other thing to remember is that this is the part that users dread
most. Even more than providing their intimate details. Most systems ask
you to fill out a whole form, including username at once. Uncertainty
arises from a user's previous experience with badly designed systems
where one error encountered on submitting the form reset the whole
thing to be refilled from scratch - ARGH! Our logic was to get this
username business over with, in a discreet step up front. This way
users don't have to fill out long reg forms unsure whether they'll get
the name they want and if it will remember all their other data in case
of a field error (incorrect username included). This could indeed be
aided with AJAX to allow users to quickly see which username would be
acceptable and providing suggestions dynamically. Back then, we had to
suffice with posting the form data and returning suggestions providing
another field to allow them to enter a totally new username.

Lastly, after successful registration, you need to make the "Forgot
Username" available as well as the "Forgot Password" at the point where
they may be stuck remembering either. For some reason, our business
folks wanted our single sign on system to be almost as secure as a
bank, so this wasn't possible for us. But the systems I like best are
those that don't require me to be at the email address with which I
registered, to get access to my account when I invariably forget my
security keys. You have a whole bunch of personally identifiable data
available, but mostly it is stuff that other people who know the user
could guess. So a security question is a good (and popular) mechanism
for allowing people to see or reset their password/uname. We found it
was better (and more secure) to allow the user to make up their own
question and answer it.

See the BBC Single Sign On system in action here:
http://www.bbc.co.uk/collective/ (this is one implementation of the
same system running across http://www.bbc.co.uk)
A little more about the process which got us there:
http://www.colfelt.com/applications/applications.shtml
A blog entry entitled "Tips for designing task based interaction flow"
I wrote about this SSO project:
http://www.colfelt.com/thevanityexperiment/archives/
design_ia_interaction/index.shtml#000093

Anthony Colfelt
http://www.colfelt.com/

26 Nov 2005 - 8:23pm
dszuc
2005

Understanding numbers (especially long ones) are harder to remember, but
perhaps as part of registration (if we are talking about an internal system)
users could use their "employee number" (which is unique) and then tie this
to their real name.

For further clarification on who John Smith is, you could use a photo or the
Department - to avoid clashes with other John Smith's who work at the
company?

Daniel Szuc
Principal Usability Consultant
Apogee Usability Asia Ltd
www.apogeehk.com
'Usability in Asia'

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com
[mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of Anthony
Colfelt
Sent: Saturday, November 26, 2005 8:49 AM
To: discuss at ixda.org
Subject: Re: [IxDA Discuss] suggested User ID's

[Please voluntarily trim replies to include only relevant quoted material.]

> As for the idea that email addresses are unique, we've run into
> problems in
> our testing.

I agree with Jared's skepticism about email as a unique identifier.
When doing research to inform the design process to deliver a single
sign on system, we found that email is quite frequently not unique.
Aside from Jared's concerns, many families share one email address and
I don't think this is as small a number as we tend to think. Also,
some people don't have an email address. OK, so I can practically hear
the groans audibly about that statement, but its true. There are folks
who choose not to use email - admittedly they're in the minority of web
users. To make a authentication system open to anyone, you can't assume
that everyone has their own email address. Don't use it to authenticate
if uniqueness is a requirement.

The crux of the matter is to make the username memorable (regardless of
whether it becomes the screen name or not). This is because of all the
issues others have raised so far pertaining to one user - many online
accounts etc. We can assume that most people will not get their desired
username if they type in something they will easily remember (e.g.
their first name) because someone else will have got to it first. To
make this disappointment a little less frustrating, sophisticated
authentication systems append your chosen user name with some other
piece of personal data (e.g. birth year) as a suggested valid username.
They do this so that you don't endlessly keep trying and failing name
after name, building to a boiling point that results in a head-shaped
dent in your keyboard. However, this idea fails to create a name that
the user can truly identify with and remember. The solution we came up
with was to suggest names that were more emotionally engaging and
likely memorable. Instead of numbers, we appended the user's chosen
username with adjectives like 'Wicked', 'Marvelous' and 'Smelly'. I'd
rather be called 'AwesomeAnthony' than 'Anthony1976'. We allowed
different business units to customize their area's list of suggested
adjectives to closely reflect their brand identity. So for the News
site, they may choose to provide serious adjectives like 'Informed' or
'Aware'. The Kids site could offer 'Bodacious' or 'Gnarly' to their
registrants.

One other thing to remember is that this is the part that users dread
most. Even more than providing their intimate details. Most systems ask
you to fill out a whole form, including username at once. Uncertainty
arises from a user's previous experience with badly designed systems
where one error encountered on submitting the form reset the whole
thing to be refilled from scratch - ARGH! Our logic was to get this
username business over with, in a discreet step up front. This way
users don't have to fill out long reg forms unsure whether they'll get
the name they want and if it will remember all their other data in case
of a field error (incorrect username included). This could indeed be
aided with AJAX to allow users to quickly see which username would be
acceptable and providing suggestions dynamically. Back then, we had to
suffice with posting the form data and returning suggestions providing
another field to allow them to enter a totally new username.

Lastly, after successful registration, you need to make the "Forgot
Username" available as well as the "Forgot Password" at the point where
they may be stuck remembering either. For some reason, our business
folks wanted our single sign on system to be almost as secure as a
bank, so this wasn't possible for us. But the systems I like best are
those that don't require me to be at the email address with which I
registered, to get access to my account when I invariably forget my
security keys. You have a whole bunch of personally identifiable data
available, but mostly it is stuff that other people who know the user
could guess. So a security question is a good (and popular) mechanism
for allowing people to see or reset their password/uname. We found it
was better (and more secure) to allow the user to make up their own
question and answer it.

See the BBC Single Sign On system in action here:
http://www.bbc.co.uk/collective/ (this is one implementation of the
same system running across http://www.bbc.co.uk)
A little more about the process which got us there:
http://www.colfelt.com/applications/applications.shtml
A blog entry entitled "Tips for designing task based interaction flow"
I wrote about this SSO project:
http://www.colfelt.com/thevanityexperiment/archives/
design_ia_interaction/index.shtml#000093

Anthony Colfelt
http://www.colfelt.com/
________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss at ixda.org
(Un)Subscription Options ... http://subscription-options.ixda.org/
Announcements List ......... http://subscribe-announce.ixda.org/
Questions .................. lists at ixda.org
Home ....................... http://ixda.org/
Resource Library ........... http://resources.ixda.org

27 Nov 2005 - 1:20am
Andy Kirkwood, ...
2005

Hi Anthony,

>I agree with Jared's skepticism about email as a unique identifier.
>When doing research to inform the design process to deliver a single
>sign on system, we found that email is quite frequently not unique.

...although there can only be one recipient account per email address.

>To make a authentication system open to anyone, you can't assume
>that everyone has their own email address. Don't use it to authenticate
>if uniqueness is a requirement.

If the system is something like a community/forum then even if more than one family member uses the same email address, they would still need to know the URL of the log-in page and the associated password. (Authentication would be through the combination of email address and password.)

>many families share one email address and
>I don't think this is as small a number as we tend to think. Also,
>some people don't have an email address. OK, so I can practically hear
>the groans audibly about that statement, but its true. There are folks
>who choose not to use email - admittedly they're in the minority of web
>users.

A reason why an email address is preferable is due to the concept of social responsibility. A current email address is the nearest thing to a physical contact point in the virtual world. A user without an email address may be considered something of a 'rogue agent'. In a scenario where abuse has caused a user to be banned, if the system requires an email address to create a new account, then there is an additional 'hurdle' to prevent an individual resigning using a new alias.

> The solution we came up
>with was to suggest names that were more emotionally engaging and
>likely memorable. Instead of numbers, we appended the user's chosen
>username with adjectives like 'Wicked', 'Marvelous' and 'Smelly'. I'd
>rather be called 'AwesomeAnthony' than 'Anthony1976'. We allowed
>different business units to customize their area's list of suggested
>adjectives to closely reflect their brand identity. So for the News
>site, they may choose to provide serious adjectives like 'Informed' or
>'Aware'. The Kids site could offer 'Bodacious' or 'Gnarly' to their
>registrants.

Although the solutions noted are memorable, they're still working around the questionable 'need' for a handle to be unique. In most cases I'm assuming that a unique handle has been presented as a requirement, as it is used for the purposes of monitoring or moderating behaviour. In such situations the handle must 'lead' to an individual who is held accountable for their actions. This type of functionality does not require the handle to be unique, only that the handle can be traced back to an individual.

It would be interesting to hear alternative business case(s) for this requirement.

If offered the choice between entering the name I would choose to be known by, or grafting on a branding-related adjective, my preference is for the former ;)

If the issue is memorability then this is more likely when is key is used frequently (as is the case with email addresses) or when the key is self-selected.

Thoughts?

--
Andy Kirkwood | Creative Director

Motive | web.design.integrity
http://www.motive.co.nz
ph: (04) 3 800 800 fx: (04) 970 9693
mob: 021 369 693
93 Rintoul St, Newtown
PO Box 7150, Wellington South, New Zealand

27 Nov 2005 - 4:50am
Anthony Colfelt
2005

Hi Andy

> A reason why an email address is preferable is due to the concept of
> social responsibility. A current email address is the nearest thing to
> a physical contact point in the virtual world.

In our case, we still used email address to authenticate a user, not as
a "security key" as entered into the system to log-in, but rather as a
mechanism to ensure that a registrant was traceable (reinforcing the
'social responsibility' idea you mentioned). The registration was not
activated until the registrant confirmed they had received a
'confirmation email'. I agree that the combination of email address and
password is good enough in many cases to authenticate a user. However,
our security guys didn't feel that any two people should be allowed the
same log-in key because in the case that two accounts used the same
log-in key (i.e. email address) the odds of someone guessing another's
password would be enhanced significantly, since they would only need to
crack one security key rather than two.

> Although the solutions noted are memorable, they're still working
> around the questionable 'need' for a handle to be unique. In most
> cases I'm assuming that a unique handle has been presented as a
> requirement, as it is used for the purposes of monitoring or
> moderating behaviour. In such situations the handle must 'lead' to an
> individual who is held accountable for their actions. This type of
> functionality does not require the handle to be unique, only that the
> handle can be traced back to an individual.

Allow me to make another clarification about the system we designed.
BBC Single Sign On never shows the log-in key (username) to the public.
Instead, the user chooses another screen name (handle) that is separate
from the log-in key, which does not need to be unique. This allows a
users single account to have a different handle per community (if
desired). Some communities discard the screen name idea and use a
user's real name for a handle (showing a real identity can create a
desirable community dynamic in certain circumstances). I would say this
was a pretty unique requirement given we had widely varying communities
to which the same user may belong. Most authentication systems don't
have to serve more than one community or brand. Yes, there are
sometimes problems with confusion between screen name (handle) and
log-in key (username), but they don't outweigh the security
requirements.

> If the issue is memorability then this is more likely when is key is
> used frequently (as is the case with email addresses) or when the key
> is self-selected.

So again, I agree with you that in an ideal world you would allow any
log-in key and use the unique combination of that and a password to
authenticate. Email is a good and memorable log-in key, however,
Jared's point about users changing their email addresses is not a moot
one. This happens and does so relatively frequently. I guess you need
to make a value judgment respective to expected tenure of a
registration. Short-term accounts should be served by email in this
manner with infrequent problems. Long-term ones will be affected by a
change in address (or three).

In our case, we were building a system that is a little more robust in
terms of security than most, so our model may not be fitting for all.
But by the sound of Tricia's original posts, there was little
compromise to be made on the requirement of a unique log-in key. This
was the case for us too.

Anthony Colfelt
http://www.colfelt.com/

27 Nov 2005 - 5:50am
Ben Hunt
2004

This simple problem is unfolding into something not all that simple at
all...

Our current thinking uses some or all of the following set of data for user
identification:

- User primary key, private for internal use only
- Unique UserID, used for authentication only
- Password, used for authentication only
- Screen name, used for interpersonal identification (may require to be
unique)
- Email address, used for communication from system to user outside the
normal flow. *May* be the same as the UserID (may be kept private from other
users)

We're all working on the assumption that *TWO* private are required to
authenticate a user.

While this is traditional, can we challenge it by suggesting a single key,
i.e. Pass-key? This would have to be unique within the system, of course.

If an Email address and is used for system > user communication, then it may
serve to use it as an extra key for authentication as well. But how much
benefit? And, as we've said, not everybody has an email address of their
own.

-- Ben

27 Nov 2005 - 8:18am
Dave Malouf
2005

> We're all working on the assumption that *TWO* private are required to
> authenticate a user.
>
> While this is traditional, can we challenge it by suggesting
> a single key,
> i.e. Pass-key? This would have to be unique within the
> system, of course.

Actually, many institutions are moving the other direction. From 2 keys to 3
keys. We seem to use the word token a lot in our work instead of Key. I
don't know what the standard is though.

I work in the pharma and financial communities. And NOT on the consumer
facing side. What I have learned here is that even doing something as
"ordinary" as saving one of the tokens in a cookie so that the user only has
to type the other token is not allowed. B/c in essence that would be
eliminating one of the 2 tokens.

What they would rather do is have a 3 token system:
1. "username" or "e-mail address" - in this world EVERYONE has an individual
e-mail address. Actually we have the opposite problem--people have more than
one alias for the same mailbox, i.e. dheller at blah.com or
david.heller at blah.com and since they never write e-mail to themselves they
often forget which one to put.

2. A password of some type. They want to enable strong passwords: no matches
against a dictionary, must have some case change, a number AND a special
character, and be atleast *8* characters long.

3. A physical or biometric token. This token is tied to a networked
authentication system. The token is phyiscally distributed with a digital
signature key--i.e. you have to pick it up at a bank, or your organization
has to be authorized to distribute, or you have a distribution agreement
with a distribution vendor.

Howz them apples.

Security is a wonderous topic. It is not completely business stakeholder
driven, but it does go against some core usability principles. On the
end-user side, tough authentication methods do one thing that they like. It
makes them feel like what they are doing on that system is safe, secure, and
private. So while it is harder to use, many an end-user would rather
sacrifice usability in this area for "the greater good".

-- dave

David Heller
V.P. IxDA
dave (at) ixda (dot) org
http://ixda.org/
http://synapticburn.com/

AIM: bolinhanyc | Y!: dave_ux
MSN: hippiefunk (at) hotmail (dot) com
Google Talk: dheller (at) gmail (dot) com

27 Nov 2005 - 8:44am
penguinstorm
2005

On Nov-27-2005, at 6:18 AM, David Heller wrote:

> What I have learned here is that even doing something as
> "ordinary" as saving one of the tokens in a cookie so that the user
> only has
> to type the other token is not allowed. B/c in essence that would be
> eliminating one of the 2 tokens.

Interesting. I've done quite a bit of work in financial, and I would
certainly give users the *option* of saving one of the tokens (i.e.
bank card number) in a cookie.

I'd make the cookie using only organic ingredients though; you wanna
make sure that puppy goes stale pretty quickly with an expiration
date of only a couple of weeks or so. Those perma-cookies that last
forever aren't good for financial stuff.
--
Scott Nelson
skot(at)penguinstorm(dot)com
http://www.penguinstorm.com/

skype. skot.nelson

27 Nov 2005 - 8:54am
Dave Malouf
2005

> Interesting. I've done quite a bit of work in financial, and I would
> certainly give users the *option* of saving one of the tokens (i.e.
> bank card number) in a cookie.

I think this brings up an interesting piece. Is there "one" of any vertical.

In my line of "financial" we deal with strict compliance regulations and
top-secret M&A and private investor information. The type of information
that would never go outside of a firewall, but our software is just for
enabling the distribution of secured info beyond the firewall to the "right"
party.

We even have some customers so scared about the transfering of information
(despite how well DRM software works) that we have a service that prevents
users from looking at information across different machines even if they use
the same exact authentication credentials.

Like I said before, this is NOT for the consumer markets like an online
banking system. This is for strict due-dilegence and regulatory auditing
environments. If someone can question your audit trail to the slightest
degree, then you might be facing some big fines or worse loose a deal. When
a single deal can be billions of dollors, you up the ante. ;)

Now for consumers, I think someone said that banks have a lot of pull in
making users jump through hoops. I think they have this pull because
security and privacy are such big fears in the cyber world these days.

As to the original question of pushing a user name to a user. I just don't
see the plus for any system. Why? b/c they are going to do one of 3 things:
1. write it down (doh! There goes your security. Do you really want people
writing down uid's and passwords?)
2. forget it - thus having them to constantly re-set or re-get their
information, which is a bad UX.
3. save it in e-mail, or some other digital archive (see #1).

(ok, there is a 4th unlikely option ... They remember it and use it
happily.)

I much prefer coming up with my own names b/c I tend to repeat names and
passwords, which makes it easier for me to remember. ;) (see #1)

-- dave

27 Nov 2005 - 9:00am
penguinstorm
2005

On Nov-27-2005, at 6:54 AM, David Heller wrote:

> In my line of "financial" we deal with strict compliance
> regulations and
> top-secret M&A and private investor information.
> <snip>.
> Like I said before, this is NOT for the consumer markets like an
> online
> banking system.

Oh yes. Quite different than what I've done. Quite different indeed.
Makes much more sense.
--
Scott Nelson
skot(at)penguinstorm(dot)com
http://www.penguinstorm.com/

skype. skot.nelson

27 Nov 2005 - 12:57pm
Todd Warfel
2003

Just to play devil's advocate here, and because I'm curious...

On Nov 25, 2005, at 7:49 PM, Anthony Colfelt wrote:

> When doing research to inform the design process to deliver a
> single sign on system, we found that email is quite frequently not
> unique.

I'm curious how in the world email addresses are not unique,
especially since email systems are set up so that they are unique to
an individual. So, can you elaborate on this a bit more.

> Aside from Jared's concerns, many families share one email address
> and I don't think this is as small a number as we tend to think.

Would this be a problem in this situation?

> Also, some people don't have an email address. OK, so I can
> practically hear the groans audibly about that statement, but its
> true. There are folks who choose not to use email – admittedly
> they're in the minority of web users. To make a authentication
> system open to anyone, you can't assume that everyone has their own
> email address. Don't use it to authenticate if uniqueness is a
> requirement.

Statistical anomaly (edge case). We don't design toward those. That's
where scope creep and the MS way come into play and then products
either never come out, or are half-baked. Also, I think in the case
of an ecommerce site, or web-based application, we can expect that
those audiences do have email.

Out of curiosity, have you noticed any trends of types of audiences
who are less likely to have email?

Cheers!

Todd R. Warfel
Partner, Design & Usability Specialist
Messagefirst | designing and usability consulting
--------------------------------------
Contact Info
Voice: (607) 339-9640
Email: todd at messagefirst.com
AIM: twarfel at mac.com
Blog: http://toddwarfel.com
--------------------------------------
In theory, theory and practice are the same.
In practice, they are not.

27 Nov 2005 - 2:38pm
Andy Kirkwood, ...
2005

Thanks to all who have contributed to this discussion to date, the most well-informed and considered responses I've come across in some time ('big ups').

Anthony: With your point regarding short and long-term relationships, I would have thought the reverse of the proposed model were more appropriate?
- short-term = less social responsibility = no requirement for email
- long-term = greater responsibility = require email

It's also worth considering alternative responses to the usability observation that "People frequently change their email addresses". People also change their postal addresses, however it is expected that the individual will inform the post office if (physical) mail is to be redirected.

If the concern is that the user are likely to change email address, then the system should make provision for the email address to be updated. In other words, the email address should not be the primary key. Once a new email address has been entered they user would then use the new email address and existing password for authentication purposes. Historical action/posts would remain linked to the system-determined (and non-editable) ID.

Although we can aim to make systems more memorable and secure, ultimately the user must assume responsibility for their own security practices. We can help by advising on best practise when choosing a password, etc., however as systems are not standardised, the one consistent 'factor': the behaviour of users, also needs to be modified. The often cited example is where overzealous security processes result in users post-it-noting their current account details to the side of the monitor...

>Now for consumers, I think someone said that banks have a lot of pull in
>making users jump through hoops. I think they have this pull because
>security and privacy are such big fears in the cyber world these days.

David: The are a couple of banking models in New Zealand that you might be interested in:

NETCODE
ASB has introduced a 'netcode'. For any electronic transfers over a user determined threshold value (the current default is $800), the user must enter a SMS/TXT code.

Process
-transaction is entered using the online banking system
-if transaction is over the set threshold, an additional authentication screen is displayed requesting a netcode
-an authentication code is sent to the account holder's cell/mobile phone
-the account holder enters the code to verify the transaction
-the code remains 'active' until the end of the current user session
Netcode article: < http://www.asbbank.co.nz/netcode/default.asp >

CAPTCHA
An alternative/supplementary method of preventing program-based security attack is by adding a completely automated public Turing test to tell computers and humans apart (CAPTCHA) to the mix. New Zealand's Kiwibank requires:
- account number (chosen by the bank)
- user-selected password (from memory, more than 6 characters, mix of alpha-numeric characters)
- CAPTCHA: a randomly-generated distorted bitmap image

The CAPTCHA severely curtails the use of a program to 'guess' the account password, as each log in attempt generates a new bitmap image.
KiwiBank login screen < https://www.kiwibank.co.nz/banking/login.asp >
CAPTCHA < http://www.captcha.net/captchas/ >

--
Andy Kirkwood | Creative Director

Motive | web.design.integrity
http://www.motive.co.nz
ph: (04) 3 800 800 fx: (04) 970 9693
mob: 021 369 693
93 Rintoul St, Newtown
PO Box 7150, Wellington South, New Zealand

Syndicate content Get the feed