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 the text.
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.
...snip details...
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.
That could be solved by preloading the image with javascript. I 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.
In the past we've been avoiding the use of Javascript. The policy rationale is here: http://www.boost.org/more/lib_guide.htm#JavaScript 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. Jeff