Netscape DevEdge Redesign

Not bad ... but not great

Submitted by brothercake on February 13, 2003 - 10:08.

Although it's substantially better than before, it still looks pretty rough around the edges to me. The text-resizing doesn't work without javascript, which makes it little better than a gimmick. They should be using scaleable fonts, and could have done a lot better with user styles - offered true customisation for accessibility, instead of just a handful of aesthetic presets. And those dropdown menus are pretty limited in their browser support. But links which print out the whole URL - now that is cool.

login or register to post comments

3 points

Submitted by Xanadu on February 14, 2003 - 05:13.

Three points:

1. The alternative styles are slow to change. This is due to the graphic loading as well. (Even when cached, it seems to require reloading.) Nor do they change the rest of the page much.
    
2. The dropdown menus are cool, but they are too close together. The W3C Accessibility Guidelines tells us to separate links with a symbol (such as a line or dot) to make them clearer.
    
3. The links don't print out the URL in IE6. My guess is they're using the CSS command :after to generate the URL - I've seen it published somewhere. Great idea, but it only works in two or more very new browsers, and not IE! A better idea might be to add the URL in a div after each link, then make it {display:none;} in all stylesheets except for the print one. It's an idea I had this week for our site at work, and I might try it out soon.

login or register to post comments

it works!

Submitted by Xanadu on February 14, 2003 - 08:26.

Just tested the following code in IE6 and Opera 7 on WIndows 98, and it works! Put this after each link, copying the URL into the brackets:

<nolayer><div id="url"> (http://www....com)</div></nolayer>

Then set up your stylesheets so they all have the line #url {display:none;} in them - this prevents the URL from being seen. Go to your printer stylesheet though, and put in the line #url {display:inline;} instead. When you now print the page, it should show the URL after each link!

Why do I use <nolayer> you ask? Because Netscape 4 doesn't recognise #url {display:none;}, so it would show the URL text on screen. You can hide anything from Netscape 4 this way.

login or register to post comments

Choices

Submitted by emeyer on February 14, 2003 - 10:06.

I thought I'd share a few brief thoughts on some of our design choices in the hopes of answering the points commenters have raised.

• Font sizing/test-resize gimmick-- unfortunately, there are no good choices for sizing fonts on the Web. Even leaving the size totally alone isn't a good choice. We decided to use pixel-sized text because most browsers have text zoom functions that override any text sizing. Since the exception is IE/Win, we needed the gimmick, but it's one we felt we had to provide in order not to leave IE/Win users without any options at all. One can argue this shows we made a bad choice, but one can also argue this shows that browsers (ALL browsers) still have some way to go in terms of accessibility.
• "Theme" choices-- yeah, we could have done more in terms of different layouts, and I wanted to do so. But since this redesign effort went from zero to done in less than two months, including a complete reworking of our data structures in the backend and dramatic changes to the way we build the site, we had to settle for variations. Radical restyling just wasn't something high enough on the priority list. We hope to add more varied themes and powerful customization features down the road.
• "Theme" reloading-- only IE/Win does this, because we had to script our way around problems in its behavior. In our original RC build, when you switched the theme, the masthead's background wouldn't appear. The only way around it was to force the browser to reload the page. Other browsers don't have the same problem, so they don't need the reload hack.
• Navbar links too close together-- IE/Win bugs in inline layout are to blame for that. We're thinking about lightening up the borders between the links for visual reasons. There isn't an accessibility issue there, because in the unstyled view those links are an unordered list. Thus no symbol or separator is needed; the separation is already built into the structure.
• Printed link URLs-- yes, that uses generated content; and no, IE doesn't support it. When IE is updated to support generated content, then its users will get the benefit. In the meantime, they're missing out on a minor (cool) feature, but it's nothing that prevents them from making use of the site. We can't use a solution like nolayer because it will prevent validation.

Thanks for the comments!

login or register to post comments

Moving Foward

Submitted by shifter on February 14, 2003 - 10:39.

These are features that add to the user experience; style, printed links, spiffy menu; they are additional, they do not take away from the content only add to it. What reason are we giving users to upgrade if we continously kneel down to service their outdated browser needs. If they aren't missing out the content, that is sufficient. We need to think twice when we start to worry about NN4 and old IE. They are long gone, whether half our visitors use them or not. If we do our job right (valid) and our content is accessible to all, we have done our job.

Eric Meyer and the DevEdge team have done that and they are rewarding those of us who surf with an up-to-date browser, with features such as optional style, nifty menu, so on and so forth.

login or register to post comments

Very good points ...

Submitted by brothercake on February 14, 2003 - 11:36.

.. and my apologies if my initial remarks were a bit scathing - I am generally impressed with what's been acheived.

My critisism was rooted in the way the user-style and font control is presented as an accessibility feature, when very little accessibility benefit is gained - for example, why is one of the options not light text on a dark background, or dark text on a tinted background (many people find a tinted background much easier to read against than white).

That IE doesn't resize pixel text might be a bug ... but that really is irrelevant. Sure, it's counter-productive to concede to netscape 4 and ie4, but not to ie5 and ie6 - these are the majority browsers, however buggy they are; you can't ignore something so fundamental, especially when you flag what you've done as a good example to others.

As it goes - I find % font-size pretty reliable - consistent between ie5/6 and mozilla, at any rate, and only marginally smaller in Opera.

login or register to post comments

Re: it works!

Submitted by kirkaracha on February 14, 2003 - 11:44.

Classes would probably be better to use than DIVs, since you're likely to have more than one URL on a page.

Netscape 4 does support display: none.

I have this HTML (excerpt):

<p>We'll put the swamp here:</p>

<div class="url"><a href="#">www.here.com</a></div>

In testNS4.css:

.url {display: none;};

In testCSS2.css (using @import):

.url {display: block;};

The .url DIV does not appear in Netscape 4, and does in IE 5.5.

login or register to post comments

in reply

Submitted by Xanadu on February 15, 2003 - 14:42.

My apologies, I assumed from past experience that NS4 didn't support {display:none;}. If it does, that means you don't need the <nolayer> tags, so Eric Meyer can have the pages validate!

Since the majority of surfers use IE, I'd have thought it prudent to make sure things like printable URLs work in that browser, and as a luxury, Mozilla and Opera, etc. But then we're talking about the Netscape DevEdge site here! :-)

Kirkaracha - "Classes would probably be better to use than DIVs, since you're likely to have more than one URL on a page.".
It doesn't matter how many divs you have, they can all reference the same CSS. Or is that breaking any rules? The main reason I don't use classes is that I once had a page with several divs on that would fail to display one of them properly. After much testing and frustration, I eventually concluded that I had too many classes on the page. Sounds crazy? Well I replaced them all with "id"s instead, and the page then worked. So now I avoid divs with classes.

Also, I would replace your class in testCSS2.css with .url {display:inline;}; as this helps to keep the printed URL with the surrounding text.

Eric - "Navbar links too close together-- IE/Win bugs in inline layout are to blame for that. We're thinking about lightening up the borders between the links for visual reasons.".
No, the links are too close on all the browsers I looked at the site in. It looks like a sentence of words, rather than a set of links. However, only later did I notice the black borders inbetween them! On my screen, you can barely see them due to the dark blue background. All you need to do is add some padding at the left and right to space the links out.

One last thing. The Print Preview in Opera 7 on Windows 98 gives me a first page that's completely blank! The second page has the text, but no borders! You might want to look into that. Could be a browser bug or the code needs tweaking.

login or register to post comments

re: in reply

Submitted by kirkaracha on February 18, 2003 - 15:02.

It doesn't matter how many divs you have, they can all reference the same CSS.

Sorry, I meant "classes would probably be better to use than IDs," not DIVs. Too much coffee...or not enough?

login or register to post comments

probably the wrong place to ask - but...

Submitted by technophobe on February 24, 2003 - 08:00.

does anyone have a clue why http://developer.netscape.com/ appears as Japanese in my IE6 on XP?
yes i do have japanese language support installed, but it doesn't happen on other sites, nor on devedge in other browsers...
...btw i can't read japanese :)

login or register to post comments

"id"s instead of classes

Submitted by tekai on March 13, 2003 - 07:17.

Xanadu: Well I replaced them all with "id"s instead, and the page then worked.

generally thats a bad idea, afaik it even violates xhtml standard as the id must be unique for the whole document and things like document.getElementById(id) and <label for="id"> shouldn't work anymore.

login or register to post comments

you got me wrong

Submitted by Xanadu on March 13, 2003 - 11:54.

No, the id's were all different! So I was in full compliance. You see, I was daft enough before to create a separate unique class for each div. That idea should still have worked trouble free though?

login or register to post comments