adrian holovaty

August 7, 2002, 11:24 PM ET

Site review: Nzherald.co.nz

Farah Iqbal, the designer at The New Zealand Herald Online, told me that site changes are in the works and suggestions would be appreciated.

Let's all help out. I'll go first; others, feel free to post comments below.

• The first thing that comes to my attention is the large banner ad on many of the pages. It measures 760 by 120 pixels, and it's a whole lotta trouble. Not only is it distracting, it actually slowed my (relatively fast) computer down -- the MP3 playing at the time skipped, and there was a delay in scrolling down the page. This isn't a weblog for online business, so I don't care to debate the financial merits of such an ad, but I strongly urge that this monster be tamed. Having an ad slow down one's computer is annoying and might very well send users elsewhere. One suggestion: Make it a one-frame ad, not animated.
• Another disadvantage of the ad: Because it's so gigantic, I perceive it as an almost-integral design element of the page. For this reason, the pages that lack the giant ad threw me for a loop. Moving from giant-ad page to no-ad page can be very jarring. As I surfed the site's first few pages, my eyes learned to ignore the ad and begin scanning pages from about a third of the way down. But when I came upon a page that didn't have the ad, it was an uncomfortable change -- like having the rug pulled out from underneath me. Consistency in placement of page elements, including advertising when it's this big, is important.
• The far-right rail has a similar effect. Sometimes, it's used for vertical ads; at other times, it's used for sidebar information. I have a feeling many users ignore the sidebars because they're in (what users perceive to be) the ad rail. Advertising staffs can say all they want about forcing people to look at ads by placing them in editorial space, but I believe users make quick judgments about what is editorial vs. advertising space and learn to ignore the latter. I think it'd be a better idea to put related content within the content area, but I'd love to hear more opinions on this.
• Usability of the top-left drop-down menu can be increased by eliminating its JavaScript onchange event. Right now, when I choose a menu option, it immediately takes me to that page immediately, without my having to click "GO". It's great that the "GO" submit button is provided for non-JavaScript browsers, but in some cases (mainly, when using the keyboard to browse), it's impossible to make a choice other than the top link without being redirected. (See Accessible Scripting's informative explanation.)
• All fonts are set using absolute widths, making it impossible for Windows Internet Explorer users to resize them. (Although a workaround is given on the site's outstanding FAQ page.) Dive Into Accessibility has a great page on this topic, although its solution is a bit too much of a hack. My take on the matter: Use ems instead of pixels.
• As mentioned before on this site, it would be a good idea to use correct structural markup, such as H1 and H2 tags, for headlines, bylines, etc. Such markup gives text-only browsers a better idea of what kind of content they're displaying. (And that's just one of the advantages.) Also, I encourage heavier use of style sheets in order to separate design from content. Quick tip: The stylesheet's current font-family: arial, helvetica, sans-serif; font-size: 12px; line-height: 19px; font-weight: bold; can be combined into font: bold 12px/19px arial, helvetica, sans-serif, and color: #000066 can be shortened to color: #006. Might not look like a lot, but it saves a lot of bandwidth and cuts page load in the long run. (Here's a useful page on such CSS shortcuts.)
• It's always good to see breadcrumb navigation! (This is a topic previously mentioned here.) And section names in the left rail are highlighted according to the page you're on. As a result, the site is easily navigable, and that's commendable.
• The search form is featured very prominently, in the middle of the page and above the news content. It's obvious that making site search easy should be a high priority, but here, the form's dead-center placement almost regards search too highly. As a recent Digital-Web Magazine article explains, searching should be a last resort, not a default method for retrieving content. The key is making navigation prominent and usable. The search form should still be easy to find, just not this easy. For what it's worth, Jakob Nielsen has recommended search forms be in the upper right corner of a site -- sufficiently out of the way, but instantly apparent when users need them.
• Speaking of site search, what do the percentages next to the search results mean? (See a sample search.) The site's FAQ offers this: "[R]esults are ordered by the relevance of the story to your keyword." Yes, but how are the percentages calculated? They don't mean anything to me unless I know.

I hope that's helpful. Everybody, chime in with your own comments.

Comments (7) / Permalink

August 7, 2002, 12:21 PM ET

Lunchtime links

404 Research Lab -- History, examples and more.

typoGRAPHIC -- All about typography. "Hip" capitalization, too.

Webmonkey: Web Standards for Hard Times -- Why you shouldn't ignore Web standards.

E&P: NYT adds Google search -- A smart move.

Digital-Web: Building a semantic Web site -- A readable look at the future of CMSes.

Comments (1) / Permalink

August 7, 2002, 9:11 AM ET

Washingtonpost.com to ask for personal information

The Wall Street Journal reports washingtonpost.com will begin asking users for gender, year of birth and zip code, starting today. It'll be voluntary until Aug. 14, when users will be required to enter the information to access news stories, the article says. Information will be stored in a cookie.

It'll be interesting to see how they pull this off, especially from an accessibility standpoint. What about users who have disabled cookies in the interest of privacy? Clearly they'll have to enter the personal information every time. What about Lynx users? Lynx has the ability to accept and save cookies, but they're not stored between browser sessions.

UPDATE, 7:47 PM EST: Here are some more resources:

• Reuters article
• Washingtonpost.com press release

Comments (1) / Permalink