forced select - NO preselected option

5 Oct 2004 - 5:40pm
10 years ago
20 replies
516 reads
Gunnar Langemark
2004

My client (a large labour union turning professional organization) wants to
give prospect members - applying for membership online - a choice to select
if they want to share some personal and other data with other portal community
members.
My first idea was to have applicants click a set of checkboxes to select which
types of data they would allow others to see.
This was not what the client wanted.
So I suggested that we had sets of two radio-buttons - yes and no - and have
the "no" option preselected (i.e an opt in offer).
This was still not what my client had envisioned.

He would like to force applicants to make a selection - yes or no - but have
none of the two preselected. So he would validate on whether the options had
been selected.

So my question is: What would be the standard/best way of doing so?

It should fit into a flow of 5 guided pages of filled in data (yes there is a
lot of input here!) - so I'm not so keen on "sub-guides" - like asking one
question at a time. I would prefer to get the answers on the same page (the
same page as a few other choices).

Thanx in advance

Gunnar Langemark
gunnar at langemark.com

Comments

6 Oct 2004 - 6:34am
Coryndon Luxmoore
2004

One point of clarification. Does the user have to enter the data the either way regardless of the choice? --Coryndon

-------Original Message-------
> From: gunnar <gunnar at langemark.com>
> Subject: [ID Discuss] forced select - NO preselected option
> Sent: 05 Oct 2004 23:40:53
>
> [Please voluntarily trim replies to include only relevant quoted material.]
>
> My client (a large labour union turning professional organization) wants to
> give   prospect members - applying for membership online - a choice to select
> if they want to share some personal and other data with other portal community
> members.
> My first idea was to have applicants click a set of checkboxes to select which
> types of data they would allow others to see.
> This was not what the client wanted.
> So I suggested that we had sets of two radio-buttons - yes and no - and have
> the "no" option preselected (i.e an opt in offer).
> This was still not what my client had envisioned.
>
> He would like to force applicants to make a selection - yes or no - but have
> none of the two preselected. So he would validate on whether the options had
> been selected.
>
> So my question is: What would be the standard/best way of doing so?
>
> It should fit into a flow of 5 guided pages of filled in data (yes there is a
> lot of input here!) - so I'm not so keen on "sub-guides" - like asking one
> question at a time. I would prefer to get the answers on the same page (the
> same page as a few other choices).
>
>
> Thanx in advance
>
> Gunnar Langemark
> gunnar at langemark.com
> _______________________________________________
> Interaction Design Discussion List
> discuss at ixdg.org
> --
> to change your options (unsubscribe or set digest): http://discuss.ixdg.org/
> --
> Questions: lists at ixdg.org
> --
> Announcement Online List (discussion list members get announcements already)
> http://subscribe-announce.ixdg.org/
> --
> http://ixdg.org/
-------Original Message-------

5 Oct 2004 - 6:38pm
Gunnar Langemark
2004

> One point of clarification. Does the user have to enter the data the
> either way regardless of the choice? --Coryndon

The user is presented with the options and does only have to select on a
yes/no basis. But he HAS TO select. And there should not be a preselected
option. And there should not be a flow (meaning that all questions should be
presented on the same page).

I hope this answers your question.

Gunnar Langemark
gunnar at langemark.com

6 Oct 2004 - 6:51am
Peter Boersma
2003

Gunnar explained:
> The user is presented with the options and does only have to select on a
> yes/no basis. But he HAS TO select. And there should not be a preselected
> option.

No matter what your client wants or doesn't want, this is exactly what
checkboxes and radio buttons are made for. In my opinion this is not a
matter of finding another solution, but convincing the client that the
designs they disagree with are actually established solutions for this
problem.

Peter
--
Peter Boersma - Senior Information Architect - EzGov
Rijnsburgstraat 11 - 1059AT Amsterdam - The Netherlands
t: +31(0)20 7133881 - f: +31(0)20 7133799 - m: +31(0)6 15072747
mailto:peter.boersma at ezgov.com - http://www.ezgov.com

6 Oct 2004 - 7:04am
Michael Bartlett
2004

Agreed, even Microsoft in XP SP2 have adopted this approach when presenting
the user with "important questions" - especially those that are security
related.

For example the ActiveX control (or maybe it's a security cert prompt) that
asks you to run or not run the control is defaulted to yes prior to XP2; so
if you just click the default or press enter then you install a control
which is potentially hazardous. It's now a radio that is unselected by
default.

I think a lot of this stems from the fact that people/users (myself
included) do not always read properly.

-----Original Message-----
From:
discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
[mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesigners.
com] On Behalf Of Peter Boersma
Sent: 06 October 2004 13:51
To: gunnar; cluxmoore; discuss at interactiondesigners.com
Subject: RE: [ID Discuss] forced select - NO preselected option

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

Gunnar explained:
> The user is presented with the options and does only have to select on
> a yes/no basis. But he HAS TO select. And there should not be a
> preselected option.

No matter what your client wants or doesn't want, this is exactly what
checkboxes and radio buttons are made for. In my opinion this is not a
matter of finding another solution, but convincing the client that the
designs they disagree with are actually established solutions for this
problem.

Peter
--
Peter Boersma - Senior Information Architect - EzGov Rijnsburgstraat 11 -
1059AT Amsterdam - The Netherlands
t: +31(0)20 7133881 - f: +31(0)20 7133799 - m: +31(0)6 15072747
mailto:peter.boersma at ezgov.com - http://www.ezgov.com

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

6 Oct 2004 - 8:31am
Coryndon Luxmoore
2004

Gunnar,

> The user is presented with the options and does only have to select on a
> yes/no basis. But he HAS TO select. And there should not be a preselected
> option.

The two issues as a can best understand it is:
- The client does not want the user to miss the setting and accept the default
- I assume that the driver behind the clients conern is that people will not see the benefits of sharing
- You do not want to assume that the information is shared

Since all of the users personal information has to be entered and validated it seems like you could have a second page after the user has entered all of the information that asks if they want to share the information. This would make the choice explicit and you could then potentially convince your client to accept a radio button solution with the default set to no. It would also give you some room to "market" the benefits of sharing the information.

You could use a dropdown to add the third option. have the first option be somthing like "Choose Privacy Settings" and list the share/not share below. You could do this with the radio buttons but coming up for a good title for the non-selected option would be very hard.

Or you can break convention and have no radio buttons defaulted. While this is not correct convention it is rife on the web (I personally hate it) I have not yet seen users in tests have a problem with it or even notice the devient behavior. The users I have observed generally seem to have a pretty poorly formed mental model of defferences between checkboxes and radio buttons.

Regardless of the dropdown or check boxes it seems like you could mitigate your clients concerns about users missing it through a more prominate visual treatment and adding marketing/benefit messages around the sharing of information.

Peter said
> No matter what your client wants or doesn't want, this is exactly what
> checkboxes and radio buttons are made for. In my opinion this is not a
> matter of finding another solution, but convincing the client that the
> designs they disagree with are actually established solutions for this
> problem.

This seems a little harsh. The client has imposed more requirments on the design and that means that Gunnar need to develop a different solution to address the problem. Jamming a complient solution down the clients throat will most likely ensure a non-comlient solution since the client will always win either by forcing the solution to meet those requirments or by finding someone else to build it.

It is better to understand the drivers of the requirement and develop an new solution that meets those drivers and best practices.

--Coryndon

6 Oct 2004 - 10:02am
Dan Zlotnikov
2004

<snip>
> Or you can break convention and have no radio buttons defaulted. While this is not correct convention it is rife on the web (I personally hate it) I have not yet seen users in tests have a problem with it or even notice the devient behavior. The users I have observed generally seem to have a pretty poorly formed mental model of defferences between checkboxes and radio buttons.
<snip>

To me, the question would then be: how does the system handle
exceptions, like people not clicking on any of the radio buttons or
selecting none or more than one of the check boxes? A page that
refreshes with only the incorrectly answered questions seems like a
Bad Idea (tm), simply bouncing the user to the first error on the page
isn't all that good, either.

Dan
--
WatCHI
http://www.acm.org/chapters/watchi

6 Oct 2004 - 10:29am
Andrei Herasimchuk
2004

On Oct 6, 2004, at 5:51 AM, Peter Boersma wrote:

> No matter what your client wants or doesn't want, this is exactly what
> checkboxes and radio buttons are made for. In my opinion this is not a
> matter of finding another solution, but convincing the client that the
> designs they disagree with are actually established solutions for this
> problem.

Well said.

Even further, more designers need to push back on these sorts of things
from clients or their companies.

The best way to get into the sort of discussion from that point of view
is to tell the client what they have is a marketing or business problem
that should not be solved through misuse of interface widgets. Too much
of the web out there has allowed this to happen (and I know I've done
my fair share of it being lazy and not wanting to argue on certain days
with product managers), so more and more people misuse common widgets,
perpetuating problems and creating their own usability hurdles.

What you want is a radio button, with the more common or less dangerous
option pre-selected. That's it. Simple, clean, clear, and precise.

The problem the client is trying to solve should be solved in the
informative text on the form, or in keeping the app clear and precise
in other ways. trying to guide a user to do what you want through
misuse of controls is just not a good idea. It will often come back and
cause problems later on.

FWIW, if I see another menu with one of the choices labeled "Please
make a selection" I'm going to cry. The bastardization of simple
interface controls is killing the most common interface tasks in terms
of simple, straight-forward usability.

Andrei

6 Oct 2004 - 10:44am
Petteri Hiisilä
2004

>> No matter what your client wants or doesn't want, this is exactly what
>> checkboxes and radio buttons are made for. In my opinion this is not a
>> matter of finding another solution, but convincing the client that the
>> designs they disagree with are actually established solutions for this
>> problem.
>
> Well said.

Indeed.

> Even further, more designers need to push back on these sorts of things
> from clients or their companies.

Well said.

> What you want is a radio button, with the more common or less dangerous
> option pre-selected. That's it. Simple, clean, clear, and precise.

With radio buttons, yes.

> FWIW, if I see another menu with one of the choices labeled "Please make
> a selection" I'm going to cry. The bastardization of simple interface
> controls is killing the most common interface tasks in terms of simple,
> straight-forward usability.

You're right.

1) Checkbox = check none OR check one OR check more than one
2) Radio button = select just one
3) ??? = select none OR one

We need a new idiom for #3. The client request is valid, it think. It's
actually very human to require an answer, but just one answer, and no
default answer. Isn't it?

Examples:

Do you want more salt?
Are you okay?
How are you?
Do you live here?
What did you say: is your name pe-theeri or pet-ehri?

AFAIK, there's no interface widget for #3. Using a radio button is
misuse, if we hold on to ancient radio button metaphor. You know those
analog radios, where two buttons can't be down at the same time, but one
always is.

From the pure interaction / cognitive friction point of view, I don't
see what's wrong with using #2 to handle #3. Assuming that #3 isn't
going to be supported by major browsers in the near future. What's the
alternative? Is it more usable than "misusing" a radio button?

- Petteri

--
Petteri Hiisilä
Palveluarkkitehti / Interaction Designer /
Alma Media Interactive Oy / NWS /
+358505050123 / petteri.hiisila at almamedia.fi

"The unbroken spirit
Obscured and disquiet
Finds clearness this trial demands"
- Dream Theater

6 Oct 2004 - 11:04am
Jim McCusker
2004

I don't think your examples support your supposed needs. See below.

Petteri Hiisilä wrote:

> We need a new idiom for #3. The client request is valid, it think.
> It's actually very human to require an answer, but just one answer,
> and no default answer. Isn't it?
>
> Examples:
>
> Do you want more salt?

Checkbox

> Are you okay?

Checkbox.

> How are you?

Multiple checkboxes, allowing users to say that they are angry and confused.

> Do you live here?

Checkbox.

> What did you say: is your name pe-theeri or pet-ehri?

Having a default is reasonable here, since neither is dangerous.

Jim

6 Oct 2004 - 11:12am
Andrei Herasimchuk
2004

On Oct 6, 2004, at 9:44 AM, Petteri Hiisilä wrote:

> 1) Checkbox = check none OR check one OR check more than one
> 2) Radio button = select just one
> 3) ??? = select none OR one
>
> We need a new idiom for #3. The client request is valid, it think.
> It's actually very human to require an answer, but just one answer,
> and no default answer. Isn't it?

People seem to want to leave the choices empty so as not to "guide" the
user. The real question that always comes up in these debates is
whether there should be a default choice. I'm not sure what the problem
is with having a default. If the choices are explicit, then just how
much will a user be swayed by a default choice? Has anyone ever done a
study around this for data?

I guess the issue might come down to those users who won't read or take
the time to understand what is being asked of them. Just see my latest
post on my blog for my conflicted feelings in that regard.
http://www.designbyfire.com/000163.html

Andrei

6 Oct 2004 - 11:41am
Coryndon Luxmoore
2004

> FWIW, if I see another menu with one of the choices labeled "Please
> make a selection" I'm going to cry. The bastardization of simple
> interface controls is killing the most common interface tasks in terms
> of simple, straight-forward usability.

If you saw the application that I am working on right now we might have to send you out for a little therapy. :)

We have a very novice user base for the application and we tested blank dropdowns with no "Choose X..." option and designs with the "Choose X.." option.

Users stronly preferred the "Choose X" design. Blank boxes caused problems with users knowing the contents even though they had a label directly above the box. Additionally they had greater confidence about what to do since the language in the box is action oriented not passive like a label. Finally, if they wanted to get rid of the selection in the box they had greater confidence selecting the "Choose X' vs a blank option.

So you have mentioned a number of times about you dislike for this solution since it breaks "convention" why does it cause problems to do this in your testing experience? And why do you think the convention should not be changed?

--CML

6 Oct 2004 - 11:29am
Petteri Hiisilä
2004

>> Do you want more salt?
>
> Checkbox

Okay. Here's my answer.

[x] yes
[x] no

The checkbox widget should allow it, since

> 1) Checkbox = check none OR check one OR check more than one

Isn't this right?

Rejecting this answer would be a misuse of the checkbox.

>> What did you say: is your name pe-theeri or pet-ehri?
>
> Having a default is reasonable here, since neither is dangerous.

Your right, it isn't dangerous in the sense as playing with a loaded gun
is dangerous. Not a big deal. It's just a name, right?-)

But having a default in this case isn't smart, as it wasn't in the
previous examples either.

You know, I might be someone important and now you have to spell my name
right. You want to know how to say it. I'm not Zon Carry, but it's still
not polite to say my name wrong.

Let's assume that I use a web radio button to tell you the answer. Let's
make the first option the default. That's a fair default, isn't it? I
might have selected it myself, but _maybe_ I just pressed OK, because I
don't care. You should.

(o) Pe-Theeri
( ) Pet-heri

Now, which one's my name?

:)

Are you sure you want to use a default with that?

- Petteri

--
Petteri Hiisilä
Palveluarkkitehti / Interaction Designer /
Alma Media Interactive Oy / NWS /
+358505050123 / petteri.hiisila at almamedia.fi

"The unbroken spirit
Obscured and disquiet
Finds clearness this trial demands"
- Dream Theater

6 Oct 2004 - 11:47am
Jim McCusker
2004

Petteri Hiisilä wrote:

> Okay. Here's my answer.
>
> [x] yes
> [x] no
>
> The checkbox widget should allow it, since
>
> > 1) Checkbox = check none OR check one OR check more than one
>
> Isn't this right?
>
> Rejecting this answer would be a misuse of the checkbox.

The correct way would be:

[ ] Would you like more salt?

checked is yes, unchecked is no. BTW, there are many checkbox
implementations that have a "null" state, which is neither checked or
unchecked. MS Access is one that jumps to mind.

> (o) Pe-Theeri
> ( ) Pet-heri
>
> Now, which one's my name?
>
> :)
>
> Are you sure you want to use a default with that?

You're probably right. Well, I just thought of another option: single
selection list. Just list out the options, and allow the user to select
the one that they want.

Jim

5 Oct 2004 - 11:46pm
Gunnar Langemark
2004

Thank you for all of your excellent replys.
I will try to make my dilemma a little more clear:

It is not an option to sell the client a well established best practices on
the web, as neither radio buttons nor check boxes fulfill the need.
The client need is determined by business practices and by law (It is a labour
union, they need their members to opt in and share some of the s...load of
information they collect in order to provide their services. They need this
because the community portal system needs it. By law they cannot assume
agreement. The application interface is already overloaded as is, and I even
need a general solution for our standard application web interface, which we
sell to other clients as well.).

In my opinion the design should reflect the business practice, and not the
other way round. If I could change the law or my clients well established
business practices by telling them that on the web we always do it this or
that way, then my job would be very easy. But that is not an option.

> Peter said
> > No matter what your client wants or doesn't want, this is
> exactly what > checkboxes and radio buttons are made for. In my
> opinion this is not a > matter of finding another solution, but
> convincing the client that the > designs they disagree with are
> actually established solutions for this > problem.
>
> This seems a little harsh. The client has imposed more requirments
> on the design and that means that Gunnar need to develop a different
> solution to address the problem. Jamming a complient solution down
> the clients throat will most likely ensure a non-comlient solution
> since the client will always win either by forcing the solution to
> meet those requirments or by finding someone else to build it.

Quite.

Gunnar Langemark
gunnar at langemark.com

6 Oct 2004 - 11:55am
Elizabeth Buie
2004

Jim McCusker writes:

>The correct way would be:
>
>[ ] Would you like more salt?

Not quite: The wording of this as a question requires a yes or no answer.
The correct way would be:

[ ] I would like more salt.

Generally speaking, a single check box is appropriate for a yes/no or
true/false condition or a condition in which the choices are logical
opposites -- "A vs. not-A". A two-radio-button group is appropriate for a
condition in which the choices are mutually exclusive but not logical
opposites -- "A vs. B", where the existence of B cannot be inferred simply
from the lack of A.

Elizabeth
--
Elizabeth Buie
Computer Sciences Corporation
Rockville, Maryland, USA
+1.301.921.3326

----------------------------------------------------------------------------------------
This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to
bind CSC to any order or other contract unless pursuant to explicit
written agreement or government initiative expressly permitting the use of
e-mail for such purpose.
----------------------------------------------------------------------------------------

6 Oct 2004 - 3:48pm
david gee
2004

gunnar wrote:
> [Please voluntarily trim replies to include only relevant quoted material.]
>
> Thank you for all of your excellent replys.
> I will try to make my dilemma a little more clear:
>
> It is not an option to sell the client a well established best practices on
> the web, as neither radio buttons nor check boxes fulfill the need.
> The client need is determined by business practices and by law (It is a labour
> union, they need their members to opt in and share some of the s...load of
> information they collect in order to provide their services. They need this
> because the community portal system needs it. By law they cannot assume
> agreement. The application interface is already overloaded as is, and I even
> need a general solution for our standard application web interface, which we
> sell to other clients as well.).
>

It seems to me what you're trying to accomplish is most similar to an
End User License Agreement, something we all see fairly often.
Personally, I think the best option in this case would be to state the
terms and conssequences of each option, followed by two discrete
buttons, clearly labelled to the effect of "Yes, I want to share", and
"No, I Don't". This should be a terminating action on the page, possibly
even a page of it's own.

--
david gee david at mode3.com http://www.mode3.com/david

6 Oct 2004 - 4:03pm
Listera
2004

> By law they cannot assume agreement.

I missed the beginning of this thread, but why not "serialize" the process?

You could have a div or iframe showing a single question and, instead of
radio buttons/checkboxes, have two (form submit) buttons that record the
selection and automatically bring up the next question. This way, the only
way to advance to the next question is an active click. You should also have
an accumulating list of answered questions with an Edit button, perhaps on a
lower frame. Notice there's no "page" refresh here, just partial inline
updates for questions/answers.

An alternative design, is to list all questions on a single page, but use
obvious visual highlighting of the current question (border, bkg color, bold
type, etc) which, as in the example above, advances to the next question
automatically.

Ziya
Nullius in Verba

6 Oct 2004 - 12:45pm
Gunnar Langemark
2004

> > By law they cannot assume agreement.
>
> I missed the beginning of this thread, but why not "serialize" the process?
> You could have a div or iframe showing a single question and,
> instead of radio buttons/checkboxes, have two (form submit) buttons
> that record the selection and automatically bring up the next
> question. This way, the only way to advance to the next question is
> an active click. You should also have an accumulating list of
> answered questions with an Edit button, perhaps on a lower frame.
> Notice there's no "page" refresh here, just partial inline updates
> for questions/answers.

This idea struck me - but that would mean that I would have a "nested" guide.
Mind you that we are inside a "serialized" guide already.
I'm tempted to experiment with it.
Especially after you mention a design without the page refresh (could be done
with script and/or css i think).
There's one disadvantage though. This system is designed inside the Microsoft
Business Solutions product Axapta - which is an ERP system with a build in
"HTML generator". This generator does not exactly live up to all W3C
standards, and if I go beyond the build in capabilities I will lose the
ability to track, document and update the solution automatically from within
the Axapta development framework. That would seriously p... off my developers
and consultants I think.
Oh what a mess I've gotten myself into....
:-)

Gunnar Langemark
gunnar at langemark.com

7 Oct 2004 - 1:06am
Listera
2004

gunnar:

> Especially after you mention a design without the page refresh (could be done
> with script and/or css i think).

Certainly. If anybody says otherwise, just show him GMail or Blogger, as
examples of what can be done. This one wouldn't be remotely as complex,
you're just shuffling hidden form/selection values between the server and
frame updates.

> There's one disadvantage though. This system is designed inside the
Microsoft...

Well, then. :-)

Ziya
Nullius in Verba

6 Oct 2004 - 1:28pm
Gunnar Langemark
2004

> > There's one disadvantage though. This system is designed inside the
> Microsoft...
>
> Well, then. :-)

Yup

:-)

Gunnar Langemark
gunnar at langemark.com

Syndicate content Get the feed