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.
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.
Labels: media, mobile internet, publishing, wap
posted by Brad Paton at 9:01 PM
0 comments
