Hi all, I know gazillion words have been said on the looks of the new webpage, but still I want to add my 2 pennies. Briefly, I think that links in the text look very ugly and... amateurish? If you insist on having them underlined I suggest you stick with more standard look, such as on OpenOffice.org webpage (and many others). This looks much more professional. Additionally, I'd rather have links in boxes on the right have the same style as links in the text. cheers, Marcin
Marcin Kalicinski wrote:
I know gazillion words have been said on the looks of the new webpage, but still I want to add my 2 pennies. Briefly, I think that links in the text look very ugly and... amateurish?
OK. How is it ugly? How is it amateurish?
If you insist on having them underlined I suggest you stick with more standard look, such as on OpenOffice.org webpage (and many others). This looks much more professional.
OpenOffice.org doesn't have underlines on links, from my POV.
Additionally, I'd rather have links in boxes on the right have the same style as links in the text.
Why? PS. I'm not trying to be abrasive, it's just not possible to use feedback that doesn't explain why or how. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
I sent these related suggestions in a post some time ago, although apparently they were missed as I received no response. --- I don't know whether this has been mentioned and/or discussed previously, but I think it would be better to stick with the default font styles both for the text and more importantly for the links in the new home page design. Although the alternate font styles and colors to some extent make the home page prettier, I find that they actually make it harder to read and use. The default font style is generally one in which text is easily read by the user while still being small enough that a large amount of text can fit on the screen at once. A custom font, such as the one selected for the normal text in the new design, may display either smaller or larger than the user would like. I find that the custom link styling is a greater problem. The black text with a light blue underline is far less effective at identifying a link than my default link style, both because it does not stand out from the rest of the text as my default style of blue text with a blue underline, and also because I am not as familiar with it identifying a link as I am with my default style. Furthermore, some of the links (such as in the right-side boxes) do not even have an underline, which makes them even less identifiable as links, and some non-link pieces of text appear to be links because of the styling. For example, the headings in the right-side boxes are in blue text with a blue underline and change color when the mouse is moved over them, a style that is commonly used only for links, and similarly, the "Revised 8 May, 2005" notice at the bottom right is in the same style as the links on the left side, and even changes color when the mouse is moved over it, but is not a link. Less strongly than in regards to the text styling, I also suggest that the left and right margins currently filled by gradient images be eliminated, since they take up space and don't really improve the appearance of the page. -- Jeremy Maitin-Shepard
Jeremy Maitin-Shepard <jbms@cmu.edu> writes:
I sent these related suggestions in a post some time ago, although apparently they were missed as I received no response.
---
I don't know whether this has been mentioned and/or discussed previously, but I think it would be better to stick with the default font styles both for the text and more importantly for the links in the new home page design. Although the alternate font styles and colors to some extent make the home page prettier, I find that they actually make it harder to read and use.
The default font style is generally one in which text is easily read by the user while still being small enough that a large amount of text can fit on the screen at once. A custom font, such as the one selected for the normal text in the new design, may display either smaller or larger than the user would like.
Yes, it's been discussed over and over. Recently, too! I don't have a strong position on the right answer here, but I can say that I don't have the ability to change my browser settings so a webpage written without font and link presentation tuning is as nice for me to look at as what Rene has done. I suggest you check through the mail archives and read the various arguments to see if you can add anything new. It would be a shame to go through the whole business again, especially if in the end you _do_ have something new to say; it would probably get lost in the noise. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Jeremy Maitin-Shepard writes:
I sent these related suggestions in a post some time ago, although apparently they were missed as I received no response.
---
I don't know whether this has been mentioned and/or discussed previously, [...] Yes, it's been discussed over and over. Recently, too!
This is an indicator that a rationale page for the web design would be useful. Regards, m Send instant messages to your online friends http://au.messenger.yahoo.com
Martin Wille <mw8329@yahoo.com.au> writes:
David Abrahams wrote:
Jeremy Maitin-Shepard writes:
I sent these related suggestions in a post some time ago, although apparently they were missed as I received no response.
---
I don't know whether this has been mentioned and/or discussed previously, [...] Yes, it's been discussed over and over. Recently, too!
This is an indicator that a rationale page for the web design would be useful.
True! A blurb on the front titled "Hey, what's with the new webpage?" would be a good idea. We could then explain that it's still evolving. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"Jeremy Maitin-Shepard" wrote: [ old vs new homepage style ] Perhaps solution would be to have two html pages: old_layout.html and new_layout.html and index.html redirect into one of these. Whoever doesn't like one style would simply edit the index.html, once and forever. I personally prefere the old style. I need index.html only to get quickly to the documentation and with new style it takes one second more to identify the proper link. /Pavel
Rene Rivera wrote:
Marcin Kalicinski wrote:
I know gazillion words have been said on the looks of the new webpage, but still I want to add my 2 pennies. Briefly, I think that links in the text look very ugly and... amateurish?
OK. How is it ugly? How is it amateurish?
IMHO, it isn't amateurish at all.
If you insist on having them underlined I suggest you stick with more standard look, such as on OpenOffice.org webpage (and many others). This looks much more professional.
OpenOffice.org doesn't have underlines on links, from my POV.
That's strange. They get displayed underlined here.
Additionally, I'd rather have links in boxes on the right have the same style as links in the text.
Why?
I understand that request. It's the same functionality (a link to some other page). Why are there different visual representations for the same functionality? Without relying on mouse-over stuff, it's non-obvious that the box contents are links. In fact, I would have thought that "Support" is a link because it's underlined. However, it is not. Why do the titles in the Box not only have underlines but also this mouse-over stuff? They are not links, so there's no need to help the user aim at the correct spot. Maybe it would be a good idea to actually make them links. Why does the ">>" icon indicate a link in the boxes, but not in the main part of the page? I usually have loading of pictures turned off (which is why I didn't recognize those inconsistencies earlier). Without the ">>", there's no indication that the box contents are links. I understand that a box contains an index for a different page and I like the idea of grouping them. However, I suggest to add some more obvious indication that the index items are links (maybe underlining in some light color, maybe underlining only on mouse-over). On terminal based browsers, these problems don't seem to exist. All links get displayed consistently. Regards, m Send instant messages to your online friends http://au.messenger.yahoo.com
Hi Rene, I'm not trying to be abrasive either. I appreciate the work that has been done. Preferences and likings is something that is impossible to explain, I'm only trying to "vote against". Maybe if there is enough guys like me you will consider redesigning?
look very ugly and... amateurish?
OK. How is it ugly? How is it amateurish?
Ugly is just my personal feeling. But amateurish is because it looks like somebody forcibly tried to do something more interesting than the standard, but the result is actually worse than the standard. 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.
Why?
For consistency. They do not look like links immediately. Also, on my machine mouse cursor briefly changes to hourglass when moving on the link. It looks like it was flickering. But that's less important for me than links in main text. cheers, Marcin
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. One of the things that has impressed me the most in using the libraries is how intuitive they are. It's also a marketing issue since "intuitive" translates to lower training costs. It would be nice if that quality were suggested by the design of the website. How about using the same blue as the headings for both linked text and menu items? The menu headings could be switched to black to maintain the color contrast between the menu headings and items. Both text and menu links could be underlined on mouseover. I also agree with someone above who said that the menu headers shouldn't change on mouseover. The change says "link" to users and should be avoided unless that's what it really means. 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.
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.
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
Jeff Garland wrote:
I assume the idea was to make the text more readable, which is a noble goal.
The idea was indeed to make body text more readable.
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...
Yes, I'll have to address that. As it's common for people to rely on the visited color changes.
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.
This "flicker" is only a problem on IE. There's only so much time I will spend on working around bugs on IE. Just like we don't spend much time in supporting old C++ compilers. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
On Sun, 07 Aug 2005 23:36:32 -0500, Rene Rivera wrote
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.
This "flicker" is only a problem on IE. There's only so much time I will spend on working around bugs on IE.
Interesting. IE6 is probably still the majority case for our users (Boost users are weird b/c they tend to use alternative browsers much more then 'regular folks' -- I base this comment on Wiki web stats, BTW). Still, I agree, this doesn't seem like a big enough issue to spend time on -- but perhaps someone else will contribute a fix ;-)
Just like we don't spend much time in supporting old C++ compilers.
If only it were true -- the amount of time spent by really talented folks that hang out around here supporting old compiler relics is almost unimaginable... Jeff
Jeff Garland wrote:
On Sun, 07 Aug 2005 23:36:32 -0500, Rene Rivera wrote
Just like we don't spend much time in supporting old C++ compilers.
If only it were true -- the amount of time spent by really talented folks that hang out around here supporting old compiler relics is almost unimaginable...
True, and the same goes for the web design I've done so far. But I get really tired of making a new web page design in 30 minutes for Gecko, Safari, Opera, etc. And then have to spend at least 12 hours making it work on IE without breaking on the others. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
On Mon, 08 Aug 2005 00:08:19 -0500, Rene Rivera wrote
Jeff Garland wrote:
On Sun, 07 Aug 2005 23:36:32 -0500, Rene Rivera wrote
Just like we don't spend much time in supporting old C++ compilers.
If only it were true -- the amount of time spent by really talented folks that hang out around here supporting old compiler relics is almost unimaginable...
True, and the same goes for the web design I've done so far. But I get really tired of making a new web page design in 30 minutes for Gecko, Safari, Opera, etc. And then have to spend at least 12 hours making it work on IE without breaking on the others.
LOL, yeah that stinks. Good news is IE7 is just around the corner -- or that could be the bad news ;-) Jeff
Rene Rivera wrote:
This "flicker" is only a problem on IE. There's only so much time I will spend on working around bugs on IE. Just like we don't spend much time in supporting old C++ compilers.
I'd suggest just not to use these >> at all and use 2 stylesheets on the page so if user has a browser capable to select stylesheets she will be happy. I'm against JS, page beauty and fixing IE bugs. I'm for standard compliant XHTML/CSS, and for page usability. Boost doesn't e I dislike old minimalistic design of the homepage because it reminds me days of IE3/NN4. But I'd prefer more visible links. Body readability doesn't matter at all for me. I vote for something like http://en.wikipedia.org/wiki/Battle_of_Jutland (as an alternate stylesheet). Andrey
Andrey Melnikov <melnikov@simplexsoft.com> writes:
Rene Rivera wrote:
This "flicker" is only a problem on IE. There's only so much time I will spend on working around bugs on IE. Just like we don't spend much time in supporting old C++ compilers.
I'd suggest just not to use these >> at all
The ">>" if kept, should probably be replaced by the graphic element from the Boost logo.
and use 2 stylesheets on the page so if user has a browser capable to select stylesheets she will be happy.
What would the stylesheets have to do with the flickering problem? <facetious>Why should we stop at two stylesheets?</facetious> What's the point?
I'm against JS, page beauty
Any enemy of beauty is an enemy of mine ;-)
and fixing IE bugs. I'm for standard compliant XHTML/CSS, and for page usability.
Usability and beauty often are interdependent.
Boost doesn't e
I don't "e" either ;-)
I dislike old minimalistic design of the homepage because it reminds me days of IE3/NN4. But I'd prefer more visible links. Body readability doesn't matter at all for me. I vote for something like http://en.wikipedia.org/wiki/Battle_of_Jutland (as an alternate stylesheet).
I've always liked Wikipedia. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Andrey Melnikov <melnikov@simplexsoft.com> writes:
Rene Rivera wrote:
This "flicker" is only a problem on IE. There's only so much time I will spend on working around bugs on IE. Just like we don't spend much time in supporting old C++ compilers.
I'd suggest just not to use these >> at all
The ">>" if kept, should probably be replaced by the graphic element from the Boost logo.
and use 2 stylesheets on the page so if user has a browser capable to select stylesheets she will be happy.
What would the stylesheets have to do with the flickering problem? <facetious>Why should we stop at two stylesheets?</facetious> What's the point?
The stylesheets don't help with the flickering. They help with links. The default stylesheet will have fancy links like now and the alternate stylesheet will have usual blue underlined links.
Boost doesn't e
I don't "e" either ;-)
I must go home and have a sleep. Andrey
Andrey Melnikov wrote:
Rene Rivera wrote:
This "flicker" is only a problem on IE. There's only so much time I will spend on working around bugs on IE. Just like we don't spend much time in supporting old C++ compilers.
I'd suggest just not to use these >> at all and use 2 stylesheets on the page so if user has a browser capable to select stylesheets she will be happy.
The flicker also has nothing to do with the >> images for the links on the menus. It already uses 2 stylesheets, and the next design uses 7. But what you meant where alternate stylesheets. And that doesn't work on all popular browsers.
I'm against JS, page beauty and fixing IE bugs. I'm for standard compliant XHTML/CSS, and for page usability. Boost doesn't e
It's already XHTML & CSS compliant. It's also mostly compliant with a variety of WAI requirements. It doesn't use JS, except to work around IE bugs where it was easy, convenient, well documented. and tested fix. If you don't want "beauty" you can turn the stylesheet off, use a text browser, override with some other styles, or just look at the well structured XHTML source directly.
But I'd prefer more visible links.
It's been noted and will hopefully improve in the future.
Body readability doesn't matter at all for me.
The your are very far away from the target audience we expect to be _reading_ the Boost web pages. Perhaps you should say how you want to use the web pages and we can try to accommodate that behavior, because it may be a common behavior of visitors.
I vote for something like http://en.wikipedia.org/wiki/Battle_of_Jutland (as an alternate stylesheet).
It's also been mentioned before. And at least one person did a sample of the Boost page with that design. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
In the past we've been avoiding the use of Javascript.
This "flicker" is only a problem on IE. There's only so much time I will spend on working around bugs on IE. Just like we don't spend much time in supporting old C++ compilers.
You can fix the flicker quite simply and portably without JS : ----front.css:76----- /* Lists in sidecells are menus. */ .sidecell ul a { border: none; background: url(menu_link_indicator.png) no-repeat -14px center; padding-left: 14px; } .sidecell ul a:hover { border: none; background-position: left center; } The idea being the background is loaded straight away, drawn outside the links box, and slid into position on hover. You also need to add this to httpd.conf, otherwise IE will just keep on downloading images, over and over and over again, even when they've been loaded at page load time. #this stops background-image flicker in IE BrowserMatch "MSIE" brokenvary=1 BrowserMatch "Mozilla/4.[0-9]{2}" brokenvary=1 BrowserMatch "Opera" !brokenvary SetEnvIf brokenvary 1 force-no-vary ExpiresActive On ExpiresByType image/gif A2592000 ExpiresByType image/jpeg A2592000 ExpiresByType image/png A2592000 For what its worth I like the >> on the links. Sam
Sam Partington wrote:
You also need to add this to httpd.conf, otherwise IE will just keep on downloading images, over and over and over again, even when they've been loaded at page load time.
#this stops background-image flicker in IE BrowserMatch "MSIE" brokenvary=1 BrowserMatch "Mozilla/4.[0-9]{2}" brokenvary=1 BrowserMatch "Opera" !brokenvary SetEnvIf brokenvary 1 force-no-vary ExpiresActive On ExpiresByType image/gif A2592000 ExpiresByType image/jpeg A2592000 ExpiresByType image/png A2592000
Unfortunately that level of server setup is beyond our control. We can only hope that SF has such configuration already present on their servers. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
Rene Rivera <grafik.list@redshift-software.com> writes:
Sam Partington wrote:
You also need to add this to httpd.conf, otherwise IE will just keep on downloading images, over and over and over again, even when they've been loaded at page load time.
#this stops background-image flicker in IE BrowserMatch "MSIE" brokenvary=1 BrowserMatch "Mozilla/4.[0-9]{2}" brokenvary=1 BrowserMatch "Opera" !brokenvary SetEnvIf brokenvary 1 force-no-vary ExpiresActive On ExpiresByType image/gif A2592000 ExpiresByType image/jpeg A2592000 ExpiresByType image/png A2592000
Unfortunately that level of server setup is beyond our control. We can only hope that SF has such configuration already present on their servers.
Sam, why don't you register a support request with the SF site admins asking them to make that change and explaining why it's a good idea? -- Dave Abrahams Boost Consulting www.boost-consulting.com
Unfortunately that level of server setup is beyond our control. We can only hope that SF has such configuration already present on their servers.
Sam, why don't you register a support request with the SF site admins asking them to make that change and explaining why it's a good idea?
Thats done : http://tinyurl.com/97tuv Sam
Sam Partington <sam.partington@gmail.com> writes:
Unfortunately that level of server setup is beyond our control. We can only hope that SF has such configuration already present on their servers.
Sam, why don't you register a support request with the SF site admins asking them to make that change and explaining why it's a good idea?
Thats done :
Thanks! -- Dave Abrahams Boost Consulting www.boost-consulting.com
Beth Jacobson <bethj@bajac.com> writes:
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. One of the things that has impressed me the most in using the libraries is how intuitive they are. It's also a marketing issue since "intuitive" translates to lower training costs. It would be nice if that quality were suggested by the design of the website.
I hate to say it, but these criticisms are starting to ring true for me as well :( I still think of wikipedia.org as a prime example of a site design that works and looks good without any special help on my part. I wonder if we shouldn't use something much more like that?
How about using the same blue as the headings for both linked text and menu items? The menu headings could be switched to black to maintain the color contrast between the menu headings and items. Both text and menu links could be underlined on mouseover. I also agree with someone above who said that the menu headers shouldn't change on mouseover. The change says "link" to users and should be avoided unless that's what it really means.
Beth, your proposals sound interesting... but they'd be a whole lot easier to evaluate if you'd just make up the page or CSS stuff required and post it where we can all get a look at it.
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.
It looks to me as though wikipedia does that, but it so subtle that I can barely see the change. At least it probably won't upset those people who *hate* the changing link color effect ;-)
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.
Care to contribute the code to do that? -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
How about using the same blue as the headings for both linked text and menu items? The menu headings could be switched to black to maintain the color contrast between the menu headings and items. Both text and menu links could be underlined on mouseover. I also agree with someone above who said that the menu headers shouldn't change on mouseover. The change says "link" to users and should be avoided unless that's what it really means.
Beth, your proposals sound interesting... but they'd be a whole lot easier to evaluate if you'd just make up the page or CSS stuff required and post it where we can all get a look at it.
Done. The test page is up at http://bajac.com/boost/ I made a few additional changes, most notably increasing the menu text size which meant there was no longer room for the mouseover pointer image, and I had to shorten "Boost General Interest" to "General Interest" (under "Groups"). If either of these are a problem I could shrink the text back down and put them back. I wanted to make the text size large enough so the similarity between text links and menu links would be unmistakable, but maybe the color alone would be enough.
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.
It looks to me as though wikipedia does that, but it so subtle that I can barely see the change. At least it probably won't upset those people who *hate* the changing link color effect ;-)
I went for subtle but clear. Hopefully people on various OS's and browsers can tell me if I succeeded.
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.
Care to contribute the code to do that?
Rene noted that the flicker only occurs on IE. That being the case, I doubt the fix I had in mind would work.
From: Beth Jacobson <bethj@bajac.com>
David Abrahams wrote:
Beth, your proposals sound interesting... but they'd be a whole lot easier to evaluate if you'd just make up the page or CSS stuff required and post it where we can all get a look at it.
Done. The test page is up at http://bajac.com/boost/
I don't find the enlarged text an improvement, particularly. In a sense, the enlarged size makes that text compete too much with the body text on the left 2/3. I like the consistent treatment of links. I don't like the selected color as the contrast is too low. Nevertheless, colored text is better than underlining. The subtle difference for visited links is fine, but the selected color has even less contrast, so it is a poor choice. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Rob Stewart writes:
From: Beth Jacobson <bethj@bajac.com>
David Abrahams wrote:
Beth, your proposals sound interesting... but they'd be a whole lot easier to evaluate if you'd just make up the page or CSS stuff required and post it where we can all get a look at it.
Done. The test page is up at http://bajac.com/boost/
I don't find the enlarged text an improvement, particularly. In a sense, the enlarged size makes that text compete too much with the body text on the left 2/3.
Well, the navigation links are supposed to be easily identifiable at first glance. Besides, they don't really compete with the body text in a sense that once you start reading it, you concentrate all your attention on the flow and simply don't notice what's around it (much as you don't notice the ads and the likes when you are reading a news site). IMO from usability standpoint the larger size is an improvement.
I like the consistent treatment of links. I don't like the selected color as the contrast is too low.
FWIW, it works for me. The links are clearly distinguishable from the plain text.
Nevertheless, colored text is better than underlining.
Most definitely.
The subtle difference for visited links is fine, but the selected color has even less contrast, so it is a poor choice.
Again, it's clearly distinguishable, which IMO makes it an acceptable choice (although may be not the best one). -- Aleksey Gurtovoy MetaCommunications Engineering
From: Aleksey Gurtovoy <agurtovoy@meta-comm.com>
Rob Stewart writes:
David Abrahams wrote:
I don't find the enlarged text an improvement, particularly. In a sense, the enlarged size makes that text compete too much with
From: Beth Jacobson <bethj@bajac.com> the body text on the left 2/3.
Well, the navigation links are supposed to be easily identifiable at first glance. Besides, they don't really compete with the body text in
They should be easily identifiable when you look at that side of the page, but they shouldn't draw your attention to that side immediately. The larger text does the latter.
a sense that once you start reading it, you concentrate all your attention on the flow and simply don't notice what's around it (much as you don't notice the ads and the likes when you are reading a news site). IMO from usability standpoint the larger size is an improvement.
Did you find the smaller text somehow unreadable?
I like the consistent treatment of links. I don't like the selected color as the contrast is too low.
FWIW, it works for me. The links are clearly distinguishable from the plain text.
Yes, they are distinguishable. The problem is, they are harder to read because of the lower contrast.
The subtle difference for visited links is fine, but the selected color has even less contrast, so it is a poor choice.
Again, it's clearly distinguishable, which IMO makes it an acceptable choice (although may be not the best one).
Readability is of great concern, not just distinguishability. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Rob Stewart writes:
From: Aleksey Gurtovoy <agurtovoy@meta-comm.com>
Rob Stewart writes:
I don't find the enlarged text an improvement, particularly. In a sense, the enlarged size makes that text compete too much with the body text on the left 2/3.
Well, the navigation links are supposed to be easily identifiable at first glance. Besides, they don't really compete with the body text in
They should be easily identifiable when you look at that side of the page, but they shouldn't draw your attention to that side immediately. The larger text does the latter.
From a seasoned visitor's standpoint, I consider this to be a feature: I read the text only once, and the rest of the time what I want is to find the navigation links instantly. Falimiarity with the site's layout doesn't help as much as one would hope for here because usually you regularly visit more than just one site.
a sense that once you start reading it, you concentrate all your attention on the flow and simply don't notice what's around it (much as you don't notice the ads and the likes when you are reading a news site). IMO from usability standpoint the larger size is an improvement.
Did you find the smaller text somehow unreadable?
Yes, I find that I actually have to read what the links say before clicking, while with the larger text I recognize what I'm looking for "instantly".
I like the consistent treatment of links. I don't like the selected color as the contrast is too low.
FWIW, it works for me. The links are clearly distinguishable from the plain text.
Yes, they are distinguishable. The problem is, they are harder to read because of the lower contrast.
Lower contrast between the links and the text or the links and the background?
The subtle difference for visited links is fine, but the selected color has even less contrast, so it is a poor choice.
Again, it's clearly distinguishable, which IMO makes it an acceptable choice (although may be not the best one).
Readability is of great concern, not just distinguishability.
No argument here. -- Aleksey Gurtovoy MetaCommunications Engineering
From: Aleksey Gurtovoy <agurtovoy@meta-comm.com>
Rob Stewart writes:
From: Aleksey Gurtovoy <agurtovoy@meta-comm.com>
Rob Stewart writes:
I don't find the enlarged text an improvement, particularly. In a sense, the enlarged size makes that text compete too much with the body text on the left 2/3.
Well, the navigation links are supposed to be easily identifiable at first glance. Besides, they don't really compete with the body text in
They should be easily identifiable when you look at that side of the page, but they shouldn't draw your attention to that side immediately. The larger text does the latter.
From a seasoned visitor's standpoint, I consider this to be a feature: I read the text only once, and the rest of the time what I want is to find the navigation links instantly. Falimiarity with the site's layout doesn't help as much as one would hope for here because usually you regularly visit more than just one site.
Ah, I see the difference. I've said before that I don't think the main page should be designed for visitors like us. It should be designed for the newcomer. There should be other pages that we bookmark that provide the things we want regularly. Thus, I'm not looking for the main page to be my main entry point to what I want from the Boost web site. Indeed, I'll create my own bookmarks or put links on my own home page to get me to what I want quickly.
a sense that once you start reading it, you concentrate all your attention on the flow and simply don't notice what's around it (much as you don't notice the ads and the likes when you are reading a news site). IMO from usability standpoint the larger size is an improvement.
Did you find the smaller text somehow unreadable?
Yes, I find that I actually have to read what the links say before clicking, while with the larger text I recognize what I'm looking for "instantly".
That's as it should be for newcomers.
I like the consistent treatment of links. I don't like the selected color as the contrast is too low.
FWIW, it works for me. The links are clearly distinguishable from the plain text.
Yes, they are distinguishable. The problem is, they are harder to read because of the lower contrast.
Lower contrast between the links and the text or the links and the background?
THe problem is low contrast relative to the background; it makes the text harder to read, something Rene mentions in another reply in this thread.
The subtle difference for visited links is fine, but the selected color has even less contrast, so it is a poor choice.
Again, it's clearly distinguishable, which IMO makes it an acceptable choice (although may be not the best one).
Readability is of great concern, not just distinguishability.
No argument here.
Apparently, we need to agree on the audience in order to agree on the visual treatment. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
On Mon, 8 Aug 2005 23:00:15 -0400 Rob Stewart <stewart@sig.com> wrote:
Ah, I see the difference. I've said before that I don't think the main page should be designed for visitors like us. It should be designed for the newcomer. There should be other pages that we bookmark that provide the things we want regularly.
Thus, I'm not looking for the main page to be my main entry point to what I want from the Boost web site. Indeed, I'll create my own bookmarks or put links on my own home page to get me to what I want quickly.
I don't think having a bunch of bookmarks is the solution either. I like the idea of having a scaled down front page for non-newbies, which has minimal textual information, and a bunch of links to the good stuff.
From: Jody Hagins <jody-boost-011304@atdesk.com>
On Mon, 8 Aug 2005 23:00:15 -0400 Rob Stewart <stewart@sig.com> wrote:
Ah, I see the difference. I've said before that I don't think the main page should be designed for visitors like us. It should be designed for the newcomer. There should be other pages that we bookmark that provide the things we want regularly.
Thus, I'm not looking for the main page to be my main entry point to what I want from the Boost web site. Indeed, I'll create my own bookmarks or put links on my own home page to get me to what I want quickly.
I don't think having a bunch of bookmarks is the solution either. I like the idea of having a scaled down front page for non-newbies, which has minimal textual information, and a bunch of links to the good stuff.
I had mentioned that previously. Here I was just indicating that if nothing else, I'd do things for myself to suit my own needs. The significant point is that the main page should be focused on new visitors, not regulars. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Rob Stewart wrote:
From: Aleksey Gurtovoy <agurtovoy@meta-comm.com>
Rob Stewart writes:
From: Aleksey Gurtovoy <agurtovoy@meta-comm.com>
Rob Stewart writes:
a sense that once you start reading it, you concentrate all your attention on the flow and simply don't notice what's around it (much as you don't notice the ads and the likes when you are reading a news site). IMO from usability standpoint the larger size is an improvement.
Did you find the smaller text somehow unreadable?
I think that even the enlarged version is still a tad to small. I find the links extremly hard to read. I think that the links should be the same font size as the main text, or if you must, only marginaly smaller. I also don't think it can possibily be confusing or distracting, since the Links are well separated by the (very nice looking) shadowed frames. Most sites I know have link text in either: Same font size: www.slashdot.org www.heise.de Only a little bit smaller: en.wikipedia.org/wiki/Main_Page www.kde.org Smaller but bolt faced: www.gentoo.org On a sudden inspiration I checked with Internet Explorer. There the font sizes are ok, but IIRC IE is known to show fonts larger than it should.
Yes, they are distinguishable. The problem is, they are harder to read because of the lower contrast.
Lower contrast between the links and the text or the links and the background?
THe problem is low contrast relative to the background; it makes the text harder to read, something Rene mentions in another reply in this thread.
Well, but blue on white is fairly standard for the web (look at google, wikipedia, ...), and I can't see anybody who is not visually impaired having problems with it. In the case of visually impaired they probably have a custom Stylesheet in place which changes the colors and layout anyway. By the way I really like the new layout. Just my 2 cent. Fabio
From: Fabio Fracassi <f.fracassi@gmx.net>
Rob Stewart wrote:
From: Aleksey Gurtovoy <agurtovoy@meta-comm.com>
Rob Stewart writes:
From: Aleksey Gurtovoy <agurtovoy@meta-comm.com>
Rob Stewart writes:
I think that even the enlarged version is still a tad to small. I find the links extremly hard to read.
I don't know what it looks like on your screen, but at my normal settings, both fonts are quite readable. I can, of course, enlarge or shrink the text at will. I note that when I enlarge the text, the background does not grow with the text, so the links on the right push past the white background and into the shadow. Since I do find it necessary to enlarge text for various purposes at many web sites, I can easily envision someone with vision problems wanting to do the same. At that point, the links become much harder to use.
I think that the links should be the same font size as the main text, or if you must, only marginaly smaller.
To do so means to use a single column, I think. We're very nearly there anyway because of the narrow window problems.
I also don't think it can possibily be confusing or distracting, since the Links are well separated by the (very nice looking) shadowed frames.
It's not that you will find yourself reading off the end of a line and into the links section, but rather that it is visually more interesting and, thus, draws your attention.
Most sites I know have link text in either:
Same font size: www.slashdot.org www.heise.de
Only a little bit smaller: en.wikipedia.org/wiki/Main_Page www.kde.org
Smaller but bolt faced: www.gentoo.org
When I view the page in Firefox, the links on the right *do* appear "only a little bit smaller."
THe problem is low contrast relative to the background; it makes the text harder to read, something Rene mentions in another reply in this thread.
Well, but blue on white is fairly standard for the web (look at google, wikipedia, ...), and I can't see anybody who is not visually impaired having problems with it.
It isn't the standard blue. It is a blue/green color with lower contrast. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
In article <dd82f9$sot$1@sea.gmane.org>, Beth Jacobson <bethj@bajac.com> wrote:
Done. The test page is up at http://bajac.com/boost/
I like this except for one thing: because links and titles are bluish text, it's really hard to tell that titles are not links. I realize that the blue color of titles is slightly darker, but the problem is that the titles are also set in a considerably heavier typeface, and as a result I initially thought that titles are links and are using the same color (and just look darker because the typeface is heavier). This is further compounded by the fact that the section heading image (">>") looks very much like a stylized arrow, which to me suggests a link. In short, I believe that the highlight color (dark blue) and the link color (lighter blue) are insufficiently distinct and therefore confusing. I think it might be a good idea to simply give up using blue for non-link section headings. Ben -- I changed my name: <http://periodic-kingdom.org/People/NameChange.php>
Beth Jacobson writes:
It looks good! Unfortunately, the page doesn't behave very well when you display it in a small browser window. In my case, half the navigation isn't visible without having to scroll. The original Boost page doesn't have that problem. Also, when you display the page with lynx(1), the new version has the navigation coming _after_ the text, at the bottom of the page (which is bad), whereas on the current Boost pages the navigation is shown at the top. I suspect other text-only browsers will have the same problem. Peter
Peter Simons wrote:
Beth Jacobson writes:
It looks good! Unfortunately, the page doesn't behave very well when you display it in a small browser window. In my case, half the navigation isn't visible without having to scroll. The original Boost page doesn't have that problem.
Also, when you display the page with lynx(1), the new version has the navigation coming _after_ the text, at the bottom of the page (which is bad), whereas on the current Boost pages the navigation is shown at the top. I suspect other text-only browsers will have the same problem.
I was going to wait and see what the consensus was on the menu size, but this seems like a deal breaker, so I've shrunk them back down. (I assume that will fix it.) I also made the links slightly darker as Rob suggested. I'm not entirely satisfied with the resulting appearence, though. If someone could suggest a color that's dark enough to be easily readable but works better with the color scheme, I'll give it a try.
Beth Jacobson wrote:
I also made the links slightly darker as Rob suggested. I'm not entirely satisfied with the resulting appearence, though. If someone could suggest a color that's dark enough to be easily readable but works better with the color scheme, I'll give it a try.
When the same issues came up during the design, many months ago, I went trough many, more than 30, variations to try and find that color you are searching for now. I ended up with the current design where using color for links just gets in the way of readability, regardless of color. Hence why it's using underlines, and leaving the text color uniform. Unless the link status can be seen from the context as it is on the sidebar menus, where everything is a link and therefore don't have underlines. Just an FYI ;-) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
Rene Rivera wrote:
When the same issues came up during the design, many months ago, I went trough many, more than 30, variations to try and find that color you are searching for now. I ended up with the current design where using color for links just gets in the way of readability, regardless of color. Hence why it's using underlines, and leaving the text color uniform. Unless the link status can be seen from the context as it is on the sidebar menus, where everything is a link and therefore don't have underlines.
A general accessibility guideline is that you shouldn't rely only on colour to indicate links, because it'll cause problems for the colour blind. So this seems the right way to go. http://diveintoaccessibility.org/day_12_using_color_safely.html Daniel
Rene Rivera wrote:
When the same issues came up during the design, many months ago, I went trough many, more than 30, variations to try and find that color you are searching for now. I ended up with the current design where using color for links just gets in the way of readability, regardless of color. Hence why it's using underlines, and leaving the text color uniform. Unless the link status can be seen from the context as it is on the sidebar menus, where everything is a link and therefore don't have underlines.
I was afraid of that. Still, as much as I hate messing up your attractive design (and I really do - I can imagine how much work it must have taken to make it look that good), I'm convinced the usability issue is big enough to justify the change. Black text with blue underline just doesn't say "link", and when I first saw the page I didn't even realize the menus were menus. I assumed that they were some sort of informational text. I'm hoping my changes have made these things a lot clearer without seriously harming the aesthetics.
Beth Jacobson wrote:
I'm convinced the usability issue is big enough to justify the change.
Usability is *very* subjective aspect. Your version is for you more usable. But for others, like the visually impaired it's likely not more usable, as Daniel pointed out. Thanks Daniel for that link, I've looked for a long time for a way to test color blindness usability.
Black text with blue underline just doesn't say "link", and when I first saw the page I didn't even realize the menus were menus.
Yet, link underlines are the default for many browsers and hence mean 'link' to much of the web population.
I assumed that they were some sort of informational text.
Very likely because of your preference for color indicators.
I'm hoping my changes have made these things a lot clearer without seriously harming the aesthetics.
I'm fairly picky about typography and visual composition; my friends would say that's an understatement. So from my POV it's not an improvement. I used to prefer colored links as you have them but for the last few years I've realized that the colors break up the visual structure of text more than I can tolerate. This change for me is likely because of the increased amount of online reading, as opposed to book reading, that I currently engage in. Hence my conclusion has been that for text heavy content colored links are intrusive to reading and comprehension. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Rene Rivera
I'm convinced the usability issue is big enough to justify the change.
Usability is *very* subjective aspect. Your version is for you more usable. But for others, like the visually impaired it's likely not more usable, as Daniel pointed out. Thanks Daniel for that link, I've looked for a long time for a way to test color blindness usability.
BTW, I'm color blind such that nearly all images that I test on the Deuteranope simulation at Vischeck look identical to the original image. For what its worth, just about any of the web page attempts so far look fine, and I think people might be making the color issue more of a usability issue than it actually is. I don't know if it is even possible to come up with a color scheme that looks good to both people with normal vision and people with severe blue-yellow deficiencies at the same time unless the color scheme is grayscale.
From my point of view, differences in brightness are the most distinguishing elements, and I tend to prefer grayscale color schemes because there is less distraction caused by hue. But that's only a preference; it is rarely difficult (to a significant degree) to navigate web pages or find links. Obviously, there are people with a much greater degree of color blindness than me, but the majority (by far) of color blind people don't have significant trouble with stuff like this.
Regards, Paul Mensonides
From: Beth Jacobson <bethj@bajac.com>
I was going to wait and see what the consensus was on the menu size, but this seems like a deal breaker, so I've shrunk them back down. (I assume that will fix it.) I also made the links slightly darker as Rob suggested. I'm not entirely satisfied with the resulting appearence, though. If someone could suggest a color that's dark enough to be easily readable but works better with the color scheme, I'll give it a try.
The unvisited color looks quite good; if it were any darker it would blend in too easily. The visited color is still too light for my tastes. I'm not sure what to suggest. There are only shades of the blue and of black/white to play with in the color scheme, so it isn't clear there's another color to choose. Lacking a different color, perhaps you could play with the face or other font attribute for visited/unvisited links. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Beth Jacobson writes:
Peter Simons wrote:
Beth Jacobson writes:
It looks good! Unfortunately, the page doesn't behave very well when you display it in a small browser window. In my case, half the navigation isn't visible without having to scroll. The original Boost page doesn't have that problem.
Also, when you display the page with lynx(1), the new version has the navigation coming _after_ the text, at the bottom of the page (which is bad), whereas on the current Boost pages the navigation is shown at the top. I suspect other text-only browsers will have the same problem.
I was going to wait and see what the consensus was on the menu size, but this seems like a deal breaker, so I've shrunk them back down.
FWIW, I thought the larger menu text was an improvement.
(I assume that will fix it.) I also made the links slightly darker as Rob suggested. I'm not entirely satisfied with the resulting appearence, though.
They are blending with the text now, which is IMO a step back. -- Aleksey Gurtovoy MetaCommunications Engineering
From: Aleksey Gurtovoy <agurtovoy@meta-comm.com>
Beth Jacobson writes:
(I assume that will fix it.) I also made the links slightly darker as Rob suggested. I'm not entirely satisfied with the resulting appearence, though.
They are blending with the text now, which is IMO a step back.
They are more readable, however, and I find them sufficiently distinguished from the surrounding text. I can scan the page and easily spot the links. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Rob Stewart wrote:
From: Aleksey Gurtovoy <agurtovoy@meta-comm.com>
They are blending with the text now, which is IMO a step back.
They are more readable, however, and I find them sufficiently distinguished from the surrounding text.
I just changed the link colors to their websafe versions. I can't see any difference on my browser, but it may make things more consistent across different browsers/OS's. It could be that you've been seeing different colors. Hopefully this will fix that.
From: Beth Jacobson <bethj@bajac.com>
Rob Stewart wrote:
From: Aleksey Gurtovoy <agurtovoy@meta-comm.com>
They are blending with the text now, which is IMO a step back.
They are more readable, however, and I find them sufficiently distinguished from the surrounding text.
I just changed the link colors to their websafe versions. I can't see any difference on my browser, but it may make things more consistent across different browsers/OS's. It could be that you've been seeing different colors. Hopefully this will fix that.
No difference for me. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Beth Jacobson writes:
Unfortunately, the page doesn't behave very well when you display it in a small browser window.
I was going to wait and see what the consensus was on the menu size, but this seems like a deal breaker, so I've shrunk them back down.
The problem is not the size of the menu, it is the fact that the page doesn't _scale_. I haven't looked at the HTML source code, but apparently the page requires a certain window width, and if the window doesn't have that, text will be missing. In my case, half the navigation is invisible in favor of about 2 centimeters of white space on the left margin. I really don't think that's optimal.
When you display the page with lynx(1), the new version has the navigation coming _after_ the text, at the bottom of the page (which is bad) [...].
I assume [the smaller fonts] will fix it.
No, they haven't. The problem is that the menu is on the _right_ hand-side now, a text-based browser will display the left column before the right, hence the navigation ends up being the last thing on the page. Which is not optimal. Peter
Peter Simons wrote:
Also, when you display the page with lynx(1), the new version has the navigation coming _after_ the text, at the bottom of the page (which is bad), whereas on the current Boost pages the navigation is shown at the top. I suspect other text-only browsers will have the same problem.
The ordering of the menu after the text is intentional. It is designed to put the more important textual content first to prevent from being presented with a long navigation menu at the top. And hence not have to paginate down to get to the text. Why do you think it "is bad" ? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
Rene Rivera writes:
The ordering of the menu after the text is intentional.
Well, on http://boost.org/ this is _not_ the case; the original page has the introduction text following the navigation when viewed with a text-based browser.
[Hence the readers do] not have to paginate down to get to the text. Why do you think it "is bad" ?
Because the readers have to paginate down to get to the navigation, which they'll probably access more frequently than the text. Peter
Peter Simons wrote:
Rene Rivera writes:
The ordering of the menu after the text is intentional.
Well, on http://boost.org/ this is _not_ the case; the original page has the introduction text following the navigation when viewed with a text-based browser.
Yes, I know ;-) The change to text-nav order was intentional is all I said.
[Hence the readers do] not have to paginate down to get to the text. Why do you think it "is bad" ?
Because the readers have to paginate down to get to the navigation, which they'll probably access more frequently than the text.
But again this is a disagreement of who the audience is. Newby visitors are better served by having text to read telling them where they are than by a bunch of links. And yes this is a shift in Boost public image we need. More, and more new users visit the Boost pages. And more and more they are put off by the "expert" look and feel of the pages. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
Beth Jacobson writes:
David Abrahams wrote:
Beth, your proposals sound interesting... but they'd be a whole lot easier to evaluate if you'd just make up the page or CSS stuff required and post it where we can all get a look at it.
Done. The test page is up at http://bajac.com/boost/
Could we please, please get this rolled in 1.33? IMO this is a huge improvement in terms of the page readability. -- Aleksey Gurtovoy MetaCommunications Engineering
Aleksey Gurtovoy wrote:
Beth Jacobson writes:
David Abrahams wrote:
Beth, your proposals sound interesting... but they'd be a whole lot easier to evaluate if you'd just make up the page or CSS stuff required and post it where we can all get a look at it.
Done. The test page is up at http://bajac.com/boost/
Could we please, please get this rolled in 1.33? IMO this is a huge improvement in terms of the page readability.
That's also my opinion (I did like some tiny details of the old page better but that could be taken care of for 1.34). Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.
Beth Jacobson <bethj@bajac.com> writes:
Done. The test page is up at http://bajac.com/boost/
Works for me!
I made a few additional changes, most notably increasing the menu text
What is menu text?
size which meant there was no longer room for the mouseover pointer image, and I had to shorten "Boost General Interest" to "General Interest" (under "Groups").
Still says "Boost General Interest" AFAICT.
If either of these are a problem I could shrink the text back down and put them back.
I like your proposed change to the text on its own merits.
I wanted to make the text size large enough so the similarity between text links and menu links would be unmistakable, but maybe the color alone would be enough.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Beth Jacobson wrote:
Done. The test page is up at http://bajac.com/boost/
I believe your attempts complement Rene's work well.
I went for subtle but clear. Hopefully people on various OS's and browsers can tell me if I succeeded.
Colors and what not are in my (subjective) opinion done well. Really well. Where I had issue, was with the "Updated Libraries" section. As I can see, there are two pertinent issues here, namely: 1. When I first looked here ("Updated Libraries"), the first thing I asked myself was why the text was column-ated (is that a word?) to the left, and not running across the entire page width; as it might aide readability. This is really not so important, especially if the next point is taken to task... 2. Take for example the "Graph Library" in the "Updated Libraries" section: a whole series of points are made sumarizing much of the capability, but in its condensed form, makes very hard to distinguish each point. The solution here as I see it is either bullet points of some description (which is not the best of options to be honest), or alternatively, and much better, is a little, and just a little space between each of the summary points made. Other than that, I thank you and Rene on a job well done. -It really looks great and does well in projecting a professional image of Boost. Cheers, -- Manfred Doudar Metocean Engineers www.metoceanengineers.com
Manfred Doudar wrote:
2. Take for example the "Graph Library" in the "Updated Libraries" section: a whole series of points are made sumarizing much of the capability, but in its condensed form, makes very hard to distinguish each point.
That's my fault. In copying the webpage, I neglected to include the bullet gif Rene created. It's fixed now.
Just one man's opinion - I think the web page looks pretty nice. Clean, professional and slightly understated. Very much in line with my self image as a dedicated booster. I do have one beef though. In the section "updated libraries", mention of the improvements to the serialization system don't appear. I checked these in a long time ago to the main web page in the developer CVS and didn't think anything else was necessary. What do I have to do get this in here. Robert Ramey Marcin Kalicinski wrote:
Hi all,
I know gazillion words have been said on the looks of the new webpage, but still I want to add my 2 pennies. Briefly, I think that links in the text look very ugly and... amateurish? If you insist on having them underlined I suggest you stick with more standard look, such as on OpenOffice.org webpage (and many others). This looks much more professional. Additionally, I'd rather have links in boxes on the right have the same style as links in the text.
cheers, Marcin
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Robert Ramey wrote:
Just one man's opinion - I think the web page looks pretty nice. Clean, professional and slightly understated. Very much in line with my self image as a dedicated booster.
If I haven't said it before. To all Boosters: Thank you for all the feedback of all forms :-)
I do have one beef though. In the section "updated libraries", mention of the improvements to the serialization system don't appear. I checked these in a long time ago to the main web page in the developer CVS and didn't think anything else was necessary. What do I have to do get this in here.
Do you know which version it was? So I can go put them in. I don't see it on the branch version nor the mirror: <http://boost-consulting.com/boost/>. So it must have gotten overwritten. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
Rene Rivera wrote:
Robert Ramey wrote:
I do have one beef though. In the section "updated libraries", mention of the improvements to the serialization system don't appear. I checked these in a long time ago to the main web page in the developer CVS and didn't think anything else was necessary. What do I have to do get this in here.
Do you know which version it was? So I can go put them in. I don't see it on the branch version nor the mirror: <http://boost-consulting.com/boost/>. So it must have gotten overwritten.
I looked at the rather long history of boost-root/index.htm and the last change you did was on version 1.175 more than a year ago on July 22, 2004 <http://cvs.sourceforge.net/viewcvs.py/boost/boost/index.htm?rev=1.175&view=markup>. So you must have forgotten to put those changes in. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
So it would seem. I updated my local copy and used cvs update of my whole boost tree from time to time. The problem is that this process takes so long and has so many messages that they scroll of the top of my screen so I never noticed that there was a difference between my local page and the main page. Robert Ramey \> I looked at the rather long history of boost-root/index.htm and the
last change you did was on version 1.175 more than a year ago on July 22, 2004 <http://cvs.sourceforge.net/viewcvs.py/boost/boost/index.htm?rev=1.175&view=markup>.
So you must have forgotten to put those changes in.
participants (21)
-
Aleksey Gurtovoy -
Andreas Huber -
Andrey Melnikov -
Ben Artin -
Beth Jacobson -
Daniel James -
David Abrahams -
Fabio Fracassi -
Jeff Garland -
Jeremy Maitin-Shepard -
Jody Hagins -
Manfred Doudar -
Marcin Kalicinski -
Martin Wille -
Paul Mensonides -
Pavel Vozenilek -
Peter Simons -
Rene Rivera -
Rob Stewart -
Robert Ramey -
Sam Partington