Tooltip or similar

[CJM]

I want a semantically-appropriate way of providing a tooltip or similar
mechanism when a user hovers over a particular cell in a table.
Specifically, I have an intranet application that enables users to find out
about tooling equipment, and when they hover over the Board No cell, I want
the location of that board to be displayed in a tooltip or similar.

I think using an ABBR or ACRONYM tag would achieve what I want, but it's not
really semantically correct. Is there something more appropriate, or should
I just use one of these two elements and be damned.

Thanks in advance

CJM

[David Dorward]

CJM wrote:

I want a semantically-appropriate way of providing a tooltip or similar
mechanism when a user hovers over a particular cell in a table.
Specifically, I have an intranet application that enables users to find out
about tooling equipment, and when they hover over the Board No cell, I want
the location of that board to be displayed in a tooltip or similar.

A title attribute on the data cell?

[Steve Pugh]

CJM wrote:

I want a semantically-appropriate way of providing a tooltip or similar
mechanism when a user hovers over a particular cell in a table.
Specifically, I have an intranet application that enables users to find out
about tooling equipment, and when they hover over the Board No cell, I want
the location of that board to be displayed in a tooltip or similar.
If the information is important then put it in the always visible
content. Not all users will see it if its only in a tooltip.
I think using an ABBR or ACRONYM tag would achieve what I want, but it's not
really semantically correct. Is there something more appropriate, or should
I just use one of these two elements and be damned.

No. Just use the title attribute on the td element. No need for any
extra elements.

Steve

[CJM]

"David Dorward" <do*****@gmail.com> wrote in message
news:11**********************@j72g2000cwa.googlegr oups.com...

CJM wrote:

I want a semantically-appropriate way of providing a tooltip or similar
mechanism when a user hovers over a particular cell in a table.
Specifically, I have an intranet application that enables users to find
out
about tooling equipment, and when they hover over the Board No cell, I
want
the location of that board to be displayed in a tooltip or similar.

A title attribute on the data cell?

Ah yes, of course...

Thanks.

[CJM]

"Steve Pugh" <st**********@gmail.com> wrote in message
news:11**********************@j72g2000cwa.googlegr oups.com...

If the information is important then put it in the always visible
content. Not all users will see it if its only in a tooltip.

Everything is importantly to somebody at sometime or other, just not to
everybody all of the time!

I'm trying to avoid clutter, and users will only periodically want this
information. However, I'm trialling it as we speak, and so I'll soon know if
the users want this info in it's own cell or whether the tooltip is
preferred.

Thanks

Chris

[Jukka K. Korpela]

CJM <cj*******@REMOVEMEyahoo.co.ukscripsit:

I'm trying to avoid clutter, and users will only periodically want
this information.

But what happens when a user's browser does not support the title="..."
attribute that you intend to use or, more probably, he cannot read its
content comfortably since it is in such a tiny font and in a small popup
that vanishes before he has read it? What happens when you need to write a
title="..." attribute with a value that is longer than normal users can
easily read?

A more robust approach makes the content of a cell (assuming that it is
inline text) a link to the extra information. You might combine this with
the title="..." attribute, perhaps so that the attribute contains a short
version of the info, sufficient for most purposes. The link would guarantee
that the extra info is available to all.

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

[CJM]

"Jukka K. Korpela" <jk******@cs.tut.fiwrote in message
news:zR******************@reader1.news.jippii.net. ..

CJM <cj*******@REMOVEMEyahoo.co.ukscripsit:

>
But what happens when a user's browser does not support the title="..."
attribute that you intend to use or, more probably, he cannot read its
content comfortably since it is in such a tiny font and in a small popup
that vanishes before he has read it? What happens when you need to write a
title="..." attribute with a value that is longer than normal users can
easily read?

This application is in an intranet environment, so we do know the
limitations of the browser. However, there are various people with various
abilities (and potentially disabilities) so it's not beyond the realms of
possibility that the user might miss this information. It's only a single
word or a short-phrase, so length is not an issue, but the fact that you
can't otherwise control the tooltip may be an issue.

A more robust approach makes the content of a cell (assuming that it is
inline text) a link to the extra information. You might combine this with
the title="..." attribute, perhaps so that the attribute contains a short
version of the info, sufficient for most purposes. The link would
guarantee that the extra info is available to all.

TBH, If we opt for the link-to-page route I probably wont bother with the
tooltip - in this environment, the richness of an application is not
necessarily a blessing; most prefer there to be just one way to do
everything!

CJM

[Jukka K. Korpela]

CJM <cj*******@REMOVEMEyahoo.co.ukscripsit:

This application is in an intranet environment,

This group is about HTML authoring for the WWW, as the name suggests.

so we do know the
limitations of the browser.

You may know what your current browser is. Do you wish to make everything
depend on that choice, even though a clueless (or clueful) boss might decide
tomorrow that for security reason, that browser shall be immediately
abandoned?

However, there are various people with
various abilities (and potentially disabilities) so it's not beyond
the realms of possibility that the user might miss this information.

Indeed. And some disabled employers might need a browser different from the
one you regard as company standard.

TBH, If we opt for the link-to-page route I probably wont bother with
the tooltip -

A link is generally too "heavy" a tool for just showing a word or two, so a
tooltip might be a reasonable alternative, suitable for _most_ users.

in this environment, the richness of an application is
not necessarily a blessing; most prefer there to be just one way to do
everything!

When the tooltip works, the user can use just it. They only need to learn
that although some word looks like a link, it points to the same information
as is available as a tooltip. This shouldn't be too difficult. Looking like
a link is not a problem and might actually be an asset: it suggests that
extra info is available, and then the user learns (in most cases) that it's
really a "quick link" that shows the info on mouseover, without clicking.

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

[CJM]

"Jukka K. Korpela" <jk******@cs.tut.fiwrote in message
news:le******************@reader1.news.jippii.net. ..

CJM <cj*******@REMOVEMEyahoo.co.ukscripsit:

>This application is in an intranet environment,

This group is about HTML authoring for the WWW, as the name suggests.

This is old ground as you well know, and has been covered plenty of times in
this NG; c.i.i. gets virtually no traffic, and what is more, the question is
about HTML. The behaviour is the same regardless of the scope of the domain
on which it is hosted.

If I'd wanted to specifically discuss browser issues, there are also
specific NGs available too, yet you missed that objection...

>
You may know what your current browser is. Do you wish to make everything
depend on that choice, even though a clueless (or clueful) boss might
decide tomorrow that for security reason, that browser shall be
immediately abandoned?

We have an IT strategy that has a shelf-life longer than both my application
and IE6 (the browser in question).

But that is beside the point. We have no control over future browsers, nor
over future web technologies and standards. We can't guarantee that any of
our work will survive future changes; all we can do is avoid forseeable
erroneous decisions. In in my case, I haven't made any design choices that
are limiting my options in the future (to my knowledge).

>However, there are various people with
various abilities (and potentially disabilities) so it's not beyond
the realms of possibility that the user might miss this information.

Indeed. And some disabled employers might need a browser different from
the one you regard as company standard.

Quite. Though not the users of this particular application. However, the
point still stands.

Both a tooltip (read 'title' attribute) and an external link are equally
accessible under current standards. If they change, all bets are off.

>TBH, If we opt for the link-to-page route I probably wont bother with
the tooltip -

A link is generally too "heavy" a tool for just showing a word or two, so
a tooltip might be a reasonable alternative, suitable for _most_ users.

This remains to be seen. The project team will make a decision on what is
the best option (or combination of options) in good time, though it is my
job to advise them (not that they always listen!).

>in this environment, the richness of an application is
not necessarily a blessing; most prefer there to be just one way to do
everything!

When the tooltip works, the user can use just it. They only need to learn
that although some word looks like a link, it points to the same
information as is available as a tooltip. This shouldn't be too difficult.
Looking like a link is not a problem and might actually be an asset: it
suggests that extra info is available, and then the user learns (in most
cases) that it's really a "quick link" that shows the info on mouseover,
without clicking.

Now we are getting down to it. Yes, I think this seems logical and
intuitive... the link styling will hint to the user that there is more
information available; if the tooltip is sufficient - great - if not, the
linked page is available. If it was up to me, I would include both since the
extra effort involved is negligible.

But believe me when I say that the users dont like too many alternatives. My
target group aren't very computer literate, aren't very open-minded and are
resistant to change. To we have to tip-toe around them sometimes.

CJM

[Andy Dingley]

Jukka K. Korpela wrote:

But what happens when a user's browser does not support the title="..."
attribute that you intend to use

Then they should get themselves a browser that works, where "works" can
reasonably be interpreted as "implementing a useful subset of the
standard".

Your usual curmudgeonliness has surpassed its usual bounds here. You've
gone from picking irrelevant holes in trivia to seemingly advocating
IE4 and working around browser foibles, rather than trying to aim for a
standard. This is the wrong attitude, you know it, and it's no excuse
just for a bit of intaweb ego-waving.

* curmudgeonliness must be a good Finnish word, because I read it in a
Moomin book at the weekend.

[CJM]

<di*****@codesmiths.comwrote in message
news:11**********************@v61g2000cwv.googlegr oups.com...

>
Then they should get themselves a browser that works, where "works" can
reasonably be interpreted as "implementing a useful subset of the
standard".

I think that will always be the highest standard you can expect to achieve.
But then again, I am a pessimist.

Your usual curmudgeonliness has surpassed its usual bounds here. You've
gone from picking irrelevant holes in trivia to seemingly advocating
IE4 and working around browser foibles, rather than trying to aim for a
standard. This is the wrong attitude, you know it, and it's no excuse
just for a bit of intaweb ego-waving.

Yeah, we've been here before too.

>
* curmudgeonliness must be a good Finnish word, because I read it in a
Moomin book at the weekend.

lol

[Jukka K. Korpela]

di*****@codesmiths.com <di*****@codesmiths.comscripsit:

Jukka K. Korpela wrote:

>But what happens when a user's browser does not support the
title="..." attribute that you intend to use

Then they should get themselves a browser that works, where "works"
can reasonably be interpreted as "implementing a useful subset of the
standard".

Exactly where does the "standard" say what a browser has to do with a
title="..." attribute? The HTML specifications simply say that the attribute
specifies an advisory title for an element. There is no requirement to make
its content available to the user.

As I wrote, my main point was not the browsers that do not make the
attribute's value available to the user but the poor quality of
implementation in browsers that do. By default, there is no hint about the
presence of such information. It is displayed, in a poor way, only when user
happens to mouse over the element. (Using the typical default rendering of
links might be a suitable visual hint, but then it would be natural to
_make_ them links.)

You've gone from picking irrelevant holes in trivia to seemingly
advocating IE4 and working around browser foibles, rather than trying
to aim for a standard.

Building and hitting strawmen, are you not? But you are rather illogical. If
there is a standard, why would anyone need to aim for a standard?

The title attribute is of questionable value, especially as implemented.
It's meaning was never clarified, so it became a "tooltip attribute", and
people abuse it in a manner that mostly hides essential information or
occasionally shows irrelevant texts. What is an "advisory title"? I think
this might be given a reasonable meaning for a _link_ (it could be described
as an auxiliary text that explains the link text or presents a longer
version of it), and for links the attribute is actually useful at times.

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

[jojo]

Andy Dingley <di*****@codesmiths.comschrieb:

>But what happens when a user's browser does not support the title="..."
attribute that you intend to use

Then they should get themselves a browser that works, where "works" can
reasonably be interpreted as "implementing a useful subset of the
standard".

If I remember right *you* are the one which always points out that it is
not the duty of the user to use the Browser/OS you want them to use but
the web-designers duty to create sites which can be shown by every user,
no matter what software they use...

>
Your usual curmudgeonliness has surpassed its usual bounds here. You've
gone from picking irrelevant holes in trivia to seemingly advocating
IE4 and working around browser foibles, rather than trying to aim for a
standard. This is the wrong attitude, you know it, and it's no excuse
just for a bit of intaweb ego-waving.

* curmudgeonliness must be a good Finnish word, because I read it in a
Moomin book at the weekend.