November 28, 2002, 1:11 AM ET
The Case of the Mysterious Date
I've touched on this phenomenon before, but it's worth discussing in depth. Simply put, a number of news/information sites display ambiguous dates on their story pages without designating (either visually or explicitly) whether they're publication dates or the current date. This practice is confusing, misleading -- and easily avoidable.
I've given this a little thought and have divided sites into four groups:
- Group 1: Those that display only one date and make clear what that date means. (Good)
- Group 2: Those that display only one date but do not make clear what it means. (Bad)
- Group 3: Those that display two dates but make clear how they differ. (OK, but potentially confusing)
- Group 4: Those that display two dates but do not make clear how they differ. (Horrible)
Let's take these one at a time.
Group 1
Many news sites keep it simple by displaying only a single date -- the date of story publication -- and placing it in the content area to give users a visual clue that the date is intrinsically related to the story. Good examples: arizonarepublic.com, which places the date just below a story's byline, and seattlepi.com, which places it slightly above a story's headline.
The key on these sites is the visual relationship between the date and the rest of the content. For example, there's no need to preface the date with "Date posted: " if the date appears just below the byline; in that case, it's obvious the date refers to the publication date.
Group 2
A problem arises when a news site displays a single date but doesn't identify it.
The New York Times' site offers a fine example. On its story pages (sample page), a date appears in the upper-right corner -- located far enough from the content that you might stop and think, "Is that today's date, or the date this article was published?"
In the Times' case, it's the date the article was published. But I only know that because I clicked around the site and observed the dates change. Because the date is so far removed from the content area (the light purple search bar stands between them), they're not visually tied, as the Group 1 examples were. The Times would do well to label this with "Posted:" or "Publication date:", whichever is more appropriate.
At the other end of the spectrum is irelandonsunday.com, which displays the exact current time -- yes, including seconds -- in the upper-right corner of its story pages. (This feature requires JavaScript.) Just like nytimes.com, the date is not labeled. How do we know what this date represents?
Group 3
Introducing a second date into the picture makes things more confusing, but some sites manage to pull it off with minimal confusion.
North Carolina's Sanford Herald displays today's date and the article's publication date, using placement to distinguish the two. (Note that there's still a chance a reader might mistake the former for the latter.)
The Hollywood Reporter gets a little sketchier, displaying the current date near the logo but prominently displaying the article's publication date below the headline to clear up confusion.
Likewise, benicianews.com displays the current date in the upper-right corner but displays the publication date just above the headline. And cjonline.com displays today's date in the upper-right corner while showing an article's last-modified date just below the headline.
Group 4
The most confusing way to present dates is to display two of them with no apparent distinction. You might particularly be inclined to double-take a story such as this one on nytimes.com, which displays one date ("PHOENIX, Nov. 27") in the article body and a second ("November 28, 2002") at top right. Which one's correct? Journalists will tell you that "PHOENIX, Nov. 27" is a newspaper convention called a "dateline" -- a short snippet giving the reporter's location, if not local, and the date -- but, convention or not, having two ambiguous dates on the same page is confusing.
Similarly, The Indian Express shows two different dates on story pages, as does heraldonline.com.
The solution
It's easy to make dates make sense: Identify them.
A label works well. The Belfast Telegraph uses the label "Publication Date:". Savannahmorningnews.com uses "Web posted". Greenvilleonline.com uses "Posted". On these sites, the meaning of dates is unambiguous -- which is the way it should be.
Giving the date is crucial in presenting the news; without a clear disclosure of the date, a news article is useless.
November 25, 2002, 7:38 PM ET
A career move
Updates to this site have been lighter than usual lately because I've been busy making career decisions and moving preparations.
I've resigned from my job at the Atlanta Journal-Consitution and have accepted a position as lead developer at the Lawrence Journal-World in Kansas. I'll be working with Rob Curley and his outstanding Web team, who have been known in the industry to push the envelope of online journalism.
With that, and a looming deadline for a secret side project I've been involved in, my blogging time has been cut short. I apologize for that.
November 22, 2002, 12:17 PM ET
Recommended reading
Economist.com design director David Wertheimer shed light on his site's redesign process in a recent book, "Usability: the Site Speaks for Itself." Now, Digital Web Magazine has published excerpts from the book. I've wanted to get the book for a while; reading this whetted my appetite more. (On a related note, Economist.com's innovative "subscriber sponsorship" has been the buzz lately.)
Danny Sullivan of Search Engine Watch declares keyword meta tags are dead.
Mark Pilgrim has made several technical innovations on his weblog, including a custom 404 script that enables URL-based shortcuts. (Here at Holovaty.com, I've had URL-based search functionality for a few months -- just type holovaty.com/search/[searchstring] in your browser's location bar.) He's also put together a "Recommended Reading" tool that, given your weblog's URL, suggests other sites you might like to read. It behooves publishers of online news sites to keep an eye on the early technological adapters in the weblog community.
November 21, 2002, 12:53 PM ET
'Intelligent' design personalization at bbc.co.uk
Matt Jones points out an innovative feature of the new bbc.co.uk home page: The background colors of the various sections change based on your browsing habits.
For example, this is how the "News" and "Sport" sections looked when I first visited the page:
Then, I clicked into the "News" section and repeated this process a few times, to "teach" it that I visit the News section often. When I went back to the home page, "News" was given a darker background color, giving it more prominence:
This is an outstanding idea -- and one I could see being applied to font sizes and positioning, as well. Kudos to the BBC for proving again it is an industry leader in adapting new technologies into its news and information sites (such as RSS feeds and accessibility measures).
I do see one problem, though, with the BBC's implementation of the dynamic background-color changes. Simply put, the home page, by default, already uses quite a few different background colors. So it's hard to tell whether the background color for a particular section is in a darker shade of blue because of personalization, or because of the site designers' judgment. Granted, they're probably still experimenting with this feature, but if they're serious about it, they should make all default background colors the same.
November 19, 2002, 11:22 PM ET
One thing wrong with the Reuters redesign
Reuters, the news service, has redesigned its Web site. Its home page has abandoned subtlety and simplicity for an intense, overly designed busyness; it is a page in which many pieces shout.
The code is equally inflated. When I examined the home page, it had 112 spacer GIFs, 125 tables and flat-out indulgent class names such as class="bottomNavigationChannelsSmall". A measly 6.29 % of the home page's source code is actual text content, according to the GetContentSize utility.
Here is a particularly heinous example of the page's bloat:
<script>
if (document.all) {
document.write('<input class="headerSearchBox" name="ticker" type="text" size="7">');
}
else if (document.getElementById) {
document.write('<input class="headerSearchBox" name="ticker" type="text" size="12">');
}
else {
document.write('<input class="headerSearchBox" name="ticker" type="text" size="5">');
}
</script>
Some of you readers might recognize (and laugh maniacally at) the problem and ill-conceived solution here. For the others, first a little background...
Browser quirks make it difficult to control precisely the width of text fields (input type="text" -- an example of which is this page's search form). The input tag, which defines a text field, allows for the size attribute, but browsers' varying default font settings interpret size differently. Most notably, Netscape 4's default is to format text fields in a wide fixed-width font, which means a form field with a size="12" will look substantially longer in Netscape 4 than in other browsers -- and, hence, messing up sophisticated layouts.
That said, we return to the Reuters code. For the JavaScript-uninitiated, if (document.all) is often used as a shortcut method for determining whether the user's browser is a recent version of Internet Explorer or Opera. (document.all is a piece of functionality that works in those browsers and not in others.) Likewise, if (document.getElementById) is widely used to test for browsers that adhere to the DOM, such as Netscape 6+ and Mozilla.
What we have here, then, is basically a browser-sniffing script that outputs a hard-coded size on an input tag based on the browser.
This is poor in practice, wasteful and flat-out silly.
A much easier method would be to use a simple style declaration in a CSS file. To accomodate for the lowest common denominator (Netscape 4), set the size as small as needed so as not to blow-out the layout:
<input class="headerSearchBox" name="ticker" type="text" size="5">
Then, set the text field's width in a style sheet, like so:
input.headerSearchbox { width: 80px; }
The style sheet width declaration will overrule the size="5" in all browsers that support this basic CSS property, and Netscape 4 will happily buzz along with its size="5". This has the added bonus of pixel precision, and it doesn't require JavaScript for the form fields to show up on the page.
November 18, 2002, 12:26 PM ET
Recommended reading
Nathan Ashby-Kuhlman tackles "click here" text and the wording of online polls.
A new evolt.org article gives "courtesy titles and webform design recommendations."
In an interview with Digital Web Magazine, usability guru Jakob Nielsen shares his thoughts on a few news sites:
I also like the redesigned homepage CNN introduced about a year ago, with more of a focus on the top stories and a scannable list of smaller stories. For mobile access on a small PDA screen, MSNBC has better usability, though.
And another usability expert, Steve Krug, says good things about The New York Times Associated Press news headlines page:
There are lots of sites where you can see the latest AP stories, but I like the Times' page because the way it's formatted makes it very easy for me to scan it in a hurry.
November 18, 2002, 12:12 PM ET
Poynter.org redesign woes
Poynter.org, the site of the Poynter Institute (a journalism think-tank and training facility) and home of the E-Media Tidbits and Romenesko's MediaNews weblogs, redesigned Friday -- and was met with a flood of discontent. More than 70 readers posted negative remarks on the new MediaNews comment system, and a number of Tidbits readers did the same.
A few features of the redesign...
Poor URL scheme. Smart, friendly URLs such as "poynter.org/medianews" and "poynter.org/tidbits" have been eschewed for anonymous, stale addresses such as "poynter.org/column.asp?id=45". Two things immediately wrong with this scheme:
- They're ASP-dependent. If Poynter decides to change its back-end system to, say, PHP, every URL will change, resulting in hundreds of broken links. (Granted, this can be remedied with URL-rewriting methods such as mod_rewrite, but that's a messy hack.)
- They're unfriendly and unhelpful. What tells you more, poynter.org/column.asp?id=45 or poynter.org/medianews? I find it particularly difficult to navigate the site now, because I was accustomed to using URLs as UI.
QuickLinks. Almost every page has a unique QuickLink code -- e.g., "A9035". "You can use these codes however you like," the site explains. "Jot them down as a quick reference; e-mail them to colleagues; or use them as a fast way to link to Poynter Online content." It's an interesting idea, but I doubt people will use it, because it offers no clear advantage over bookmarking a page or e-mailing the full URL. (The URLs aren't so long that they'd wrap across lines in an e-mail program.)
Chunky code. Spotted on MediaNews:
<font face="Trebuchet MS"><font size=2><font size=3><a class="" href="mailto:medianews@poynter.org">
I did not make that up.
There's no acceptable reason, in the year 2002, for a site to be using font tags. Not to mention redundant, nested, font tags.
Unusable comment system. Reading comments is an incredible hassle. Try it. From a comments list page, you've got to click into a comment separately, then click back to the list page, then click into another comment. Not to mention you're supposed to click the overly subtle binoculars graphic, not the commenter's name.
November 14, 2002, 12:11 AM ET
GetContentSize changed slightly
Some comments here, some comments on Webgraphics and various e-mails have convinced me to alter my GetContentSize tool a bit.
The tool measures the percent of a single HTML document -- not including any attached images or supplementary files -- devoted to what I call "text content." Text content is everything content-related that the user is able to view. (Or, in the case of blind users, all content a screen reader can access.) HTML code, in and of itself, is not text content. The sentence you're reading right now, however, is.
When I launched the tool last week, it calculated the text content by stripping away all HTML tags in a given document and calculating the ratio of the number of remaining characters to the number of characters in the first place. A problem, some pointed out, is that this didn't account for content embedded in HTML tags -- particularly alt attributes (text meant to describe/replace images) and title attributes (supplementary descriptive information often coded into links, acronyms, etc., and traditionally accessible via browser tooltips).
That's changed.
The tool now includes all contents of every title, alt and summary attribute. That's definitely text content, and it deserves to be counted as such.
(The seldom-used summary attribute, by the way, is supposed to be used to describe data tables. Not many people use it, but I figured I'd include it.)
I have a feeling this will increase the content-to-code ratios for many blogs, as many bloggers tend to use the title attribute liberally, but it probably won't affect other sites' ratios much.
November 13, 2002, 11:19 PM ET
Two DOM ideas
In an evolt.org article posted earlier today, Peter-Paul Koch advocates using the W3C-sanctioned Document Object Model (DOM) in new, innovative ways in order to empower users to create their own interfaces to Web sites:
Basically, since the W3C DOM allows us to completely rewrite the page according to the wishes of the user, we should design web pages in a new way. We no longer need to take serious decisions about how the site will work, how the navigation, the forms and the other elements interact with the users. Instead, we can offer the user a way to create his/her own web page, with exactly those elements and that interaction he/she wants, likes or needs. Thus one web page can look completely different for two users.
Koch presents a DOM-driven example page -- an item-entry form that replicates itself infinitely, based on how many items the user wants to add. He also cites the International Herald Tribune's site as "the best practical implementation of the unique possibilities of the W3C DOM so far." (The IHT uses the DOM to give users limited control over how news articles look. For instance, users with DOM-compliant browsers may switch between a three-column view and a one-column view.)
Heeding Koch's advice to start thinking of good DOM uses, I have two ideas I'd like to see implemented on news/information sites:
- User comments within articles. Let people insert text anywhere in any story. This could be limited to a paragraph level -- i.e., user comments only appear between text paragraphs -- or, more radically, within text itself. (Any kind of comment would be acceptable: fact corrections, editing corrections, opinions, sarcastic remarks, you get the idea.) Importantly, make it easy to distinguish between "official" content and user-provided content. Make it easy to turn comments off and on. Give each comment a "type" -- "additional fact," "opinion," "correction" -- and enable users to show and hide the comments by type. (e.g., "Show me just the corrections, and no opinions." Or, "Show me just the witty remarks, not the sarcastic ones.") This would turn a single story into a multilayered experience, with different parts accessible via different clicks.
- User-manipulated stories. Let users reorder the facts in a hard news story. We journalists value highly our news judgment -- that is, we like to think we know which facts are more important than other facts -- but we shouldn't be elitist about it. Give the people a voice; let them call us on it, right on our site. (This ties in with recent comments about users "building their own internal narratives" over at Hypergene MediaBlog.) Log individual users' changes and manipulations, and present an alternative article, created on the fly, based on "collective user judgment." Do the same with the home page, but on a broader (story) level instead of a factual level.
November 12, 2002, 12:07 PM ET
Content-to-code ratio statistics
Thanks to everybody for the positive feedback on GetContentSize, which I presented Friday.
I logged the tool's results to a database, so I'm able to present a few interesting observations/statistics. (I've been away from my computer for a few days, so I apologize for not having this earlier.)
Total Web pages examined: 4,296
(Pages ranged from news sites to blogs to, yes, porn sites.)
Average percent text content: 21.57%
Highest percent text content: This page (86.57%)
Lowest percent text content: This page (.02%)
Average percent text content for URLs ending in ".com" or ".com/": 17.71%
(I figured this might be decent way to narrow down the results to commercial home pages.)
Average page size: 27,910 bytes
If there's another statistic you'd like to see, post a comment here, and I'll query the database to get it, as long as the statistic is obtainable by MySQL. The logged fields are: URL, page size (in bytes), percent content and the date/time.
November 7, 2002, 10:26 PM ET
The content-to-code ratio
Earlier today, Steve Outing of E-Media Tidbits wrote about "page bloat behind the scenes" -- the fact that many major news sites have incredibly bulky HTML under the hood. Then Barry Parr followed up, posting content-to-code ratios for six major news sites.
This topic intrigued me, so I threw together an application that calculates the ratio of text content to total page size for a given Web page. It'll strip all the HTML, JavaScript and CSS, and determine how much of the document is actual text.
I gave it the unsexy name GetContentSize, and I've put it online so everybody can play around with it, just for kicks. (All you fans of object-oriented PHP can also download the source code.)
GetContentSize will tell you, for example, that CNN.com's home page -- just the page itself, not any attached images, JavaScript classes or style sheets -- weighs 47,000 bytes but only devotes 8.70 percent of that to text content. (Really makes you wonder what the other 91.3 percent of the document accomplishes.)
Other interesting ratios:
- dallasnews.com -- 5.85%
- abcnews.com -- 5.94%
- news.bbc.co.uk/1/hi/uk/default.stm -- 7.54%
- chicagotribune.com -- 8.86%
- washingtonpost.com -- 9.70%
- nytimes.com -- 10.85%
- latimes.com -- 10.95%
- boston.com -- 14.70%
Not surprisingly, blogs outperformed news sites considerably -- probably because blogs tend to use CSS to separate content from code, and they're more text-driven than news-site home pages anyway. Some examples:
- dashes.com/anil/ -- 25.94%
- doc.weblogs.com -- 26.18%
- kottke.org -- 40.00%
- ashbykuhlman.net -- 44.63%
- holovaty.com -- 46.67%
- simon.incutio.com -- 46.93%
- hypergene.net/blog/ -- 59.03%
Of course, having a low ratio isn't horrible. HTML structure is important. And this tool doesn't account for photos (which are an important part of many sites' content) nor JavaScript-generated content. Still, I think something's wrong when less than 10 percent of a Web page's raw code is devoted to text content. Load time and rendering time remain important concerns.
UPDATE, Nov. 14, 12:14 AM: I've done a bit of follow-up analysis and have changed my methodology slightly.
November 6, 2002, 3:08 PM ET
Unfriendly Web design 'may be just fine'?
Business 2.0's "Who Needs a Pretty Website Anyway?" reports the ugly, cookie-cutter RealCities sites are profitable despite their much-criticized look:
KRD is proving that Web design that's unfriendly to users may be just fine, as long as it's friendly to advertisers and cheap to operate.
"Web design that's unfriendly to users" is not just fine. The logic is quite simple: If you annoy users enough, they won't come back to your site -- and not a single non-comatose advertiser will want to spend his or her money wooing your shrinking audience.
I'll also point out that any decent content-management system will allow for design customization while maintaining the ability to share content.
More comments on this topic are at E-Media Tidbits and Barry Parr's MediaSavvy.
November 5, 2002, 10:05 PM ET
Study links Web design with credibility
A new Stanford University study, "How Do People Evaluate a Web Site's Credibility?," concludes Web users are more likely to deem a Web site credible because of its design than because of its content.
That's right: In the majority of Web users' eyes, the credibility of the content itself isn't as important as the site's design. If a gossip-rag news site has a "professional," "higher-quality" or "pleasing" design, it could very well be looked upon as more credible than a more traditional newspaper site with, say, a bright orange, polka-dotted background.
Why? The study concludes it might have something to do with users' short attention spans and tendencies to click quickly without much thought:
If such rapid navigation is indeed the norm for most types of Web use, then it makes sense that Web users have developed efficient strategies, such as focusing on the Design Look, for evaluating whether a Web site is worthwhile.
Plus, it ties into psychology:
It's important to note that looking good is often interpreted as being good -- and being credible...This basic human processing bias -- "looking good is being good" -- also seems to hold true for evaluating the credibility of Web sites, especially since Design Look is highly noticeable.
Especially interesting is the study's analysis of news sites. It turns out users do not associate news sites' designs with credibility as much as they do with other types of sites, such as e-commerce sites. Still, 39.6 percent of the study's participants linked news site design with credibility; that's a significant number.
November 5, 2002, 11:41 AM ET
An announcement for RSS readers
To those of you who read this site via its RSS syndication feed, two things:
- I've cut the number of blog entries in the feed from 10 to 5, in the name of saving bandwidth. My thinking here is: If you'd like to read older entries, you know where to find them.
- Right now, each entry's
descriptionconsists of the entry's entire contents, in pure XHTML code. I'm considering changing this to be plain text of the first few sentences of the entry, or possibly a short synopsis. I hope this won't disrupt people's reading habits; please let me know if you're opposed to this change.
November 4, 2002, 1:14 PM ET
Drop caps at NYTimes.com
For some time now, NYTimes.com has been using single-letter images to create a drop-cap effect on article pages.
In this sample Times article, for example, the letter "M" is actually an image hard-coded into the article body.
This was a fine technique in, say, 1997. But these days, the NYT would do well to get with the times. See, there are two problems with presenting a drop-cap this way:
- Bandwidth -- Obviously, each image on a page adds to that page's weight. It can be argued that the tiny drop-cap images are negligible, but I'll point out that on a highly trafficked site such as nytimes.com, the bandwidth spent on sending one image to millions of users is nothing to sneeze at.
- Accessibility -- As pointed out in Joe Clark's "Building Accessible Websites" (which will be reviewed here soon), "[S]creen-reader users will be inconvenienced by the use of a drop cap. It simply breaks up a word." In other words, a screen reader will place a space between the drop cap and the remainder of the word. The example page above will be read aloud as "em edford mass" instead of "medford mass."
Instead of hard-coding images as drop-caps, a better technique is to use CSS to do all the formatting automatically, using the first-letter pseudo-element. Check out the about.com CSS drop-cap tutorial for more.
November 1, 2002, 4:42 PM ET
Separating photos and captions at ABCNEWS.com
Here's a strange way of presenting photos and photo captions on a news article page.
On ABCNEWS.com, wire story photos are displayed adjacent to headlines, but their captions are all the way at the foot of pages. Photos and captions are tied via an internal link.
Check out these examples:
- King Air Planes Are Charter Favorite
- Nicole Kidman Not Ready for New Relationship
- Jam Master Jay Created New Sound
On each of those pages, you don't see the caption of the lead photo until you either scroll down or click the photo credit (e.g. "AP photo"). There's a section titled "photo credit and caption" at the bottom of the page.
What the heck?
This does help keep the top of news story pages uncluttered, but I question whether moving caption information to the bottom of the page is throwing the baby out with the bathwater. Seems to me this is a workaround to a poorly thought-out design.
