Wall Street Journal Online Has a "Null" Problem

In case you are unfamiliar with the mostly geek-oriented term "null" used in the title of this piece, it is used to refer to an unknown value. Apparently the website of the Wall Street Journal, looked at by many in the newspaper industry as representing a site that "gets" what it is to make money online, has a bug somewhere in the system that prevents me getting to their home page to look up an article or two I was wanting to post to my del.icio.us profile.

I'm a self-confessed dork, so I memorized the non-intuitive web address, online.wsj.com, and tried that first. Results?



In case you can't see it very clearly, the resulting automatically re-directed URL that the WSJ's server sends me to is "online.wsj.comnull&url=http://online.wsj.com/home/redirect/" which isn't quite kosher, as it makes it look like instead of ending in the normal ".com" it actually ends in the strange "comnull&url=http:".

There are 2 things missing here. 1) the "/" which separates the ".com" from the rest of the address, necessary so the server knows where to start looking for information to process the request, and 2) what comes after the "/", normally a page/file name for the article or script you are looking for.

This second part isn't always necessary, as on some blogs there is a default script that processes everything un-specified in the directory referenced, but if you simply replace the word "null" with a "/" character, you get a "Page Unavailable" error from the Journal servers. Clicking the journal logo on this error page to take me to "online.wsj.com/home" doesn't do me any more good, resulting in the same "null" problem as above.

Being enough of a geek to understand basic troubleshooting, I decided to see if the problem were somehow related to my choice of browsers, so I tried to load the same "online.wsj.com" address in Firefox instead of my normal choice of Apple's Safari web browser. Bingo! I actually get re-directed to the correct final destination, "online.wsj.com/public/us".

Now we're getting somewhere. An additional wrinkle is that I'm the proud owner of Apple's newest craze, the iPhone, which means that if I want to test my code to see how it will run on it, first I needed to upgrade to the 3.0 beta of Safari. So I tried one of my other machines running the currently shipping v.2 of Safari, and had the same success as the local copy of Firefox.

Why should it matter which browser a user uses as to whether or not a newspapers site redirect works or not? Shouldn't there always be a lowest-common-denominator option that unknown/test browsers get dumped to? Of course there should be, as newspapers are not technology companies, and simply taking a user to your home page is not the sort of advanced "feature" that logically you could get away with requiring your users to use an "approved" browser to enjoy. Flash, esoteric AJAX applications, or Windows-only technologies can claim that, but redirecting from your root web address to your chosen home page? Not quite.

The solution to my problem? Now I have to memorize the full target URL, "online.wsj.com/public/us", and type all of that into my address bar to get to the WSJ home page. Or use a different browser. Or a different computer.

You know what? After I post these two articles, I think I just won't go there any more on this computer. I don't think that's the desired effect, but there you have it. Maybe I'll try again in a few months to see if the WSJ has fixed their bug, for I don't see how they can legitimately claim it as a browser based bug when the Journal servers are returning the "null"-based address. The Journal is fortunate in that their content is seen to be valuable enough to users that we're willing to pay for access to the site, so the incremental decrease in ad impressions from decreased usage from bugs like this won't matter much.

But 99% of the newspapers out there aren't so fortunate. Case in point: the NY Times supposedly soon-to-be-retired "Times Select" product. When the NY Times put Thomas Friedman and company behind the for-pay curtain, I simply stopped browsing their site, rather than be frustrated by seeing something I was interested in but had to pay to get. Instead I would go there for an article that somebody else referenced, so long as it was free. But otherwise I simply replaced the Times with the Washington Post for my day-to-day browsing, a fact made easier since the Post is my hometown newspaper, so more generally relevant to me anyway.

Which side of the fence does your newspaper lie on? Indispensable? Or easily replaceable? The answer to that question should determine exactly how fault-tolerant, and end-user friendly you make your systems, both editorial and technological. What do you do that can't be gotten anywhere else, and is necessary to your readers?

How NOT to publish a mobile/WAP version of your site

Now that news publishers are ramping up their mobile web staffs for the iPhone and other entrants in the burgeoning smart-phone world, it's time to start thinking more about exactly how well they're servicing that market. Unfortunately right now, many publishers seem to be making some of the same sorts of kludged solutions they did back in the early days of the web, where you had sites divided up into versions targeted towards browsers that could and couldn't handle frames (remember frames?).

One specific "kludge" I'm referring to is taking the time to sniff out whether a browser is a mobile or desktop browser, but not then going the next step and finding the page that browser was trying to access and giving it to them directly if it exists instead of just dumping them on your mobile portal home page.

But then again, maybe I'm expecting too much since I can't count how many news sites change their site architecture and then don't make the effort to re-direct their readers from the old section pages those users may have already bookmarked, or found a link to in some far flung corner of the internet, to the new section pages, instead returning outdated content at best, sometimes even with a note that the section is no longer being updated, or at worst showing the user a "page not found" error, often accompanied by some sort of admonition instructing the reader, their customer, to change their habits. How's THAT for customer service of the sort that would land a non-newspaper company in the virtual dock in front of their own consumer affairs columnist?

For example, I recently decided to add a custom WAP site to my American soccer news index, www.ussoccerreview.com, so was browsing my current version of the site on my Palm Treo 600 to see how my baseline fared. Since it is almost exclusively a text-only site, being an index and all, I expected it to do pretty well for page-weight, which it did coming in around 60K.

There are some interface tweaks that I was able to identify needing to make it a little more friendly on the small screen, mainly breaking up the quantity of articles listed into more bite-sized chunks, etc., but overall there isn't too much I'll need to do to make it play nice on a Treo, or the new iPhone I'm hoping to be able to get my hands on this Friday.

However, my big surprise came when I clicked on a link from my site to show my wife an article in the Los Angeles Times that I indexed about David Beckham. Instead of going directly to the article, instead the LATimes site sniffed out that I was on a mobile browser and redirected me to their Crisp Wireless provided home page. Of course that cheesed me off a bit, as I now had to go through 2 more clicks to get to the article: one to get to see ALL of the articles in the Sports section, and the second to get to the intro of the article, complete with another link to "View Full Article" rather than having to manually click through all 4 pages the article was sub-divided into one at a time.

Being a geek, and someone who doesn't like frustrating his readers, I decided to look at the article's web address and see if I could come up with a parser that would translate the regular web URL into the mobile URL. Most CMS systems seem to use a unique identifier in the URL for their stories that should make a solution like this relatively straightforward, except Yahoo News, which inexplicably uses and re-uses old-fashioned slug-type identifiers (definition 7 here is what a "slug" is if you're not sure), which makes it a crap-shoot as to whether the article I found today at the address (http://sports.yahoo.com/sow/news?slug=reu-copamexico&prov=reuters&type=lgns) will be the same as the article I find tomorrow at that same address.

If this were the case at LATimes I would be able to take the URL from the full web page, break it down into its contituent parts, pick out the dynamic piece(s) that would be necessary to create a valid mobile URL, and voilà! Posh and Becks in 2 less clicks (and lower points on my blood pressure).

Unfortunately, here's the shortest legit version of the web URL: (http://www.latimes.com/sports/soccer/la-sp-elliott26jun26,1,829190.column). And here's the corresponding mobile version: (http://mobile.latimes.com/detail.jsp?key=42149). Normally there is also extra garbage tacked onto those URLs for LATimes to track some extra data for their reporting tools I'd imagine, but since I don't know what that is exactly, I wouldn't pass that on to my users as it may be unique to my session/account or who knows what.

As you can see, there isn't any way to get from point A to point B without some inside information not available to the general public, so I'm stuck with linking to articles that I know won't work properly when browsed on a device that the LATimes identifies as mobile and sends to their mobile application. How is that user-friendly?

Now I'm looking at the un-happy prospect of having to create two classes of article links: ones that I know will work on any device, and thus I'll include on my mobile site, and those that don't and will only show up on my main web site. My alternative options:

1) Leave it as is and have to deal with upset readers who tell me that my link is wrong. I could also post an FAQ or other note on the site explaining the situation, but that is unlikely to mitigate much of the anger and frustration since readers are unlikely to look there before they click the seemingly erroneous link.

2) Create a parser that will crawl the mobile sites of the offending publishers and try to match up headlines, bylines and publishing dates, but even that would only get me so far. The web headline of this particular article is "Beckham move brings back memories of Gretzky", while the mobile version inexplicably makes the verb plural, "Beckham moves brings back memories of Gretzky" (probably was created from an earlier and un-corrected version of the story provided by a feed, instead of updated when the web version was).

The first alternative is almost no work, but likely would make my email in-box a place I'd like to avoid, while the second is even more work than the ghetto-ized solution I'm otherwise looking at.

Before anybody gets all up in arms with the old chestnut about how I'm just like Google, making my bucks off the backs of the hard-working publishers by indexing their sites, remember, all I'm doing is referring them readers! I've identified a unique content area that any one of these publishers doesn't service completely, and telling them where to go when those publishers happen to have a story relevant to that subject. I understand my readers because I am one: a die-hard US soccer fan who finds the few articles the local newspapers happen to post about it nowhere's near enough for me, while the automated Google News index is too-filled with duplicate AP/AFP/Reuters wire-feed articles, even with the "hide duplicates" setting on.

Whatever the case, whether it be a hand-edited news index like mine, where an editor actually personally reads every article before including it in their index, or an automated aggregator/crawler like Google News, you get the exact same reader frustration, and while they may take it initially out on us for supposedly pointing them in the wrong direction, it's not like they will all of a sudden choose to start browsing the publisher's web site directly, for I'm sure that idea had already occurred to them and been rejected for whatever reason or other.

If however that argument doesn't sway you, here's another common scenario that leads to the exact same problem.

As I noted above, I'm a news-hound, but not just for soccer news. I read dozens and dozens of articles every day on not just a regular set of topics, but also serendipitously. In order to do so I have to be pretty efficient in my browsing time, as I'd imagine any busy reader with limited online time does. One of the habits that I have is to find an article of interest, then either print it out to read later, or if I'm going somewhere that I'll have cell access and not have to focus on driving, email a link to it myself so I can read it on my Treo later. Which web address will be in that email, or even in your "tell-a-friend" email? You guessed it, the full-blown web URL, which will again result in me going to the LATimes and sent to their portal home, from which I'll have to navigate all over again, or not, as after this has happened to me a couple of times, I'll just stop altogether.

I don't mean to beat up too much on the LATimes, as their system actually appears to be managed by the parent Tribune Company, as evidenced by the "help" link on the mobile site sending you to mobile@tribune.com, but it happens to be the example I had to deal with today.

So, if you're going to go through all of the trouble of paying good money for Crisp Wireless or whomever else to convert your fancy schmancy, high-falutin' everybody-has-to-have-it content over to the wonderful world of un-tethered web browsers, do yourself a favor and don't shoot yourself in the foot by annoying your already loyal readers. If they know exactly what they're looking for and it exists on your site, give it to them. Don't make them jump through extra hoops, and don't blame that on a 3rd party provider. It's your content, you're the ones people like me are going to yell at.

Reporters, Not Writers

Journalism That MattersWashington Post

"Which leads to a wrenching dilemma: News organizations clearly need to build up their online offerings, big-time. But if they bleed the old-school core product in the process, that can cause problems both editorial and economic."

Umm, no. If a news company looks at itself as a newspaper as opposed to a deliverer of news to its given audience, then it sees things exactly backwards, just as presented above. It is 100% true that the money derived from the print version of a story far exceeds that from its online component, but so what? The reporting is the reporting, the medium in which it is delivered, print, online or some currently unknown future version, is completely immaterial.

Reporting takes time and money, but you know what, the reporting that an online media enterprise would undertake is literally no different from that a print reporter would. Do you think Bob Woodward would refuse to do an email interview with Vladimir Putin if that was the only way he could get him on the record in detail on a subject on deadline? Do you think if he happened to get him on the phone, still on the record, he wouldn't hesitate to put dear old Vladimir's translator's voice attached to his story if he could?

Reporting is reporting, delivery of the results is a completely separate enterprise. You allocate your delivery and sales resources according to where it makes sense, and invest in reporters, let your readers/audience decide which medium that reporting is best delivered in.

Would the Walter Reed article be more hard-hitting with some actual amateur video footage taken from inside Building 18 to rebut the inevitable counter-attack to come from the Department of Defense, which as expected was not of the accuracy of the piece but of the "fairness" of them, as if it were more fair to not discuss the conditions experienced by whatever percentage of Iraq and Afghanistan veterans and their families were represented by the examples in the article than it would be to remind us that despite official proclamations of appreciation for the contributions of members of our armed forces, the real sentiment from on high becomes self-evident when the budgetary push-comes-to-shove happens resulting in not enough resources being allocated to make sure that whatever number Building 18-style experiences there are is more than what is acceptable in a country as powerful and capable as ours is.

There are certain things for which the term zero tolerance was invented, and shabby treatment of those who have given of themselves for the rest of us is one of them.

Words to such effect may move some, but imagine what pictures of the molding walls would do. Video is a powerful medium, all too often cheaply used in the news media for shock and titillation, but there are situations where only it can drive home the stark presentation of a simple truth like the reality of Building 18, and isn't that truth ultimately the objective of all good reporters?

Why the iPhone Matters to the Media

From Steven Levy"s recent newsweek interview with Steve Jobs (Apple Computer Is Dead; Long Live Apple):

But cynics may note that instead of Apple’s instant-messaging program iChat, there is that aforementioned SMS messaging program. On the screen, when you send and receive messages, the display resembles the way you view them on iChat, in colorful text balloons. But because each message is an SMS text message, depending on the billing plan, users may get charged a few cents each time they say "wassup." (iChat lets you gab all you want for free.) Maybe this won’t be a problem—Jobs hints that Cingular may offer different billing plans for iPhone, though for now he isn’t saying for sure. In any case, Jobs say, "There’s no reason we couldn’t have iChat on here." So bring it on.

Actually, what I would expect to see is that Apple and Cingular figure out a way to merge your iChat ids with your phone"s SMS features. You see, whether you receive a message via SMS or iChat, Cingular gets paid. Just like SMS messages come either priced a la carte and/or bundled with a certain amount of free messages, or even unlimited messaging on some plans, data is sold the exact same way and at its heart iChat is just data.

The question will be whether the price of bandwidth/equipment to generate the additional iChat data traffic is greater or lesser than that to support the SMS"s, since everything has a cost, even things that you eventually charge for. So Cingular has an incentive in a competitive market to find a way to package and incent their customers to use the service that operates not just most profitably, but also most efficiently, for if they don"t somebody else will.^* If it"s cheaper to service the iChat-ers, it might be smart to lower the prices on their existing SMS services to the lowest stomachable profit level to attract heavy text-ers, who will probably also be heavy iChat-ers, either already or nascently, since each has contexts in which it is most well-suited.

For example, SMS means "Short Messaging Service" because it has a limit on the number of characters in an individual message, so anything over 140 or 160 characters gets split into multiple messages (geek alert: for more info see wikipedia article). This is why some of my more longer-winded messages get split into multiple parts by Cingular, which are then sometimes delivered out of order to my friends and family. Generally it's just kind of a hassle that requires me to explain to the people on the other end why I seemingly have become syntactically dyslexic, but there are circumstances where the order of a short message is going to be crucial. One of those is customer support.

I personally use Apple's iChat Instant Message software to help me support my handful of clients when I happen to not be working on-site, which is most of the time. In addition to IM support being cheaper than the phone, it allows me to multi-task, letting me keep up on my email correspondence, continue coding, or whatever else it is that I may be in the middle of when someone runs into a problem that requires timely responses. Now imagine larger enterprises that have much more real and complicated challenges with customer support.

Do you remember AOL? Just kidding of course, the real question is do you remember Prodigy or Compuserv? "Back in the Day," as the saying starts, every high profile company that cared about its customers had to have support forums on both of them, in addition to the eventual champion in the closed-bubble variety of online services that dominated the landscape before the eventual triumph of the full internet and worldwide web. For that privilege those retailers paid Prodigy et al until they migrated those services off to the web, where if they are now doing live customer support they generally rely on java- or flash-based apps to manage the communications.

If you've ever used either of those technologies, or even a web browser, on the current generation of Smart Phones/PDAs you'll know exactly what an almost completely unusable nightmare that is right now for mobile users. What if the retailers could pay Cingular and Apple to make it work and work easily on the iPhone? Might they be willing to pay for the privilege of easy instant message/chat based support? It certainly would be an added benefit for Apple and Cingular to tout in the marketplace, and again if it increases the greater adoption of the more efficient usage of the digital cell network for Cingular (it takes fractions of the bandwidth to service voice for purely textual information since all you need are letters and numbers, not a reliable representation of a sound wave).

So allowing iChat on an iPhone would both drive the future's more efficient data traffic consumption instead of the past's much more limited but well understood SMS services, and a potential revenue stream for the walled gardens that all Smart PDAs currently represent. Sounds like an easy choice to me, but what do I know, right?

And what does this all mean for the media? Well, did you happen to take a look at how the Safari browser works on the iPhone? It dramatically improves the user experience here also, which is bound to drive more mobile web usage, and thus data traffic revenue to Cingular. And this also means that we will start seeing another entrant in our web server log files to be accommodated. That's the bad news. But the good news is that what we will be able to push to that new channel will be remarkably better than what we can send out to the Treos, Blackberries and Windows Mobile devices on the market.

Remember that the iPhone was originally a multimedia player, so it is already optimized for audio and video, so let the high-bandwidth mobile streaming begin!

^* Don't you think Microsoft would love to sell their Zune with integrated MSN Messenger/SMS combined with a cheaper SMS rate setup on Verizon if Cingular and Apple leave the market opportunity open to them to do so?