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?
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?
Labels: apple safari, iPhone, new york times, newspapers, wall street journal, washington post
posted by Brad Paton at 11:31 AM
0 comments
