Website Design Forum - Making navigational links look like clickable buttons

Author

Making navigational links look like clickable buttons

Jukka K. Korpela

2006-05-22, 6:56 am

As a basic rule of usability, a user should get immediate feedback from
clicking on a link, right? This avoids the problem that users click and
click on a link because they don't see anything happen - it worked the first
time, but the system, the browser, or the net is just slow.

Apparently, this would be a browser issue, but we can't change browsers now.
Instead, should we do something at least to navigational links? Apparently
we can make a link change appearance on mouseover, using :hover in CSS, but
the :active pseudo-element is vaguely defined and inconsistently supported.
So I though a piece of JavaScript might be useful, with
<a href="..." onmousedown="pressed(this)" onclick="clicked(this)">
e.g. so that pressed() changes the element's border (initially set to outset
style) look inset and clicked() removes the border or changes it to dotted
or dashed (or changes its color). This could make the link look like a
button that can pressed down and then changes to something wild when
released. (Or should onclick() restore the outset style?) See a demo at
http://www.cs.tut.fi/~jkorpela/test/clicklink.html

The question is: does this make sense, and is it useful? Is it useful enough
to justify the amount of extra code needed (for each link)?

--
Yucca, http://www.cs.tut.fi/~jkorpela/

Spartanicus

2006-05-22, 6:56 am

"Jukka K. Korpela" <jkorpela@cs.tut.fi> wrote:

> As a basic rule of usability, a user should get immediate feedback from
>clicking on a link, right? This avoids the problem that users click and
>click on a link because they don't see anything happen - it worked the first
>time, but the system, the browser, or the net is just slow.
>
>Apparently, this would be a browser issue, but we can't change browsers now.
>Instead, should we do something at least to navigational links? Apparently
>we can make a link change appearance on mouseover, using :hover in CSS, but
>the :active pseudo-element is vaguely defined and inconsistently supported.
>So I though a piece of JavaScript might be useful, with
><a href="..." onmousedown="pressed(this)" onclick="clicked(this)">
>e.g. so that pressed() changes the element's border (initially set to outset
>style) look inset and clicked() removes the border or changes it to dotted
>or dashed (or changes its color). This could make the link look like a
>button that can pressed down and then changes to something wild when
>released. (Or should onclick() restore the outset style?) See a demo at
>http://www.cs.tut.fi/~jkorpela/test/clicklink.html
>
>The question is: does this make sense, and is it useful? Is it useful enough
>to justify the amount of extra code needed (for each link)?

Firstly I consider this a solution to a non existing problem. There is
sufficient indication to a user that a link has been activated unless
the user has switched off UI elements such as a button bar, status bar
etc, in which case the user's choice not to get such an indication is
likely deliberate and should be respected.

Secondly I don't see the need for JS, the :active pseudo is supported
well enough in the big three for this purpose.

Thirdly no self respecting designer would use outset/inset due to the
fact that browsers are free to render the gradient and do so
inconsistently.

Fourthly the use of borders to make a link look like a button is
profoundly confusing to begin with, it will make a link not look like a
link anymore but like a form element, only different.

Fifthly padding + borders on an text link embedded in other text makes
the text even harder to read, and it necessitates specifying a larger
line-height to make room for the padding and borders.

Sixthly wrapping link text causes an ugly effect when borders are
applied.

--
Spartanicus

Alan J. Flavell

2006-05-22, 6:56 am

On Mon, 22 May 2006, Jukka K. Korpela wrote:

> As a basic rule of usability, a user should get immediate feedback
> from clicking on a link, right?

Yes. The first point, though, is that a link should be recognisable
as a link, and not camouflaged as some other kind of widget (imagemap,
form button, whatever).

> This avoids the problem that users click and click
> on a link because they don't see anything happen -

Normally, when I click on a link, the cursor turns to an hourglass,
which indicates precisely that something *is* happening (and the
status bar usually shows progress indications). When that *fails* to
happen (or when the hourglass prematurely disappears), I usually find
that it's some misguided javascript which is taking away these useful
progress indications.

> Apparently, this would be a browser issue, but we can't change
> browsers now.

I'm not so sure about that! There have been quite a number of changes
in browsers. Not least, prohibiting misguided authors from
interfering with the status indications, and options to selectively
block javascript...

[...]
> See a demo at
> http://www.cs.tut.fi/~jkorpela/test/clicklink.html

It's good fun, but - with respect - it seems to me to violate a number
of the above principles. If there really /is/ a problem, then I'd
rather see it solved on the browser side, so that it presents a
consistent interface for all pages visited. Could be a user-optional
extension, for example; I guess it could be done with a js
bookmarklet, though I haven't tried to implement it.

The problem, as ever, with site-specific material is that users spend
most of their time on other people's sites, and need some time to
adjust to site-specific interface differences. To my way of thinking,
that rules out this kind of approach. Videos are a current bugbear:
every goddamned site has a different interface - it's impossible to
learn a uniform user gesture to determine whether to view the video in
a browser window - to open an external application - or to initiate a
download for later viewing while continuing to browse around. Grrr.

all the best

Jukka K. Korpela

2006-05-23, 7:03 pm

Spartanicus <invalid@invalid.invalid> scripsit:

> Firstly I consider this a solution to a non existing problem.

OK, fair comment. Thank you for your detailed analysis, and thanks to Alan
for his insight too. Originally, this issue was raised to me as a problem
and I tried to look at it from that perspective. I think I'm now in a much
better position to explain why it's not constructive to make links react
more visibly to clicking.

A few margin notes, though:

> There is
> sufficient indication to a user that a link has been activated unless
> the user has switched off UI elements such as a button bar, status bar
> etc,

Well, the bars are rather far from the link, aren't they? I think the link
itself should indicate that was clicked on, but I admit that we need to
leave this a browser issue.

> Secondly I don't see the need for JS, the :active pseudo is supported
> well enough in the big three for this purpose.

I don't think it is. On IE, clicking pressing the mouse button down when the
pointer is on the link makes the link match the :active selector. That is,
the link becomes active before it has been clicked on. Moreover, if you
follow a link and then return (using the Back button), the link remains as
matching :active.

> Thirdly no self respecting designer would use outset/inset due to the
> fact that browsers are free to render the gradient and do so
> inconsistently.

I think I have to agree. Inconsistency isn't such a big issue really, but
the border doesn't _look_ outset or inset.

--
Yucca, http://www.cs.tut.fi/~jkorpela/

Spartanicus

2006-05-23, 11:02 pm

"Jukka K. Korpela" <jkorpela@cs.tut.fi> wrote:

>
>Well, the bars are rather far from the link, aren't they?

As Alan noted the cursor changing to an hourglass should be the
principle indicator. That said, on my main browser I notice the load bar
that pops up inside the address bar in inverse colours more than I'd
notice the hourglass cursor. Firefox's changing stop/reload button is
pretty conspicuous also.

From what I can see testing with local resources IE doesn't appear to
change the cursor to an hourglass. It's status bar with the inverse
colour load bar is imo fairly conspicuous. Anything of sufficient size
that moves or blinks manages to draw my attention, regardless of the
fact that it appears on top or below the page content like on a button
or status bar.

>I think the link itself should indicate that was clicked on

Imo nothing should happen to the look of a link after it has been
activated with a pointing device (the cursor changing into an hourglass
being a much better indicator), there may be a case for the link
changing when a link is activated by the keyboard.

>
>I don't think it is. On IE, clicking pressing the mouse button down when the
>pointer is on the link makes the link match the :active selector.

Pressing the mouse button down when the pointer is on the link also
activates the link no?

>That is,
>the link becomes active before it has been clicked on.

IE does have a problem in that a:active matches when you tab to the link
with the keyboard.

>Moreover, if you
>follow a link and then return (using the Back button), the link remains as
>matching :active.

Yes that's the same issue as above, but only as long as the link retains
focus.

--
Spartanicus

Jukka K. Korpela

2006-05-24, 7:36 pm

Spartanicus <invalid@invalid.invalid> scripsit:

> From what I can see testing with local resources IE doesn't appear to
> change the cursor to an hourglass.

That's true, and probably one of the main reasons why the issue popped up
(i.e. why I was contacted by a person who was worried about the problem that
people cannot see whether they successfully clicked on a link or not).

>
> Pressing the mouse button down when the pointer is on the link also
> activates the link no?

(Read my words "clicking pressing" as "pressing". My typical mistake: I
started typing something, then changed my mind but forgot to delete a word.
Is there any HTML command that could prevent this? :-) )

No. Well, it depends on your definition of "activate". Pressing the button
down makes the link focused on, and IE shows a "focus rectangle" (dotted
border-like lines around the link), but it does not cause the link to be
followed. If you (intentionally or unintentionally) move the pointer away
before releasing the mouse button, the link remains focused.

> IE does have a problem in that a:active matches when you tab to the
> link with the keyboard.

It more or less confuses :active with :focus.

--
Yucca, http://www.cs.tut.fi/~jkorpela/