The website of The Auteurs does it that way:
I think that it comes down to appropriate segmenting of the items presented
in the form and the type of registration that is being filled out, a
utility/bank registration area will have multiple fields where e-mail might
be required but a contact number is optional.
Check out Chris Messina's screenshots of sign-up forms for more
clarification on your concern:
In my experience, and what I do day to day, I segment content by it's type
(contact information, personal data, log-in information, etc) and I clarify
the fields that are required vs the ones that are optional, I do not assume
the * tells the whole story, nor do I rely on it. Luke W's book on form
design is fascinating for this http://www.rosenfeldmedia.com/books/webforms/
On Fri, Oct 16, 2009 at 7:54 AM, jennifer <chicgeek75 at gmail.com> wrote:
> When the form requires other personal info, e.g., First name, Last
> name, etc... have you come across sites that first ask for email
> So, the order - displayed all at once on the same screen:
> First Name Last Name
> Job Function
> Seems a bit odd for me. Makes sense when *all* that is required is
> email a password. But what about when the form has all that other
> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> Posted from the new ixda.org
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
I'm with you, Jennifer. I think it's weird for email to come first
if the form is also asking for my name. I think we've been
conditioned to always expect to put down our name first. It makes
sense to the online marketer side of me to ask for email first, but
not to the rest of me.
I know we've done forms in the past where the email is all that is
required upfront. Then, once they've supplied that, we ask for name,
and other applicable fields. The idea is that once we have the email,
we can communicate with the person - all the rest is just "nice to
Senior Interactive Architect
lkruger at convio.com
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
Could it be that the database guys use email address as the record
identifier, so *they* think of it first, and that's how it came to
be first on your form? It doesn't help the user, though.
On Oct 16, 2009, at 12:55 PM, jennifer wrote:
> Has anyone seen any web forms that start off with an email field?
One thing that nobody else has mentioned is the context of your
registration form is in. What promise do you make the user, in return
for their information?
If, for example, you're asking them to register for an email
newsletter, then having the email address as the first field might
make sense. On the other hand, if you're asking them to register for
another reason, then email address as the first field might feel
awkward. The context is important.
In many situations, users get anxious when you ask them for an email
address, especially if you don't clearly explain why you need it. They
fear that they'll start receiving spam or phishing requests. In your
form design, are you clearly explaining why you are asking for the
information and what you're intending to do with it?
Simple usability tests should tell you quickly if your form is awkward
or natural. I always recommend getting your design in front of some
test participants to get some quick feedback.
Jared M. Spool
User Interface Engineering
510 Turnpike St., Suite 102, North Andover, MA 01845
e: jspool at uie.com p: +1 978 327 5561
http://uie.com Blog: http://uie.com/brainsparks Twitter: @jmspool
Users are increasingly more comfortable with using their email address
as a credential. In fact, web citizens who prefer anonymity would
rather offer their email than their legal name. An email also is
unique, a huge advantage over using legal names on forms. I would
suggest that users in general prefer to offer "nicknames" rather
than their legal name when the identifier will be used on something
like comment threads for controversial news stories.
Think of a user's online connections as very wobbly looking wheel..
When making connections, users are extending an endless amount of
interactive spokes with their email being the hub. Without that
connection to the hub, users can't expect important status updates,
reply notifications etc. The value of a product/service which only
leaves disconnected artifacts "somewhere out there" is
Even with the robust spam filtering most of us now enjoy, user data
etiquette is critical. Jared mentioned "promises" and assistant
text. I wonder if we as a community could agree on standard ways to
address this consistently across all the products we design. For
example, we could agree to always pair sensitive data entry fields
with "How will this be used?"(As a public identifier, account
credential, etc) controls. I see this being done sporadically, and we
could all benefit from respecting common standards.
<snip - background on the forms she's working on>
> What this makes me think of is something I'm continually being asked
> by my manager and stakeholders, "Do you have any documented best
> practices on X?" And, though I find tons of awesome articles by all
> you wonderful people here, what is really desired is a 'checklist'
> of best practices.
I'm going to interpret this as "Why did you write a book (and a bunch of
articles) instead of the checklist of best practices that we actually need?"
And now I'm going to brood on an answer:
I don't have a problem with checklists. Mine might run something like this:
1. Find out what your users want to do
2. Establish the relative importance to them of filling in the form compared
to what they want to do
3. Find out what your organisation actually does with each data item you
4. For every item you ask for, think very hard whether the value to your
organisation outweighs the risk of losing a user who doesn't want to give it
5. Write questions that are easy to answer
6. Create a flow that puts questions into a logical order
7. Think hard about whether your validation will encourage correct
completion, or will simply force a user into giving you the wrong answer
8. Make it look good
9. Run loads of usability tests, and make use of the findings.
10. If in doubt about what to do, see item 9 and repeat as often as you can.
First possible problem: I think that the type of checklist some people want
(probably not you) is a lot more trivial than that and contains advice like
"put the labels above the fields". Or maybe "put the labels to the left of
the fields". The trouble with bits of advice like that is that users don't
care all that much where the labels go, but they do really, really care
about what they're being asked and the context they are being asked it in.
Items 1 and 2 on my list, but things that have to be thought about rather
than issued as instructions.
Second possible problem: the checklist tends to require a follow-up here and
there. For example: What exactly are questions that are easy to answer? What
does answering a question actually mean?
So why did I write a book? Hmm, a moment of madness, maybe? But also because
I thought it might help people to have a short overview of the topic from
beginning to end.
And we did keep it to under 200 pages.
Should I have written a checklist instead? Probably. I've written this email
in about 10 minutes and it took 10 years of anguish to write the book. Only,
maybe I was only able to write a 10-item checklist *because* of the 10 years
of anguish - and the several years before that of thinking about the
problems. Maybe the checklist doesn't work for you either...
Anyway. Hope this helps.