task flow pattern question

12 Nov 2003 - 3:05am
10 years ago
16 replies
1088 reads
tim[othy] martens
2003

Hi,

I'm building a simple one page (three fieldset: trip info, personal
info, payment info) online reservation form and need to create a
functional spec of the task flow. My question is about the consensus
concerning this or similar patterns. I'm wondering specifically, if
users generally desire or require a "please review your information"
before submitting your final order page or if that's just an extra
(unnecessary) step considering they're "reviewing" the information on
the form page as they're filling it our /and /that the form will have
built in error checking which will return a facsimile of the page with
incorrect field(s) highlighted.

Thanks,

-t

Comments

12 Nov 2003 - 8:53am
Dave Malouf
2005

Yes!

Whenever you have a payment, there needs to be a confirmation screen. People
are incredibly uncomfortable w/ payment over the net and if you are dealing
w/ everyday people they will even req. this (never clicking the first submit
button) if they do not have a clearly stated step through process which
includes a confirm screen.

Question? Why do you need the 3 fieldsets on one screen? Seems that the trip
info I my "shopping cart" and the personal/payment info is part of the
fulfillment process (if I can assume a lot about your app). Connecting these
explicitly as you have might also be a sore spot for people who will feel
overwhelmed with the "shopping" aspect.

-- dave

-----Original Message-----
From:
discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
[mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesigners.
com] On Behalf Of tim[othy] martens
Sent: Wednesday, November 12, 2003 3:06 AM
To: discuss-interactiondesigners.com at lists.interactiondesigners.com
Subject: [ID Discuss] task flow pattern question

Hi,

I'm building a simple one page (three fieldset: trip info, personal info,
payment info) online reservation form and need to create a functional spec
of the task flow. My question is about the consensus concerning this or
similar patterns. I'm wondering specifically, if users generally desire or
require a "please review your information"
before submitting your final order page or if that's just an extra
(unnecessary) step considering they're "reviewing" the information on the
form page as they're filling it our /and /that the form will have built in
error checking which will return a facsimile of the page with incorrect
field(s) highlighted.

Thanks,

-t

_______________________________________________
Interaction Design Discussion List
discuss at interactiondesigners.com
--
to change your options (unsubscribe or set digest):
http://discuss.interactiondesigners.com
--
Questions: lists at interactiondesigners.com
--
Announcement Online List (discussion list members get announcements already)
http://interactiondesigners.com/announceList/
--
http://interactiondesigners.com/

12 Nov 2003 - 8:55am
Bruce Wyman
2003

>if users generally desire or require a "please review your
>information" before submitting your final order page or if that's
>just an extra (unnecessary) step considering they're "reviewing" the
>information on the form page as they're filling it our /and /that
>the form will have built in error checking which will return a
>facsimile of the page with incorrect field(s) highlighted.

Without specific backing data at my fingertips, I'd posit that the
review page acts as the oportunity not for the user so much to check
their work, but to verify that the software is actually processing
the right information or is at least working as expected.

It strikes me as parallel as going to a restaurant and when the wait
staff verify your order back to you. It's not to make sure you said
the right things, but to make sure that they've correctly parsed your
intent.

-bw.
--

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Bruce Wyman e: <bwyman at nearlife.com>
Director of Creative Development v: 617.491.3184
Nearlife f: 617.354.4191
147 Sherman Street, Cambridge, MA 02140 w: <http://www.nearlife.com/>

12 Nov 2003 - 12:10pm
Peter Bagnall
2003

No! ;-) (couldn't resist)

What about Amazon though? For one-click they only have a confirmation
screen after the transaction has occurred. The way they deal with this
is allow you to undo the transaction within about 90 minutes. gives the
same level of comfort (arguably), but without the extra step.

I suppose that could be considered a confirmation screen, but it's not
an "are you sure" screen.

Why does this work for Amazon? Is it due to the reputation? Does that
mean that it wouldn't work for unknown web vendors? I don't know, but
I'd be interested to hear views on it. There are major differences with
amazon of course. 1-click assumes you've set up your details before,
which probably means you've shopped with them in the past. For first
time shoppers then it's possible that Dave is entirely correct, but it
would be interesting to know what the important factor is that
determines whether 1-click like behaviour is acceptable or not.

Just thought I'd stir!

Cheers
--Pete

On Wednesday, Nov 12, 2003, at 13:53 Europe/London, David Heller wrote:

> Yes!
>
> Whenever you have a payment, there needs to be a confirmation screen.
> People
> are incredibly uncomfortable w/ payment over the net and if you are
> dealing
> w/ everyday people they will even req. this (never clicking the first
> submit
> button) if they do not have a clearly stated step through process which
> includes a confirm screen.
>
> Question? Why do you need the 3 fieldsets on one screen? Seems that
> the trip
> info I my "shopping cart" and the personal/payment info is part of the
> fulfillment process (if I can assume a lot about your app). Connecting
> these
> explicitly as you have might also be a sore spot for people who will
> feel
> overwhelmed with the "shopping" aspect.
>
> -- dave
>
> -----Original Message-----
> From:
> discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
> [mailto:discuss-interactiondesigners.com-
> bounces at lists.interactiondesigners.
> com] On Behalf Of tim[othy] martens
> Sent: Wednesday, November 12, 2003 3:06 AM
> To: discuss-interactiondesigners.com at lists.interactiondesigners.com
> Subject: [ID Discuss] task flow pattern question
>
> Hi,
>
> I'm building a simple one page (three fieldset: trip info, personal
> info,
> payment info) online reservation form and need to create a functional
> spec
> of the task flow. My question is about the consensus concerning this or
> similar patterns. I'm wondering specifically, if users generally
> desire or
> require a "please review your information"
> before submitting your final order page or if that's just an extra
> (unnecessary) step considering they're "reviewing" the information on
> the
> form page as they're filling it our /and /that the form will have
> built in
> error checking which will return a facsimile of the page with incorrect
> field(s) highlighted.
>
> Thanks,
>
> -t
>
> _______________________________________________
> Interaction Design Discussion List
> discuss at interactiondesigners.com
> --
> to change your options (unsubscribe or set digest):
> http://discuss.interactiondesigners.com
> --
> Questions: lists at interactiondesigners.com
> --
> Announcement Online List (discussion list members get announcements
> already)
> http://interactiondesigners.com/announceList/
> --
> http://interactiondesigners.com/
>
> _______________________________________________
> Interaction Design Discussion List
> discuss at interactiondesigners.com
> --
> to change your options (unsubscribe or set digest):
> http://discuss.interactiondesigners.com
> --
> Questions: lists at interactiondesigners.com
> --
> Announcement Online List (discussion list members get announcements
> already)
> http://interactiondesigners.com/announceList/
> --
> http://interactiondesigners.com/
>

12 Nov 2003 - 12:13pm
Dave Malouf
2005

Chris,
I think that Amazon "succeeds" at this b/c it is something you configure to
use.
BTW, I never use it b/c I don't trust it. ;)

But the fact that it is ONE way of using the fulfillment system as opposed
to THE way to use the fulfillment system makes a HUGE difference.

I also think that the other reasons you mention below are also important at
some level the most important one being brand.

-- dave

-----Original Message-----
From: Peter Bagnall [mailto:pete at surfaceeffect.com]
Sent: Wednesday, November 12, 2003 12:11 PM
To: David Heller
Cc: discuss at interactiondesigners.com
Subject: Re: [ID Discuss] task flow pattern question

No! ;-) (couldn't resist)

What about Amazon though? For one-click they only have a confirmation screen
after the transaction has occurred. The way they deal with this is allow you
to undo the transaction within about 90 minutes. gives the same level of
comfort (arguably), but without the extra step.

I suppose that could be considered a confirmation screen, but it's not an
"are you sure" screen.

Why does this work for Amazon? Is it due to the reputation? Does that mean
that it wouldn't work for unknown web vendors? I don't know, but I'd be
interested to hear views on it. There are major differences with amazon of
course. 1-click assumes you've set up your details before, which probably
means you've shopped with them in the past. For first time shoppers then
it's possible that Dave is entirely correct, but it would be interesting to
know what the important factor is that determines whether 1-click like
behaviour is acceptable or not.

Just thought I'd stir!

Cheers
--Pete

On Wednesday, Nov 12, 2003, at 13:53 Europe/London, David Heller wrote:

> Yes!
>
> Whenever you have a payment, there needs to be a confirmation screen.
> People
> are incredibly uncomfortable w/ payment over the net and if you are
> dealing w/ everyday people they will even req. this (never clicking
> the first submit
> button) if they do not have a clearly stated step through process
> which includes a confirm screen.
>
> Question? Why do you need the 3 fieldsets on one screen? Seems that
> the trip info I my "shopping cart" and the personal/payment info is
> part of the fulfillment process (if I can assume a lot about your
> app). Connecting these explicitly as you have might also be a sore
> spot for people who will feel overwhelmed with the "shopping" aspect.
>
> -- dave
>
> -----Original Message-----
> From:
> discuss-interactiondesigners.com-bounces at lists.interactiondesigners.co
> m
> [mailto:discuss-interactiondesigners.com-
> bounces at lists.interactiondesigners.
> com] On Behalf Of tim[othy] martens
> Sent: Wednesday, November 12, 2003 3:06 AM
> To: discuss-interactiondesigners.com at lists.interactiondesigners.com
> Subject: [ID Discuss] task flow pattern question
>
> Hi,
>
> I'm building a simple one page (three fieldset: trip info, personal
> info, payment info) online reservation form and need to create a
> functional spec of the task flow. My question is about the consensus
> concerning this or similar patterns. I'm wondering specifically, if
> users generally desire or require a "please review your information"
> before submitting your final order page or if that's just an extra
> (unnecessary) step considering they're "reviewing" the information on
> the form page as they're filling it our /and /that the form will have
> built in error checking which will return a facsimile of the page with
> incorrect
> field(s) highlighted.
>
> Thanks,
>
> -t
>
> _______________________________________________
> Interaction Design Discussion List
> discuss at interactiondesigners.com
> --
> to change your options (unsubscribe or set digest):
> http://discuss.interactiondesigners.com
> --
> Questions: lists at interactiondesigners.com
> --
> Announcement Online List (discussion list members get announcements
> already)
> http://interactiondesigners.com/announceList/
> --
> http://interactiondesigners.com/
>
> _______________________________________________
> Interaction Design Discussion List
> discuss at interactiondesigners.com
> --
> to change your options (unsubscribe or set digest):
> http://discuss.interactiondesigners.com
> --
> Questions: lists at interactiondesigners.com
> --
> Announcement Online List (discussion list members get announcements
> already)
> http://interactiondesigners.com/announceList/
> --
> http://interactiondesigners.com/
>

12 Nov 2003 - 12:14pm
Dave Malouf
2005

Sorry about that ... I mean to say,

Peter,
....

Sorry peter.

-- dave

-----Original Message-----
From: Peter Bagnall [mailto:pete at surfaceeffect.com]
Sent: Wednesday, November 12, 2003 12:11 PM
To: David Heller
Cc: discuss at interactiondesigners.com
Subject: Re: [ID Discuss] task flow pattern question

No! ;-) (couldn't resist)

What about Amazon though? For one-click they only have a confirmation screen
after the transaction has occurred. The way they deal with this is allow you
to undo the transaction within about 90 minutes. gives the same level of
comfort (arguably), but without the extra step.

I suppose that could be considered a confirmation screen, but it's not an
"are you sure" screen.

Why does this work for Amazon? Is it due to the reputation? Does that mean
that it wouldn't work for unknown web vendors? I don't know, but I'd be
interested to hear views on it. There are major differences with amazon of
course. 1-click assumes you've set up your details before, which probably
means you've shopped with them in the past. For first time shoppers then
it's possible that Dave is entirely correct, but it would be interesting to
know what the important factor is that determines whether 1-click like
behaviour is acceptable or not.

Just thought I'd stir!

Cheers
--Pete

On Wednesday, Nov 12, 2003, at 13:53 Europe/London, David Heller wrote:

> Yes!
>
> Whenever you have a payment, there needs to be a confirmation screen.
> People
> are incredibly uncomfortable w/ payment over the net and if you are
> dealing w/ everyday people they will even req. this (never clicking
> the first submit
> button) if they do not have a clearly stated step through process
> which includes a confirm screen.
>
> Question? Why do you need the 3 fieldsets on one screen? Seems that
> the trip info I my "shopping cart" and the personal/payment info is
> part of the fulfillment process (if I can assume a lot about your
> app). Connecting these explicitly as you have might also be a sore
> spot for people who will feel overwhelmed with the "shopping" aspect.
>
> -- dave
>
> -----Original Message-----
> From:
> discuss-interactiondesigners.com-bounces at lists.interactiondesigners.co
> m
> [mailto:discuss-interactiondesigners.com-
> bounces at lists.interactiondesigners.
> com] On Behalf Of tim[othy] martens
> Sent: Wednesday, November 12, 2003 3:06 AM
> To: discuss-interactiondesigners.com at lists.interactiondesigners.com
> Subject: [ID Discuss] task flow pattern question
>
> Hi,
>
> I'm building a simple one page (three fieldset: trip info, personal
> info, payment info) online reservation form and need to create a
> functional spec of the task flow. My question is about the consensus
> concerning this or similar patterns. I'm wondering specifically, if
> users generally desire or require a "please review your information"
> before submitting your final order page or if that's just an extra
> (unnecessary) step considering they're "reviewing" the information on
> the form page as they're filling it our /and /that the form will have
> built in error checking which will return a facsimile of the page with
> incorrect
> field(s) highlighted.
>
> Thanks,
>
> -t
>
> _______________________________________________
> Interaction Design Discussion List
> discuss at interactiondesigners.com
> --
> to change your options (unsubscribe or set digest):
> http://discuss.interactiondesigners.com
> --
> Questions: lists at interactiondesigners.com
> --
> Announcement Online List (discussion list members get announcements
> already)
> http://interactiondesigners.com/announceList/
> --
> http://interactiondesigners.com/
>
> _______________________________________________
> Interaction Design Discussion List
> discuss at interactiondesigners.com
> --
> to change your options (unsubscribe or set digest):
> http://discuss.interactiondesigners.com
> --
> Questions: lists at interactiondesigners.com
> --
> Announcement Online List (discussion list members get announcements
> already)
> http://interactiondesigners.com/announceList/
> --
> http://interactiondesigners.com/
>

12 Nov 2003 - 12:49pm
Meikel Steiding
2003

Hi all

i just subscribed to the list and i would like to add just a little
thing to the button layout.

As people started to mention amazon here there is one thing amazon is
doing really nice and that is button labeling. I think the screen
before you review your info shouldn't have a button called submit, send
or something like this. I would personally feel much more comfortable
with a labeling like "review your infos" or something like this cause
then the user isn't afraid of sending something already or getting
irritated in the buying/reservation process. On the review page you
could label the button "buy", "reserve", "finish" or whatever. I love
it at amazon that you always know what is happening next and you know
where you are and why.
If you don't agree on that i would write a lil sentence next to the
button explaining that you are not buying it already you get the
pleasure of reviewing your infos again and the possibility for
corrections.

just some quick thoughts

bye

meikel

On Nov 12, 2003, at 9:05 AM, tim[othy] martens wrote:

> Hi,
>
> I'm building a simple one page (three fieldset: trip info, personal
> info, payment info) online reservation form and need to create a
> functional spec of the task flow. My question is about the consensus
> concerning this or similar patterns. I'm wondering specifically, if
> users generally desire or require a "please review your information"
> before submitting your final order page or if that's just an extra
> (unnecessary) step considering they're "reviewing" the information on
> the form page as they're filling it our /and /that the form will have
> built in error checking which will return a facsimile of the page with
> incorrect field(s) highlighted.
>
> Thanks,
>
> -t
>
> _______________________________________________
> Interaction Design Discussion List
> discuss at interactiondesigners.com
> --
> to change your options (unsubscribe or set digest):
> http://discuss.interactiondesigners.com
> --
> Questions: lists at interactiondesigners.com
> --
> Announcement Online List (discussion list members get announcements
> already)
> http://interactiondesigners.com/announceList/
> --
> http://interactiondesigners.com/
>

12 Nov 2003 - 3:23pm
Josh Seiden
2003

Earlier this year, I took part in a review of a
one-screen hotel-room reservation system. (My review
was one of ten reviews of this site, so there is a good
deal of data here.)

The product we reviewed: http://tinyurl.com/6z79
The study results: (Results here:
http://www.dialogdesign.dk/cue.html#CUE4)

The reservation system, which is built with Flash,
presents users with a 3 column display: Date picker,
room picker, personal/payment info.

There was pretty good evidence collected for splitting
the one-screen presentation into two (or maybe 1.5) --
a first screen to allow specification of the
reservation, and a second screen (perhaps a pane that
slides open) to allow entry of personal/payment
information. The user population (consumers, and thus
unfamiliar, low volume users) was not well supported by
the dense, 3 column approach. (In terms of patterns,
the posture was wrong. The app was too sovereign, not
transient enough.)

There was no evidence that users wanted a confirmation
screen. Perhaps this is because they were simply
reserving a room, rather than making a purchase.
Perhaps it was because the confirmation email was
sufficient. Not sure.

Note that we surmised that a professional user who
enters a high volume of transactions would have no
problem with a three-panel approach. It is likely too
that this user would be unhappy with the email
confirmation strategy ;-)

JS

> -----Original Message-----
> From:
>
discuss-interactiondesigners.com-bounces at lists.interact
iondesi
> gners.com
>
[mailto:discuss-interactiondesigners.com-bounces at lists.
interac
> tiondesigners.com] On Behalf Of tim[othy] martens
> Sent: Wednesday, November 12, 2003 3:06 AM
> To:
discuss-interactiondesigners.com at lists.interactiondesig
ners.com
> Subject: [ID Discuss] task flow pattern question
>
>
> Hi,
>
> I'm building a simple one page (three fieldset: trip
info, personal
> info, payment info) online reservation form and need
to create a
> functional spec of the task flow. My question is
about the consensus
> concerning this or similar patterns. I'm wondering
specifically, if
> users generally desire or require a "please review
your information"
> before submitting your final order page or if that's
just an extra
> (unnecessary) step considering they're "reviewing"
the information on
> the form page as they're filling it our /and /that
the form
> will have
> built in error checking which will return a facsimile
of the
> page with
> incorrect field(s) highlighted.

12 Nov 2003 - 3:32pm
Dave Malouf
2005

Josh, this is just iHotlier, right?
Great system w/ a ton of research behind it supporting the product and the
process.

Yes, w/ a hotel system like this, this works quite nice. I also think that
b/c it is a reservation and not a final payment, users know they can cop out
later.

If you look at systems like expedia where your card is being charged right
away (or priceline), etc. you would find that users would be more reluctant
to make that final click w/o a further chance to review.

Another reason that review may not be necessary in your 3 panel approach is
that well, I had a clear display of all the vital information right there
when I submitted which is not the case in many cart based systems.

-- dave

-----Original Message-----
From:
discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
[mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesigners.
com] On Behalf Of Joshua Seiden
Sent: Wednesday, November 12, 2003 3:23 PM
To: 'tim[othy] martens';
discuss-interactiondesigners.com at lists.interactiondesigners.com
Subject: RE: [ID Discuss] task flow pattern question

Earlier this year, I took part in a review of a one-screen hotel-room
reservation system. (My review was one of ten reviews of this site, so there
is a good deal of data here.)

The product we reviewed: http://tinyurl.com/6z79 The study results: (Results
here:
http://www.dialogdesign.dk/cue.html#CUE4)

The reservation system, which is built with Flash, presents users with a 3
column display: Date picker, room picker, personal/payment info.

There was pretty good evidence collected for splitting the one-screen
presentation into two (or maybe 1.5) -- a first screen to allow
specification of the reservation, and a second screen (perhaps a pane that
slides open) to allow entry of personal/payment information. The user
population (consumers, and thus unfamiliar, low volume users) was not well
supported by the dense, 3 column approach. (In terms of patterns, the
posture was wrong. The app was too sovereign, not transient enough.)

There was no evidence that users wanted a confirmation screen. Perhaps this
is because they were simply reserving a room, rather than making a purchase.
Perhaps it was because the confirmation email was sufficient. Not sure.

Note that we surmised that a professional user who enters a high volume of
transactions would have no problem with a three-panel approach. It is likely
too that this user would be unhappy with the email confirmation strategy ;-)

JS

> -----Original Message-----
> From:
>
discuss-interactiondesigners.com-bounces at lists.interact
iondesi
> gners.com
>
[mailto:discuss-interactiondesigners.com-bounces at lists.
interac
> tiondesigners.com] On Behalf Of tim[othy] martens
> Sent: Wednesday, November 12, 2003 3:06 AM
> To:
discuss-interactiondesigners.com at lists.interactiondesig
ners.com
> Subject: [ID Discuss] task flow pattern question
>
>
> Hi,
>
> I'm building a simple one page (three fieldset: trip
info, personal
> info, payment info) online reservation form and need
to create a
> functional spec of the task flow. My question is
about the consensus
> concerning this or similar patterns. I'm wondering
specifically, if
> users generally desire or require a "please review
your information"
> before submitting your final order page or if that's
just an extra
> (unnecessary) step considering they're "reviewing"
the information on
> the form page as they're filling it our /and /that
the form
> will have
> built in error checking which will return a facsimile
of the
> page with
> incorrect field(s) highlighted.

_______________________________________________
Interaction Design Discussion List
discuss at interactiondesigners.com
--
to change your options (unsubscribe or set digest):
http://discuss.interactiondesigners.com
--
Questions: lists at interactiondesigners.com
--
Announcement Online List (discussion list members get announcements already)
http://interactiondesigners.com/announceList/
--
http://interactiondesigners.com/

12 Nov 2003 - 3:53pm
Alex Bainbridge
2003

Hi all,

Dave wrote...

>Great system w/ a ton of research behind it supporting the product and the
>process.

Really?

I conducted some extensive usability testing on the iHotelier 1 screen
interface 8 months ago. Frankly it may look nice, may give designers good
feelings as it uses Flash and is different to other hotel reservation
websites, but users can't use it to make bookings (in comparison to other
hotel reservation websites).

On one of the major, common, tasks, 7 out of 12 computer literate, regular
web users, regular online travel bookers - got completely confused and
couldn't make a booking.

Results of the testing, including tasks used in the usability testing, are
availble from my site (although you have to pay for some of it) - 1 research
paper is free - but that didn't cover iHotlier.

Importantly, there is a large difference between the 1 screen interface for
a single hotel (as per the research previously mentioned) and the
multi-hotel iHotelier process (which is also 1 screen). The user's purchase
decision has already been made on the single hotel 1 screen interface prior
to the user getting to that screen. Its the multi-hotel 1 screen interface
that I tested.

See www.travelucd.com for details.

regards

alex

--
Alex Bainbridge
Senior Consultant

alex.bainbridge at travelucd.com
http://www.travelucd.com/

Travel UCD Limited : consultants in travel & hospitality website design

Switchboard : +44 (0)845 130 3917 Monday to Friday : 8am - 7pm
Saturday : 9am - 3pm

The information in this email is confidential. The contents may not be
disclosed or used by anyone other than the addressee. If you are not the
intended recipient, please notify us immediately at the above address. We
cannot accept any responsibility for the accuracy or completeness of this
message as it has been transmitted over a public network. Travel UCD Limited
has installed proprietary virus checking software on its system to check
that emails and attachments sent by it do not contain known viruses. However
Travel UCD Limited can give no warranty that this email is free from
infection by viruses or anything else that has contaminating or destructive
properties. Accordingly you should implement your own virus checking
procedures before opening this email and any attachments.

-----Original Message-----
From:
discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
[mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesign
ers.com]On Behalf Of David Heller
Sent: 12 November 2003 20:33
To: discuss at interactiondesigners.com
Subject: RE: [ID Discuss] task flow pattern question

Josh, this is just iHotlier, right?
Great system w/ a ton of research behind it supporting the product and the
process.

Yes, w/ a hotel system like this, this works quite nice. I also think that
b/c it is a reservation and not a final payment, users know they can cop out
later.

If you look at systems like expedia where your card is being charged right
away (or priceline), etc. you would find that users would be more reluctant
to make that final click w/o a further chance to review.

Another reason that review may not be necessary in your 3 panel approach is
that well, I had a clear display of all the vital information right there
when I submitted which is not the case in many cart based systems.

-- dave

-----Original Message-----
From:
discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
[mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesigners.
com] On Behalf Of Joshua Seiden
Sent: Wednesday, November 12, 2003 3:23 PM
To: 'tim[othy] martens';
discuss-interactiondesigners.com at lists.interactiondesigners.com
Subject: RE: [ID Discuss] task flow pattern question

Earlier this year, I took part in a review of a one-screen hotel-room
reservation system. (My review was one of ten reviews of this site, so there
is a good deal of data here.)

The product we reviewed: http://tinyurl.com/6z79 The study results: (Results
here:
http://www.dialogdesign.dk/cue.html#CUE4)

The reservation system, which is built with Flash, presents users with a 3
column display: Date picker, room picker, personal/payment info.

There was pretty good evidence collected for splitting the one-screen
presentation into two (or maybe 1.5) -- a first screen to allow
specification of the reservation, and a second screen (perhaps a pane that
slides open) to allow entry of personal/payment information. The user
population (consumers, and thus unfamiliar, low volume users) was not well
supported by the dense, 3 column approach. (In terms of patterns, the
posture was wrong. The app was too sovereign, not transient enough.)

There was no evidence that users wanted a confirmation screen. Perhaps this
is because they were simply reserving a room, rather than making a purchase.
Perhaps it was because the confirmation email was sufficient. Not sure.

Note that we surmised that a professional user who enters a high volume of
transactions would have no problem with a three-panel approach. It is likely
too that this user would be unhappy with the email confirmation strategy ;-)

JS

> -----Original Message-----
> From:
>
discuss-interactiondesigners.com-bounces at lists.interact
iondesi
> gners.com
>
[mailto:discuss-interactiondesigners.com-bounces at lists.
interac
> tiondesigners.com] On Behalf Of tim[othy] martens
> Sent: Wednesday, November 12, 2003 3:06 AM
> To:
discuss-interactiondesigners.com at lists.interactiondesig
ners.com
> Subject: [ID Discuss] task flow pattern question
>
>
> Hi,
>
> I'm building a simple one page (three fieldset: trip
info, personal
> info, payment info) online reservation form and need
to create a
> functional spec of the task flow. My question is
about the consensus
> concerning this or similar patterns. I'm wondering
specifically, if
> users generally desire or require a "please review
your information"
> before submitting your final order page or if that's
just an extra
> (unnecessary) step considering they're "reviewing"
the information on
> the form page as they're filling it our /and /that
the form
> will have
> built in error checking which will return a facsimile
of the
> page with
> incorrect field(s) highlighted.

_______________________________________________
Interaction Design Discussion List
discuss at interactiondesigners.com
--
to change your options (unsubscribe or set digest):
http://discuss.interactiondesigners.com
--
Questions: lists at interactiondesigners.com
--
Announcement Online List (discussion list members get announcements already)
http://interactiondesigners.com/announceList/
--
http://interactiondesigners.com/

_______________________________________________
Interaction Design Discussion List
discuss at interactiondesigners.com
--
to change your options (unsubscribe or set digest):
http://discuss.interactiondesigners.com
--
Questions: lists at interactiondesigners.com
--
Announcement Online List (discussion list members get announcements already)
http://interactiondesigners.com/announceList/
--
http://interactiondesigners.com/

12 Nov 2003 - 7:02pm
tim[othy] martens
2003

Thanks to everyone for all the great feedback so far. Some very
interesting "takes." I perhaps should have better clarified the system
initially, but it's still in the conceptual phase. I'll do my best to
respond to everyone's excellent comments. Firstly, to further clarify
the functionality.

The task flow as I currently envision it:

+ customer arrives at "bookings" (labeling is still not locked down)
page from a homepage entry point, global navigation, or any number of
other hyper links
+ customer scans short intro text (above form) communicating that
advanced web bookings guarantee a spot on the tour, provide cost
savings, and that card is not charged until later.
PERHAPS A BETTER LOCATION FOR THIS BLURB IS JUST ABOVE the "submit"
button OR EVEN IN BOTH PLACES?
+ customer chooses desired date (possibly via calender type UI or
"smart" pull-downs***, number in party, and (if known) accomodations
where staying [fieldset 1]
+ customer fills in minimal contact info (name, address, email, phone)
[fieldset 2]
+ customer fill in payment info (CC type, #, expiration) [fieldset 3]
+ customer clicks "submit" (labeling is still not locked down) button
+ error checking occurs
+ IF ERRORs, return facsimile form with correct data unchanged and
incorrect/missing data clearly highlighted. Plain english "error"
message at top of page/form as well***?
+ IF NO ERRORs, return printer friendly summary of data and other
relevant data (cancellation policies, "contact on arrival", when CC charged)
+ customer receives same/similar info in an email as a back-up and/or
in case they failed to print

***feedback on these options is MUCH welcomed

assumptions

+ customer understands they are not submitting a "payment," but rather
making a reservation/booking
+ customer understands that they can change/cancel their booking up to
24 hours in advance (without penalty) by calling 24/7 toll free #
+ customer understands that their data and privacy are is secure

David:

Would you say the need for confirmation/step thru process is as
necessary with a reservations model as it is with a payment model? The
reason I had thought of the three fieldset form is because the overall
form will be quite compact. We won't be requiring as much personal info
as your average payment model. Also, due to the business model (only one
product -- a "tour" and low repeat business -- we're on Maui, people
come once a year at most) )the project's budget and time line, we
thought a fully form based reservation was more appropriate than a
shopping cart.

Bruce:

You said "I'd posit that the review page acts as the opportunity not for
the user so much to check their work, but to verify that the software is
actually processing the right information or is at least working as
expected."
This is an excellent point and in and of itself probably enough to
validate implementing the "review page" in question! I like the
restaurant analogy.

Peter:

In regards to the amazon 1-click model, I'd agree with David. Since it's
pre configured, there is higher customer confidence. A strong brand like
Amazon doesn't hurt either. That said, I still never use it :-)

Meikel:

I agree, amazon has well researched and clear button labels. We intend
to do the same. Considering this is a booking rather than a payment,
would you still opt for the intermediary "review your info" screen?

Joshua:

The model i'm err, modeling seems quite a bit simpler that iHotelier
which has much higher data density. From a user perspective, I find that
the iHotelier flash interface a bit daunting/dense. From an HCI
perspective, it breaks a number of UI/Usability principles (form fields
look like table cells and have same background color as page, form
labels are INSIDE the form fields, etc.) and in my opinion could have
been done without flash in a more clear manner. No offense to the visual
designer.

Alex:

Just downloaded your "Hotel Data Entry" report and look forward to
reading and applying the results to this simpler model if appropriate.
Cheers.

12 Nov 2003 - 7:06pm
Dave Malouf
2005

Tim asked of David:

Would you say the need for confirmation/step thru process is as necessary
with a reservations model as it is with a payment model? The reason I had
thought of the three fieldset form is because the overall form will be quite
compact. We won't be requiring as much personal info as your average payment
model. Also, due to the business model (only one product -- a "tour" and low
repeat business -- we're on Maui, people come once a year at most) )the
project's budget and time line, we thought a fully form based reservation
was more appropriate than a shopping cart.

David Responds:
I think to give you any further details of my thinking will require me to be
in person and seeing the location of the hotel ... Heh heh heh.

Seriously though, the iHotelier model to me is good (despite the usability
testing problems mentioned) b/c it takes at least 2 screens of importance
and contextual relevance to each other and puts them together. I need to
choose my dates often based on availability, not the other way around. This
is especially true in an environment like a resort where vacations are
flexible. Or!! My dates are so important that I want to put them in and then
see a list of available spaces and pricings. These two "screens" to me are
so tied together in a back and forth model that I agree that they should be
together.

The third screen can be, but doesn't have to be tied to the other two. It
does carry information from the first two into itself, but you have to
repeat it regardless just for clarity. If! This screen works as a clearly
defined "sub-app" then it is fine for it to be "on screen" w/ the other two
process flows, but I think though it is good from a user perspective to have
a clear point of process delineation that says ... I made up my mind I'm
ready to proceed.

Does this last screen require a confirmation process as part of its flow? In
the end, ask your users. Put two prototypes in front of them. Offer your
current hotel guests free breakfast if they'll be guinea pigs. ;) Ask me for
a free vacation and I'll be as big a guinea pig as you want. ;) Put an apple
in me and call me poi! ... Seriously though, I can see this working either
way based on the discussions on the list. I would ere towards confirmation
though as I can't believe it would actually hurt too much, though it is a
point of "nah!, I changed my mind." ... And of course they can say that the
very next day and the day after that up to 72 hours b4 their reservation (or
whatever your hotel's policies are).

Anyway, good luck w/ it.

-- dave

12 Nov 2003 - 8:37pm
tim[othy] martens
2003

Goodness me. I think I've been unclear yet again. The reservation system
is for a downhill bicycle tour which takes customers from the top of
Maui's dormant volcano to sea level over 38 miles with no peddling.
Sounds fun eh? It is! So, that said, the reservations model is quite a
bit simpler than those required of hotels in that there are no types of
room combinations, children/adult considerations etc. There is
essentially one product: the trip. You can choose on of two times to go:
sunrise or mid-day. And you are guaranteed a spot if you book in
advance, meet the safety requirements, and weather permitting. Yes,
sometimes it even snows on Maui!

Thoughts in relation to implementation/original thread? Maybe we should
all meet here to discuss further? :-P

t.

12 Nov 2003 - 9:10pm
tim[othy] martens
2003

Alex,

I just finished your "Hotel Data Entry" Report and find it enormously
useful. An excellent piece of research. Highly recommended to list members:

http://www.travelucd.com/research/date_entry_hotel_july2002.php

I'm wondering about ways to innovate on the best practices/patterns
defined by your research. Two possibilities that come to mind, that have
not been tried and may constitute greater functionality(IMO) for my
model are:

1. Integrating the "day of the week" word (e.g., Monday, Tuesday) and
"day of the week" number (e.g., 10, 11, 12) into one pull-down. This
begs the question which format of the following is better: "Monday 10"
or "10 Monday" and what of numeric abbreviations (1st, 2nd, 3rd, 4th)?

2. Since calenders are recommended (6 of 16 data-entry tasks were
carried out with the use of calender pop-ups) why bury them in a pop-up?
Pop-ups have there own issues as well as the those you mention later in
regards to the calender icons and their affordances? Why not embedded
the calender widget directly into the page? Perhaps if it were right
there in front of the user more than 6/16 would use it?

So, my idea is to offer users both methods up-front; an embedded
calender AND a [day (word)/day (number)][\/] [month/year][\/], e.g.,
"Saturday 16th" pull-down just to the left of "November 2003" pull-down.
Position these to options (calender and pull-down) in close proximity to
one and other possibly with a two headed arrrow separating them. And, of
course, changes in one widget would affect the other and vice versa.

This is my initial low-fi mock-up direction for fieldset 1 and based on
further feedback here I'll soon decide which model (review or not to
review booking page) to test for starters.

THOUGHTS?

Again Thanks everyone for what is turning out to be a very informative
discussion.

-t

13 Nov 2003 - 1:05pm
Anirudha Joshi
2003

Some might think that this is a bit off-topic, but here goes. There is a
hotel reservation site on reservations.broadmoor.com made in Flash. I
never used it (since I never stayed in this hotel), but I found the
reservation form to be quite interesting and we once discussed this page
for interaction design in my HCI class.

<For those who don't want to spend time going through the page: You
fill up the form, but as you do, you are not just giving data, but
getting information. You click on a room and see its view and details.
Simultaneously, you also see if the room is available for the dates you
wish to stay - mind you, you haven't told them the dates yet. You also
know how many people can share this room. If you say three people need
to stay, it tells you that you need two rooms if it does. As soon as you
do that, the calendar shows only those dates that the room is available.
You could change the room, and if the configuration is different, it
helps you along...

By the time you have made up your mind about dates, people and rooms,
the form has automatically filled up. All without 'leaving' the page.
You still need to fill the your name, address and cc info, but you are
still on the same page. I have not gone beyond this point, as I never
stayed there. But I think the confirmation too can be had without
'leaving' the page.>

I think form-design is not just an interaction design task, it is also
an information design task. Information is not the thing that people
fill in forms - that's just data. Information is what you give users, so
that they can fill up the forms right.

This brings to focus an important point about the HTML form - it has
terrible interaction capabilities. So unless there are compelling
reasons to use HTML (strict accessibility compliance for example), I
will go the opposite way around of what Nielsen said in 97 - design
intuitive interactive forms in Flash (Java, DHTML, whatever your
prefer), helping users to make decisions while giving them information,
and not just for 'collecting' data.

Two paise...
Anirudha

-----Original Message-----
From:
discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
[mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesign
ers.com] On Behalf Of David Heller
Sent: Wednesday, November 12, 2003 9:14 AM
To: discuss at interactiondesigners.com
Subject: RE: [ID Discuss] task flow pattern question

Chris,
I think that Amazon "succeeds" at this b/c it is something you configure
to
use.
BTW, I never use it b/c I don't trust it. ;)

But the fact that it is ONE way of using the fulfillment system as
opposed
to THE way to use the fulfillment system makes a HUGE difference.

I also think that the other reasons you mention below are also important
at
some level the most important one being brand.

-- dave

-----Original Message-----
From: Peter Bagnall [mailto:pete at surfaceeffect.com]
Sent: Wednesday, November 12, 2003 12:11 PM
To: David Heller
Cc: discuss at interactiondesigners.com
Subject: Re: [ID Discuss] task flow pattern question

No! ;-) (couldn't resist)

What about Amazon though? For one-click they only have a confirmation
screen
after the transaction has occurred. The way they deal with this is allow
you
to undo the transaction within about 90 minutes. gives the same level of
comfort (arguably), but without the extra step.

I suppose that could be considered a confirmation screen, but it's not
an
"are you sure" screen.

Why does this work for Amazon? Is it due to the reputation? Does that
mean
that it wouldn't work for unknown web vendors? I don't know, but I'd be
interested to hear views on it. There are major differences with amazon
of
course. 1-click assumes you've set up your details before, which
probably
means you've shopped with them in the past. For first time shoppers then
it's possible that Dave is entirely correct, but it would be interesting
to
know what the important factor is that determines whether 1-click like
behaviour is acceptable or not.

Just thought I'd stir!

Cheers
--Pete

On Wednesday, Nov 12, 2003, at 13:53 Europe/London, David Heller wrote:

> Yes!
>
> Whenever you have a payment, there needs to be a confirmation screen.

> People
> are incredibly uncomfortable w/ payment over the net and if you are
> dealing w/ everyday people they will even req. this (never clicking
> the first submit
> button) if they do not have a clearly stated step through process
> which includes a confirm screen.
>
> Question? Why do you need the 3 fieldsets on one screen? Seems that
> the trip info I my "shopping cart" and the personal/payment info is
> part of the fulfillment process (if I can assume a lot about your
> app). Connecting these explicitly as you have might also be a sore
> spot for people who will feel overwhelmed with the "shopping" aspect.
>
> -- dave
>
> -----Original Message-----
> From:
> discuss-interactiondesigners.com-bounces at lists.interactiondesigners.co
> m
> [mailto:discuss-interactiondesigners.com-
> bounces at lists.interactiondesigners.
> com] On Behalf Of tim[othy] martens
> Sent: Wednesday, November 12, 2003 3:06 AM
> To: discuss-interactiondesigners.com at lists.interactiondesigners.com
> Subject: [ID Discuss] task flow pattern question
>
> Hi,
>
> I'm building a simple one page (three fieldset: trip info, personal
> info, payment info) online reservation form and need to create a
> functional spec of the task flow. My question is about the consensus
> concerning this or similar patterns. I'm wondering specifically, if
> users generally desire or require a "please review your information"
> before submitting your final order page or if that's just an extra
> (unnecessary) step considering they're "reviewing" the information on
> the form page as they're filling it our /and /that the form will have

> built in error checking which will return a facsimile of the page with

> incorrect
> field(s) highlighted.
>
> Thanks,
>
> -t
>
> _______________________________________________
> Interaction Design Discussion List
> discuss at interactiondesigners.com
> --
> to change your options (unsubscribe or set digest):
> http://discuss.interactiondesigners.com
> --
> Questions: lists at interactiondesigners.com
> --
> Announcement Online List (discussion list members get announcements
> already)
> http://interactiondesigners.com/announceList/
> --
> http://interactiondesigners.com/
>
> _______________________________________________
> Interaction Design Discussion List
> discuss at interactiondesigners.com
> --
> to change your options (unsubscribe or set digest):
> http://discuss.interactiondesigners.com
> --
> Questions: lists at interactiondesigners.com
> --
> Announcement Online List (discussion list members get announcements
> already)
> http://interactiondesigners.com/announceList/
> --
> http://interactiondesigners.com/
>

_______________________________________________
Interaction Design Discussion List
discuss at interactiondesigners.com
--
to change your options (unsubscribe or set digest):
http://discuss.interactiondesigners.com
--
Questions: lists at interactiondesigners.com
--
Announcement Online List (discussion list members get announcements
already)
http://interactiondesigners.com/announceList/
--
http://interactiondesigners.com/

13 Nov 2003 - 8:12am
Josh Seiden
2003

> Prof. Anirudha Joshi wrote:

> Some might think that this is a bit off-topic, but
here goes.
> There is a hotel reservation site on
> reservations.broadmoor.com made in Flash.

This is another implementation of the iHotelier system
that we've been discussing.

I completely agree with your point about the good use
of rich information feedback. Cooper calls this RVMF
(pronounced: RIVV-muff)(rich, visual, modeless
feedback) and is a big proponent of its use.

That said, I think that this application has a ton of
potential that it has not realized, and that one
example in particular is instructive for interaction
designers.

Try this:

1. Open http://reservations.broadmoor.com.
2. Select Dec 2 as the beginning of your stay.
3. Select Dec 10 as the check out.
4. Enjoy the annoying modal error dialog!

Why does this happen? Well, in terms of hotel policy,
the intervening weekend is completely booked, so you
can't stay at the hotel from the 2nd to the 10th.

But the modal error dialog is a result of poor
interaction design. It could have been prevented by a
combination of with better visual feedback, and
improved application logic.

(In fact, that's a pretty good definition of our
typical medium: visual feedback + application logic.)

My take is that the designer conceived of the visual
feedback system from a static page perspective, not an
interactive perspective. Look at the key. It represents
only a few of the important states. The system is
missing feedback for the many important intermediate
states that one finds in an interactive application.
Where is the mouse-over state? Where is the "you can't
check out on that day with the currently selected
check-in date" state?

JS

13 Nov 2003 - 3:54pm
Danny Bluestone
2003

I totaly agree that Interaction Design makes Users lives easier. By using technology (such as Flash and DHTML ) combined with good Information Architecture structures, Interaction Designers can improve the lives of millions of Users across the globe.

Another great example of Interaction Design with Graphic Design and Programming can be seen on the Pet Market Blueprint: http://examples.macromedia.com/petmarket/flashstore.html

Lets not forget that Interaction Design is vital to software, Mobile & 3G, iDTV, Computer Games, e commerce, eLearning, and everything digital.

I would also like to take this opportunity to praise this group, and hope that we will be able to form an official organisation soon, so we can make Business leaders and consumers more aware of the hard work we do, and how we can improve products and processes using Interaction Design.

Cheers
Danny Bluestone
Cyber-Duck Ltd
London
UK

"Prof. Anirudha Joshi" <anirudha at iitb.ac.in> wrote:Some might think that this is a bit off-topic, but here goes. There is a
hotel reservation site on reservations.broadmoor.com made in Flash. I
never used it (since I never stayed in this hotel), but I found the
reservation form to be quite interesting and we once discussed this page
for interaction design in my HCI class.

fill up the form, but as you do, you are not just giving data, but
getting information. You click on a room and see its view and details.
Simultaneously, you also see if the room is available for the dates you
wish to stay - mind you, you haven't told them the dates yet. You also
know how many people can share this room. If you say three people need
to stay, it tells you that you need two rooms if it does. As soon as you
do that, the calendar shows only those dates that the room is available.
You could change the room, and if the configuration is different, it
helps you along...

By the time you have made up your mind about dates, people and rooms,
the form has automatically filled up. All without 'leaving' the page.
You still need to fill the your name, address and cc info, but you are
still on the same page. I have not gone beyond this point, as I never
stayed there. But I think the confirmation too can be had without
'leaving' the page.>

I think form-design is not just an interaction design task, it is also
an information design task. Information is not the thing that people
fill in forms - that's just data. Information is what you give users, so
that they can fill up the forms right.

This brings to focus an important point about the HTML form - it has
terrible interaction capabilities. So unless there are compelling
reasons to use HTML (strict accessibility compliance for example), I
will go the opposite way around of what Nielsen said in 97 - design
intuitive interactive forms in Flash (Java, DHTML, whatever your
prefer), helping users to make decisions while giving them information,
and not just for 'collecting' data.

Two paise...
Anirudha

-----Original Message-----
From:
discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
[mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesign
ers.com] On Behalf Of David Heller
Sent: Wednesday, November 12, 2003 9:14 AM
To: discuss at interactiondesigners.com
Subject: RE: [ID Discuss] task flow pattern question

Chris,
I think that Amazon "succeeds" at this b/c it is something you configure
to
use.
BTW, I never use it b/c I don't trust it. ;)

But the fact that it is ONE way of using the fulfillment system as
opposed
to THE way to use the fulfillment system makes a HUGE difference.

I also think that the other reasons you mention below are also important
at
some level the most important one being brand.

-- dave

-----Original Message-----
From: Peter Bagnall [mailto:pete at surfaceeffect.com]
Sent: Wednesday, November 12, 2003 12:11 PM
To: David Heller
Cc: discuss at interactiondesigners.com
Subject: Re: [ID Discuss] task flow pattern question

No! ;-) (couldn't resist)

What about Amazon though? For one-click they only have a confirmation
screen
after the transaction has occurred. The way they deal with this is allow
you
to undo the transaction within about 90 minutes. gives the same level of
comfort (arguably), but without the extra step.

I suppose that could be considered a confirmation screen, but it's not
an
"are you sure" screen.

Why does this work for Amazon? Is it due to the reputation? Does that
mean
that it wouldn't work for unknown web vendors? I don't know, but I'd be
interested to hear views on it. There are major differences with amazon
of
course. 1-click assumes you've set up your details before, which
probably
means you've shopped with them in the past. For first time shoppers then
it's possible that Dave is entirely correct, but it would be interesting
to
know what the important factor is that determines whether 1-click like
behaviour is acceptable or not.

Just thought I'd stir!

Cheers
--Pete

On Wednesday, Nov 12, 2003, at 13:53 Europe/London, David Heller wrote:

> Yes!
>
> Whenever you have a payment, there needs to be a confirmation screen.

> People
> are incredibly uncomfortable w/ payment over the net and if you are
> dealing w/ everyday people they will even req. this (never clicking
> the first submit
> button) if they do not have a clearly stated step through process
> which includes a confirm screen.
>
> Question? Why do you need the 3 fieldsets on one screen? Seems that
> the trip info I my "shopping cart" and the personal/payment info is
> part of the fulfillment process (if I can assume a lot about your
> app). Connecting these explicitly as you have might also be a sore
> spot for people who will feel overwhelmed with the "shopping" aspect.
>
> -- dave
>
> -----Original Message-----
> From:
> discuss-interactiondesigners.com-bounces at lists.interactiondesigners.co
> m
> [mailto:discuss-interactiondesigners.com-
> bounces at lists.interactiondesigners.
> com] On Behalf Of tim[othy] martens
> Sent: Wednesday, November 12, 2003 3:06 AM
> To: discuss-interactiondesigners.com at lists.interactiondesigners.com
> Subject: [ID Discuss] task flow pattern question
>
> Hi,
>
> I'm building a simple one page (three fieldset: trip info, personal
> info, payment info) online reservation form and need to create a
> functional spec of the task flow. My question is about the consensus
> concerning this or similar patterns. I'm wondering specifically, if
> users generally desire or require a "please review your information"
> before submitting your final order page or if that's just an extra
> (unnecessary) step considering they're "reviewing" the information on
> the form page as they're filling it our /and /that the form will have

> built in error checking which will return a facsimile of the page with

> incorrect
> field(s) highlighted.
>
> Thanks,
>
> -t
>
> _______________________________________________
> Interaction Design Discussion List
> discuss at interactiondesigners.com
> --
> to change your options (unsubscribe or set digest):
> http://discuss.interactiondesigners.com
> --
> Questions: lists at interactiondesigners.com
> --
> Announcement Online List (discussion list members get announcements
> already)
> http://interactiondesigners.com/announceList/
> --
> http://interactiondesigners.com/
>
> _______________________________________________
> Interaction Design Discussion List
> discuss at interactiondesigners.com
> --
> to change your options (unsubscribe or set digest):
> http://discuss.interactiondesigners.com
> --
> Questions: lists at interactiondesigners.com
> --
> Announcement Online List (discussion list members get announcements
> already)
> http://interactiondesigners.com/announceList/
> --
> http://interactiondesigners.com/
>

_______________________________________________
Interaction Design Discussion List
discuss at interactiondesigners.com
--
to change your options (unsubscribe or set digest):
http://discuss.interactiondesigners.com
--
Questions: lists at interactiondesigners.com
--
Announcement Online List (discussion list members get announcements
already)
http://interactiondesigners.com/announceList/
--
http://interactiondesigners.com/

_______________________________________________
Interaction Design Discussion List
discuss at interactiondesigners.com
--
to change your options (unsubscribe or set digest): http://discuss.interactiondesigners.com
--
Questions: lists at interactiondesigners.com
--
Announcement Online List (discussion list members get announcements already)
http://interactiondesigners.com/announceList/
--
http://interactiondesigners.com/

---------------------------------
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.interactiondesigners.com/pipermail/discuss-interactiondesigners.com/attachments/20031113/ed89f563/attachment.html

Syndicate content Get the feed