March 27, 2003, 3:13 AM ET
Guidelines for fair, accurate online candidate chats
Recently I've been involved in administering live online chats with candidates in local elections. The experience has given me a chance to think about how traditional journalistic values -- accuracy, fairness and accountability, to name a few -- are applied in such a nontraditional setting.
For the non-journalist readers in the crowd: When covering an election, a reputable news organization makes every effort to give each candidate fair play. In a newspaper, for instance, this means each candidate should get roughly the same amount of coverage, in the same section/page of the paper, with similarly sized photos and/or graphics. (This is the ideal goal, of course; most news organizations fall short of perfect fairness.)
Here, then, are those concepts of fairness translated into the relatively new world of online chat. Note that these are suggestions; it'd be nearly impossible to follow every guideline 100% precisely, due to any number of reasons -- from schedule conflicts to limitations on workload/manpower to human fallacy. Each guideline is derived from the basic principle that each candidate should be treated equally.
- Schedule chats during similar times of the day. A chat taking place at 9:30 a.m., near the typical news site's peak traffic point, will undoubtedly attract more participants (and more attention) than a chat held in the afternoon, when traffic tends to decline. Availability of chat transcripts can help to lessen this problem.
- For each candidate chat, give users an equal amount of time to presubmit questions. If Jack's chat is on Wednesday, Jill's chat is on Friday and the chats are announced on Tuesday, users have more time to submit questions for Jill's chat than for Jack's.
- Give each candidate the same amount of time to chat, or let each candidate chat as long as he or she wants, or allow each candidate as much (or as little) time as needed to answer all submitted questions. These three (contradictory) guidelines each have pluses and minuses. In the first case, each candidate has the same amount of time, but slower typists (or thinkers) are at a disadvantage. The second case gives control to candidates themselves but tends to produce chats of varying lengths. The third case isn't fair to readers who might tune in late. Regardless, a news site should pick one of these standards (or a combination) and stick to it.
- Require each candidate to type for him/herself, or give each candidate equal access to a typist/transcriber. Again, a news site should choose one of these mutually-exclusive standards. I prefer the second, because not all people are comfortable typing.
- Give each candidate equal access to a spell-checker. This is an interesting issue, because some argue that, if a candidate can't spell, tough.
- Adopt a standard for which types of user-submitted questions will be allowed and disallowed. Since this relies on human judgement, it helps to have the same human making the judgements for each chat.
- Adopt a standard for editing/rewording user-submitted questions. (Same as above.)
What did I forget? Please feel free to add your own suggested guidelines.
March 25, 2003, 9:48 PM ET
Registration forms make it too easy to cheat
Two of America's most highly trafficked news sites, washingtonpost.com and usatoday.com, require users to give out personal information in return for access to news. Alas, these registration forms practically invite people to cheat, because they provide easily replicated examples of valid input next to the "year of birth" and "zip" fields:
What incentive do people have not to use these example zip codes and years as their own?
If I'm interested in reading a news article -- one that I've actively sought out, and invested in, by clicking on a link -- I will fight as swiftly as I can to defeat any jarring interruptions a site might throw at me. I suspect many people act the same way. (At least one person does.)
March 21, 2003, 3:59 AM ET
Miniblog: Stuff I've done lately
It seems I'm always trading off between blogging a lot and working a lot.
To counter that, I've added a new feature to this site: A sub-blog of things I've been working on lately. It'll include projects recently finished at work, additions to my blog software, side projects and anything else I've been up to.
The new page is available in the navigation bar throughout this site.
Eventually I'll database this, add permalinks, etc., but it's a standalone page for now.
March 17, 2003, 3:27 AM ET
A review of Web NCAA bracket interfaces
It's college basketball tournament time in America, and millions of sports fans are taking their best shot at predicting the winners.
I took some time to look at a few online bracket contests. Not that I'm a sports fan in any way; I was mostly interested in how various sports news sites presented a means for user-submitted brackets. Some highlights:
FOXSports.com
Method: JavaScript, via buttons. Users click the yellow button next to a team to designate it as a winner. All four regions (East, South, Midwest, West) are on the same page, in separate brackets.
Comments: The yellow buttons are a bit small (and thus difficult to click). Plus, they all look the same; it's easy to mistake one for another, especially in the crammed-for-space first round. And users without JavaScript cannot use it (and aren't even notified of their browser's shortcomings via a noscript message). Otherwise, it's nice and clean.
SI.com
Method: JavaScript, via links. Users click the team name itself (which is a blue, underlined link) to designate it as a winner. The four regions are split across several DHTML layers on the same page, accessed via a horizontal navbar.
Comments: Beautifully simple -- once I understood I was supposed to click the team names in order to choose them as winners. (This works against the Web convention that clicking on a link gives you more information about it.) Doesn't provide a way for non-JavaScript-enabled users to submit their picks, though.
Yahoo! Sports
Method: HTML drop-down select boxes. Users choose the team that sits in a particular slot on the bracket (a subtle difference from the previous two examples). The four regions are split across four pages.
Comments: A clear advantage here is users' ability to work backwards. (Some people like to fill out their brackets this way.) Plus, users with JavaScript disabled can still use it, and hitting the Back button after a submission won't erase all your picks. (JavaScript will.) The tradeoff: Selecting each pick via a drop-down box is significantly more laborious than the point-and-click of the previous two examples.
ESPN: Flash version
Method: Flash. Users can either click on a team to advance it, or drag a team as far as they think it should advance. The four regions appear on four different areas of the screen in the same Flash interface.
Comments: Beautifully done and a joy to use -- if you have Flash. The drag-a-team feature is brilliant; it meets the needs of backward-users and forward-users. The clicking of team names is straightforward and didn't make me double-take (as SI.com's blue underlined links did).
ESPN: HTML version
Method: HTML radio buttons. All four regions are on the same page; each round gets a separate page.
Comments: Those radio buttons are awfully hard to pinpoint with a mouse cursor. This'd be a good deal easier if the team names were marked up with the label tag, which extends the clickable area of the form element to include the text. But the usual advantages of standard Web forms apply: It works for all users, and the choices stick around after a click of the Back button.
Final comment: My own bracket
This weekend, I put together an interactive bracket selector, similar to the above brackets, for our KUSports.com 2003 NCAA Tournament Contest. It uses JavaScript with buttons, with a noscript message for users without JavaScript. The cool thing about it: Users get a customized PDF file of their bracket as soon as they submit it. (I used PHP's PDF libraries to do so.) As far as I can tell, we're the only site that offers this feature.
March 14, 2003, 11:30 AM ET
Dallasnews.com: Caught red-handed
Spotted about 45 minutes ago on the home page of the Dallas (Texas) Morning News (note the caption):
Not only is the photo overly distorted; the caption is flat-out incorrect. The young boy on the left side of the photo is not Brian David Mitchell, the man who is suspected of kidnapping Elizabeth Smart. The young boy is Elizabeth's brother, William.
This photo was live on the dallasnews.com home page for about five minutes. It might've been longer; it had already been there when I first loaded the site at 9:46 a.m. Central Standard Time. I shift-reloaded several times during those five minutes, to make sure the photo wasn't sitting in my browser's cache.
If dallasnews.com's traffic patterns are anywhere near those of a typical news site, that incorrect caption was published smack-dab in the middle of the site's daily traffic peak -- the start of the business day. It's safe to say tens of thousands of people saw it. Some might have laughed, some might have gasped. Others might have let out a cry of disgust and announced it to their fellow coworkers as "the worst home page photo ever" -- like the guy who sits next to me at work, who alerted all of us here in Lawrence, Kansas.
The dallasnews.com staff corrected the photo after a few minutes. But there is no mention of the mistake on either the home page or corrections page.
When a newspaper publishes an incorrect caption, it makes an effort to publish a correction the next day, in the name of restoring its credibility. When a news Web site publishes an incorrect caption, it shoves its mistake under the rug as soon as it can.
March 10, 2003, 11:42 AM ET
Interview with Web optimization expert Andy King
Andy King, author of the new book Speed Up Your Site: Web Site Optimization, was kind enough to chat with me over e-mail about Web optimization -- making pages load and work efficiently -- and how it applies to news/information sites and weblogs.
Andy founded WebReference.com and Javascript.com, two of the most respected Web development sites. He's written a wealth of articles on Web development, optimization, scripting and design -- many of which, as I look back, I specifically recall reading and printing out over the years. If you haven't checked out Andy's book, you really should. He's made three chapters available online.
The interview:
OK, so you're willing to do this interview with me about how your optimization tips apply specifically to news Web sites. *Are there* any optimizations that are particularly relevant to news sites? Is the typical news-site design particularly vulnerable to a certain type of bloat?
News sites generally dispense news in the form of text: headlines and decks, which then point to full stories. The three main problems I've seen with news sites (which include blogs) are old-style formatting, large decks and overuse of graphics and advertising. Some news sites still use tables, font tags and single pixel GIFs, which can be inefficient. Switching to high-level CSS selectors and CSS layout control can make a big difference in size and speed. Even without updating to CSS layout you can optimize your (X)HTML to help cure the slow-loading blues.
Headlines should be descriptive, short and sweet. Decks (or "blurbs" as we call them) should be concise and summarize the story in a sentence or two. On blogs the deck is sometimes the story itself, but users skim at first, so long decks can slow them and your pages down. Overuse of images is common, especially for graphic rollovers, but can kill 56Kbps connections due to all the HTTP requests. Most home users in the US are still at 56Kbps or less (67.5% as of Jan. 2003 according to Nielsen//NetRatings), so it is a good idea to design for speed. You can now substitute CSS rollovers and be confident that the most of your users will see them.
Overuse of advertising? I certainly agree with you there. How much is too much?
At a certain point users will reject a multitude of banner ads. I'd say after three or four good-sized banner ads you start to get to the point of diminishing returns. At 10K or so each (some rich-media ads can be much larger), that is 30 or 40K to deal with. On slower connections, this can bog down your pages, especially when the dimensions are not specified. I prefer seeing one or two ads, and some studies I've read agree.
Adam Smith's "invisible hand" will ultimately determine this. It's the classic tradeoff: In the short run, sites can make more money per page view with more ads. But over time they'll lose users who bail out of their slow-loading pages. That is, unless you switch to text ads like Google's AdWords.
Let's move on to content matters. Some news sites (e.g. the New York Times) split lengthy stories over several pages. From an optimization perspective, what do you think of this practice?
I think it is a good idea for longer stories. Breaking up longer stories can ensure that each page will load in under 8.5 to 10 seconds (about 30-34K total for 56Kbps modems). But you don't want to "overchunk" your content. After about the fourth or fifth page we found that readership falls off dramatically. For shorter stories, users prefer everything on one page. Ideally you'd provide a "chunked" story and a one-page printable version.
How short is too short? How "chunked" is too chunked?
Ah, the paging versus scrolling issue. This is a complex topic with lots of variables at play. There are a number of studies out there, and some rule-of-thumb guidelines. Nielsen has softened his "users don't like to scroll" stance, as we've become used to some scrolling.
For longer texts (4 to 6 screens), some studies have shown that users read faster paging from screen to screen and more importantly find information faster paging, rather than scrolling one long document. However, a SURL study found that paging through short pages took significantly longer to read than a "full" or "scrolling" condition.
A screen-full of text seemed to perform best (the author estimates that the optimum page length is about 700 words). I've seen recommendations up to 2 to 3 screens for the length you want to make individual pages in a longer document.
Here are two places to find out more:
- http://psychology.wichita.edu/surl/ - SURL has optimum web design studies.
- http://www.humanfactors.com - Human Factors International has an excellent UI (Design newsletter that summarizes the HCI research for the past month)
Is your "8.5 to 10 seconds" guideline more applicable to a news home page, or a specific story page? Have you found users tolerate longer download times for one over the other?
When researching the book I found that the consensus was that without feedback, make your pages load in under 8.6 seconds (I rounded down a bit :). This is an average, but a good guideline. I've even seen studies recommending 4-6 seconds, where attitudes towards the site bottom out at 8 seconds. Familiarity, perceived complexity, feedback, and age are some of the factors that can lengthen the acceptable delay. In their second "Need for Speed" study, Zona Research recommended shaving load times by 0.5 to 1.5 seconds for dynamic sites. That's where the name of Chapter 1 came from, "Response Time: Eight Seconds, Plus or Minus Two" (a somewhat tongue-in-cheek homage to Miller's classic work).
I recall reading a study that found that once users arrive at a "destination" page they will tolerate longer delays. Say, for example a multimedia Flash presentation. But for most pages like home pages and gateway pages you've got to make them load quickly. Users don't read your home or gateway pages; they're looking for something interesting to click on. For news stories, as they are mainly text, users expect them to load quickly.
What's the best way of presenting photos related to a news story? Embedding them in the story? Presenting thumbnails that link to larger versions? Isolating them into photo galleries?
Thumbnails that link to larger versions. For news stories, you can often get away with larger thumbnails, as there are usually only one or two images -- unlike, say, a photo site.
Do you advocate creating "high-bandwidth" and "low-bandwidth" versions of sites?
Yes, for high-bandwidth sites of course. Most of the major news sites I tested offer streamlined text-only or low-graphics versions. Some offer RSS feeds, which are very efficient to view in news readers. Ideally you'd design your pages to be so fast that you wouldn't need a "light" version.
Rich markup, such as abbr and acronym, adds a good deal of semantic meaning to HTML documents -- but, obviously, at the cost of extra code. Is it worth it?
Yes, I'm all for marking up your text semantically with these content-based style tags and styling with CSS rather than festooning font tags or using physical style tags like <big> or <blink>. You can take this too far, of course.
How far is too far?
By doing things like <div class="mainnavigationbar activestate etc."> and using verbose HTML/XML tagging.
I noticed Chapter 13 of your book touches on "PDF Optimization." When should news sites use PDF, and when shouldn't they? And, from an optimization perspective, what are your thoughts on the practice of some newspapers to offer everything in PDF instead of HTML?
We show how to optimize PDFs in the Multimedia Chapter because they have become so popular on the Web (Google has indexed over 20 million PDF files). There are a lot of fat, unoptimized PDFs out there. For white papers and research reports they work well, where you need precise control over layout, fonts, and printing. For normal news stories, HTML is smaller and faster to display. For a newspaper, offering only PDFs defeats the purpose of HTML. I'd at least recommend offering both, and consider auto-generating your PDF files.
In your WebWord interview, you called Yahoo the "most highly optimized home page" you've seen. Can you think of any news sites that do a particularly good job of keeping their pages optimized? It's OK to say no.
No, just the opposite. I tested ten of the top news sites for you; they average over 145K for their home pages. Some are nearly 200K, and all could use some optimization. Perhaps they think we're all on broadband. But for home users, 67.5% of us are still plugging away at 56Kbps or less, as my Bandwidth Report shows:
http://www.websiteoptimization.com/bw/
There are some notable exceptions, however. Wired is much improved after their CSS redesign. Their 26K home page (HTML) loads pretty quickly, but could still stand some more optimization. I prefer the news aggregation sites and blogs. They usually load faster with more recent news, and have more personality.
OK, final question. For journalists, the Web has always promised seemingly infinite storytelling space -- something newspapers, TV stations and radio stations have never had. Yet, just as online journalists are beginning to take advantage of the medium, folks like you are saying, "Gotta keep the pages lean. Gotta make it download fast." Obviously, that limits the sorts of things journalists can do. To what degree should online journalists let optimization considerations limit their work?
You touch on a great point. The Web is only limited by the hard drive(s) your site is stored on, print is strictly limited by story inches. Have you noticed a tendency to ramble on a bit online? If you want to retain your readership you've got to curb that urge, at least on your front page. The way around that dilemma is to give them tight descriptive teasers that link to longer stories.
Writing compelling headlines and decks, or "blurbs" as we call them, is an art form in itself. At WebReference we used to see who could "out-blurb" each other in one or two sentences. The folks at ClickZ.com are especially good at this. I always look forward to seeing what they come up with next.
Once inside the story proper, the same things you learned in school apply. Just because your writing palette is virtually limitless doesn't mean you have to fill it up. I'd say a good guideline when you are writing is to always keep your readers in mind. This is a huge topic, so for all bloggers and journalists I would recommend two books: "Hot Text: Web Writing that Works" and "Wired Style." They're both excellent reads and will improve your writing for the Web.
March 10, 2003, 2:24 AM ET
Standing up for standards
This message from Online Journalism Review editor/columnist Staci D. Kramer was posted to the Poynter online-news e-mail list this evening:
Given the overwhelming use of IE in its various versions I'd like to hear how news site producers decide which browsers to support, when to use applications that shut out non-IE users and when to upgrade your sites to new versions of browsers/applications. I'd also like to hear about any developers who have stopped supporting other browsers as they upgrade. ... I'll post the link when my column on this subject is published.
I felt a strong need to respond. What follows is my e-mail to Staci. If you'd like to send her your thoughts (and I encourage you to), e-mail sdk [at] ojr [dot] org or post a comment here.
Staci,
It's quite simple, really.
Web designers shouldn't design to support particular browsers. Instead, they should design to support particular standards -- Web coding standards put forth by the World Wide Web Consortium.
Here, in a nutshell, is why:
The W3C lays down the HTML law. It decides which tags to add, which tags aren't needed anymore, and which tags are worth keeping around.
As the W3C releases its recommendations, browser vendors try hard -- some harder than others -- for their products to reflect the W3C standards. But, inevitably, browsers are released with rendering bugs. And inevitably, some browser manufacturers make up their own standards, adding and subtracting HTML tags and behaviors.
Multiply those inevitables by the four or five major browser vendors, and you've got a slew of subtly different flavors of HTML. Which is why most Web designers either go crazy trying to support each one, or just say "screw it" and code their pages to look nice in the top two (or three, if they're feeling particularly kind) dominant browsers, ignoring everybody else.
Thanks to this ignorance, perfectly legitimate readers who use less popular browsers such as Mozilla, Opera, Lynx or JAWS aren't able to get news -- arguably the most important information commodity obtainable online. For a news provider to ignore these users is utterly unacceptable.
That brings me to your question.
You wrote, "I'd like to hear how news site producers decide which browsers to support." No doubt you'll get several responses from online-news developers who will happily -- stupidly -- report that their sites are intended only for Internet Explorer version 5 and up, or for Netscape version 4 and above. No doubt you'll write about that in your article. And no doubt others in the industry will read that and say, "Hey, so-and-so news site only cares about Internet Explorer 5 and up! If that's good enough for them, it's good enough for us."
See where I'm going with this? If you publish an article detailing the various extents to which news sites support certain browsers -- in effect, endorsing such techniques -- you will have done the Web design community a great disservice. Designing to a particular browser, or set of browsers, is poor practice.
So what should you write about? Easy. The importance of standards.
There's a trend -- although I hesitate to call it that -- going on right now in Web design circles. It's called the Web Standards Movement, and an organization called the Web Standards Project (http://webstandards.org/) is leading the way.
The WaSP and thousands of Web-designer converts are committing themselves to using only W3C-standard code. It makes sense, when you think about it: Why design to accommodate five different browsers when you can design to a single standard -- a standard that makes your Web pages accessible to any graphical browser, text-only browser, screen-reader or other Web device capable of rendering HTML?
This is the future of Web design, Staci, and I implore you to discuss it in your article.
Adrian
P.S. Several big-name sites have already made the commitment to Web standards: Wired News, AllTheWeb and, just recently, ESPN.com. I can provide more information or sources if you'd like.
Post a comment:
Comments on this entry are closed.
Don't see any comments? That's because my Web hosting provider has made a server upgrade that broke the commenting feature on this site. I'm working to restore that; please check back later.