From: Jeff Garland (jeff_at_[hidden])
Date: 2005-08-07 23:10:19
On Sun, 07 Aug 2005 20:25:43 -0400, Beth Jacobson wrote
> Marcin Kalicinski wrote:
> > There is a fairly estabilished standard on how links should look in
> > "professional" sites. This is either "normally underlined" text in different
> > colour, or nonunderlined text in different colour that changes colour when
> > pointed by mouse. Microsoft.com, google.com, ibm.com, yahoo.com, amazon.com,
> > nytimes.com, you name it, all stick to it. Deviating from that makes me say
> > it looks non professional enough for boost.
> >>>Additionally, I'd
> >>>rather have links in boxes on the right have the same style as links in
> If I might add my two cents, I agree with the above. I like the look
> of the page a lot, but the link style is confusing and counter-
> intuitive. This makes it a poor introduction to the Boost Libraries.
> Finally, and much less important. it might be nice to have a
> different link color for visited links, at least in the text and
> perhaps for the menu as well. Especially for someone exploring the
> libraries for the first time, it's nice to have a visual cue to tell
> you where you've already been.
Ok, I've been sitting quietly on the webpage for awhile ;-) I agree with the
other posters here -- I don't like the new link color either. Too subtle and
'non-standard'. I assume the idea was to make the text more readable, which
is a noble goal. The observation that followed links aren't different is a
big deal to me, though. It's a usability problem that somehow I failed to
notice and I consider a big problem for new users...
> > Also, on my
> > machine mouse cursor briefly changes to hourglass when moving on the link.
> > It looks like it was flickering.
> noticed there's no js on the page and assume that was by design, but
> maybe an exception could be made in this case, since there'd be no
> added penalty for people without js. They'd just be subject to the
> same hourglass/flickering they've got already.
That said, I think we made an exception for the iostreams docs treeview? In
any case, I think we should be willing to relook at the policy as long as
their is a fallback for browsers that don't support js.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk