«

Can I do something like the following to get a browser to redirect to
a new url every time someone picks a new value in a select box?





function changeUrl() {
var redirect;
redirect = document.getElementById('newUrl').value;
document.location.href = redirect;
}


<select id="newUrl" onchange="changeUrl();">
<option>www.krubner.com</option>
<option>www.publicpen.com</option>
</select>

On 17 Sep 2004 14:56:27 -0700, lawrence <> wrote:

> Can I do something like the following to get a browser to redirect to a
> new url every time someone picks a new value in a select box?

You can, but you shouldn't. It presents usability problems for reasons not
limited to keyboard navigation, mouse wheel scrolling, and the inability
to change a selection once made. Instead, use a button.

<script type="text/javascript">
function goTo() {
var sE = null, url;
if(document.getElementById) {
sE = document.getElementById('urlList');
} else if(document.all) {
sE = document.all['urlList'];
}
if(sE && (url = sE.options[sE.selectedIndex].value)) {
location.href = url;
}
}
</script>


<select id="urlList" size="1">
<option value="">Select a link...</option>
<option value="http://www.google.com/">Google</option>
<option value="http://www.mozilla.org/">Mozilla.org</option>
<option value="http://www.opera.com/">Opera.com</option>
</select>
<input type="button" value="Go!" onclick="goTo();">


Of course, it would be better to implement this as a form which would
submit a value to the server, resulting in a redirect the selected page.

Hope that helps,
Mike

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.

"Michael Winter" <> wrote in message news:<opsehr49j9x13kvk@atlantis>...
> On 17 Sep 2004 14:56:27 -0700, lawrence <> wrote:
>
> > Can I do something like the following to get a browser to redirect to a
> > new url every time someone picks a new value in a select box?
>
> You can, but you shouldn't. It presents usability problems for reasons not
> limited to keyboard navigation, mouse wheel scrolling, and the inability
> to change a selection once made. Instead, use a button.

Can you elaborate on the problems? It seems easier so I am inclined
towards it. It saves the user a step. What sort of problems come up?
Why is it bad?

On 21 Sep 2004 12:16:07 -0700, lawrence <> wrote:

> "Michael Winter" <> wrote in message
> news:<opsehr49j9x13kvk@atlantis>...

[Brief mention of problems with SELECT element navigation menus]

> Can you elaborate on the problems? It seems easier so I am inclined
> towards it.

Easier for whom?

> It saves the user a step.

It saves some users a step. It causes others to take many.

> What sort of problems come up? Why is it bad?

It's bad for disabled users. Before you think, "That doesn't apply to my
site", the issue covers a wide range of people, not just some preconceived
subsection. People with cognative, visual, and motor disabilities can all
be affected.

Users associate behaviour with controls. A user doesn't necessarily expect
selecting a value from a drop-down list to actually perform an action such
as navigation. Usability studies show that this has many effects on users;
none of them positive.

Number 3:
<URL:http://www.useit.com/alertbox/990530.html>

Despite being six years old, every point in the article still holds true.

In addition, a user might not be able to see all of the options. This
might cause them to select a value that appears to be the closest. If they
then discover the actual destination, they'll try to select it, but it
will be too late; the request has already started and scripting is usually
ignored at that point. What's worse is that if they go back, the option
they selected just before changing pages might be selected. As most
drop-down navigation menus use the change event, they'll have to select a
different value before they can select the required one. Of course, most
people won't know that.

Part of that is echoed in this article:
<URL:http://www.useit.com/alertbox/20001112.html>

Similar to the above is the case where the user selects the wrong value.
Without confirmation, the user will suffer the same fate as above, and
there are many reasons why this can occur. I know of three from personal
experience:

1) Holding a mouse in a certain position for a long time can cause
involuntary twitches in my fingers. This might cause to me to select a
value when I'd have no intention to.
2) After using my mouse wheel, it can be left in an unstable state. That
is, there are recessed points that help stop the wheel from spinning. If
the wheel isn't resting in those points it can, and it does, slip. With an
active select menu, this would cause the list to scroll which has at times
been when I'm about to click on a link.
3) I might not be concentrating, resulting in the selection of the item
above or below the desired destination.

In my previous post, I mentioned keyboard navigation. Once the menu has
focus, you can use a variety of methods to scroll to a selection. However,
they all cause events to be fired which would result in a navigation
action. Therefore, auto-selection prevents this method from being used.
Similarly, the mouse wheel can be used to scroll the list, but that too
causes events to be fired.

Finally, the approach is useless for people without JavaScript enabled
without server-side support. Even then, you'll need to use a button.

Out of the above, two suggest that the entire concept is avoided. The
others require the use of the button. If you still want to know how, I'll
tell you, but I'd rather you didn't ask me to.

Mike

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.

"Michael Winter" <> wrote in message news:<opsep8lkuox13kvk@atlantis>...
> Users associate behaviour with controls. A user doesn't necessarily expect
> selecting a value from a drop-down list to actually perform an action such
> as navigation. Usability studies show that this has many effects on users;
> none of them positive.
>
> Number 3:
> <URL:http://www.useit.com/alertbox/990530.html>
>
> Despite being six years old, every point in the article still holds true.
>
> In addition, a user might not be able to see all of the options. This
> might cause them to select a value that appears to be the closest. If they
> then discover the actual destination, they'll try to select it, but it
> will be too late; the request has already started and scripting is usually
> ignored at that point. What's worse is that if they go back, the option
> they selected just before changing pages might be selected. As most
> drop-down navigation menus use the change event, they'll have to select a
> different value before they can select the required one. Of course, most
> people won't know that.
>
> Part of that is echoed in this article:
> <URL:http://www.useit.com/alertbox/20001112.html>

This is a strong argument. I'll present the client with both options
and I'll send your post to them so they'll understand the negative
effects of having the action triggered onChange, and then I'll leave
the final decision to them.

"Michael Winter" <> wrote in message news:<opsep8lkuox13kvk@atlantis>...
> Easier for whom?
>
> > It saves the user a step.
>
> It saves some users a step. It causes others to take many.
>
> > What sort of problems come up? Why is it bad?
>
> It's bad for disabled users. Before you think, "That doesn't apply to my
> site", the issue covers a wide range of people, not just some preconceived
> subsection. People with cognative, visual, and motor disabilities can all
> be affected.
>
> Users associate behaviour with controls. A user doesn't necessarily expect
> selecting a value from a drop-down list to actually perform an action such
> as navigation. Usability studies show that this has many effects on users;
> none of them positive.
>
> Number 3:
> <URL:http://www.useit.com/alertbox/990530.html>
>
> Despite being six years old, every point in the article still holds true.
>
> In addition, a user might not be able to see all of the options. This
> might cause them to select a value that appears to be the closest. If they
> then discover the actual destination, they'll try to select it, but it
> will be too late; the request has already started and scripting is usually
> ignored at that point. What's worse is that if they go back, the option
> they selected just before changing pages might be selected. As most
> drop-down navigation menus use the change event, they'll have to select a
> different value before they can select the required one. Of course, most
> people won't know that.

The very good, well respected weblog Crooked Timber uses onChange() as
their firing point for moves after you've picked a category in a
select box:

http://www.crookedtimber.org/archive..._politics.html

Scroll down and you'll see the selectt box for categories on the left.
I'm not sure if this is the default for MoveableType, which is also a
much respected bit of software.

Usage is whatever major sites do. I imagine their designer thought, as
I did, that not having a "Go" button would save the user a step.
Nevertheless, for now, I'm doing it the way you suggested (unless the
client complains), as you can see on the left side of this page:

http://www.alexmarshall.org/index.php?pageId=2494

On 28 Sep 2004 14:58:29 -0700, lawrence <> wrote:

[snip]

> Scroll down and you'll see the selectt box for categories on the left.
> I'm not sure if this is the default for MoveableType, which is also a
> much respected bit of software.

IE is a respected browser by the uninformed. It doesn't mean that
everything it does is right.

> Usage is whatever major sites do.

And in most sites I use, a SELECT element is used to get a choice, nothing
more.

> I imagine their designer thought, as I did, that not having a "Go"
> button would save the user a step.

In my opinion, the usability problems incurred by other uses simply
doesn't justify this "once less step".

> Nevertheless, for now, I'm doing it the way you suggested (unless the
> client complains), as you can see on the left side of this page:

Thank you for trying to become aware of the issues involved.

> http://www.alexmarshall.org/index.php?pageId=2494

You might want to know that the navigation bar at the top of the page
doesn't render well with Opera, though it does appear to be the correct
representation. Also, the page doesn't validate:

HTML:
<URL:http://validator.w3.org/check?uri=http%3A%2F%2Fwww.alexmarshall.org%2Finde x.php%3FpageId%3D2494>

CSS:
<URL:http://jigsaw.w3.org/css-validator/validator?uri=http%3A%2F%2Fwww.alexmarshall.org%2F index.php%3FpageId%3D2494&usermedium=all>

In case you're wondering what the

Invalid number : font"MS Serif" is not a font-size value :
"MS Serif","New York",serif

errors mean, a font size is required when using the font shorthand
property. As you're only specifying families, use the font-family property.

I would certainly correct the use of an unentitified ampersand (errors
5- in the "See who is linking to this site?" link. It should be:

"http://www.technorati.com/cosmos/search.html?rank=&amp;url=www.alexmarshall.org"

Notice the use of the &amp; character entity.

Mike

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.

"Michael Winter" <> wrote in message news:<opse2325gcx13kvk@atlantis>...
> > Usage is whatever major sites do.
>
> And in most sites I use, a SELECT element is used to get a choice, nothing
> more.

Fair enough.


> > http://www.alexmarshall.org/index.php?pageId=2494
>
> You might want to know that the navigation bar at the top of the page
> doesn't render well with Opera, though it does appear to be the correct
> representation.

Thanks for that. It renders well in IE, Netscape and Mozilla on a PC
and, apparently, in Safari on a Mac (so the client tells me). I'll try
to get my hands on a copy of Opera.







> Also, the page doesn't validate:
>
> HTML:
> <URL:http://validator.w3.org/check?uri=ht...xmarshall.org%
> 2Findex.php%3FpageId%3D2494>

Thanks. I always leave validation for last. It validates now.