Scripting News for 9/14/2006

Evan Williams explains how Odeo screwed up.  

“Mr Gutman” on second-time entrepreneurs. 

Now if Podshow’s CEO, Ron Bloom, Odeo’s competitor, were as insightful and open as Evan Williams, he would say something like this. “I thought all the technology for podcasting had been invented, but boy was I wrong!”  

Rex Hammock in 2/05: “Opportunism should never be confused with passion.” 

Engadget on Microsoft’s new iPod-alike, Zune. 

Todd Bishop: “If Zune is to become the long-awaited iPod killer Microsoft so clearly wants it to be, it’ll have to compete on a much more elusive battlefield: coolness.”  

Michael Gartenberg: “I can share any song on the device to any other device in range. DRM content or plain MP3s but don’t get too excited.” 

I don’t understand what Amazon is doing with Promotion via API and RSS for ECS, but it’s intriguing. Are the feeds a demo, or is that real data? 

Mobile-friendly news 

The next step in the evolution of mobile rivers is a way for a feed to link to articles that render well on mobile devices. I don’t want to propose a specific way of doing that, I could, but then the argument would be why I think I have the right to do that, which is an old boring argument that I’d rather side-step. Rather, I’m going to ask the great minds of the tech blogosphere to mull this over, discuss it if you like, and propose some solutions. Even better if you are a source of content, and can vouch for a bunch of feeds that will support your proposed solution. Then we can seek a second party and a third to support the first workable solution that pops up.

Let me try to state the problem concisely, so we’ll know when we have a solution.

First, consider the BBC and NY Times rivers. When I link to an article, I start with the URL to the “rich” HTML rendering, and apply an algorithm to turn the rich URL into a URL that points to a “plain jane” page, one which renders well on a mobile device. For example, here’s an article on the BBC website, and here’s the mobile-friendly version. See the difference? On a desktop or laptop, you’d probably prefer the rich version, but on a mobile device, like my Blackberry, the plain version works much better.

I was able to figure out a mapping for the Times and the BBC, but clearly that won’t work in every case. Somehow each feed is going to have to tell us where the mobile-friendly version is. And that means, inevitably, using a namespace (creating a new one or using an existing one) to link from an item to its mobile-friendly rendering. Or so it seems to me. I could be wrong. Figure it out and let me know. I’ll use whatever works and is supported by the community. (But the clock is ticking, I have an app almost ready to deploy that needs the solution.)

PS: Anticipating that people are going to suggest using Google’s algorithmic method of generating mobile-friendly content, I’d rather not depend on Google, I’d rather the content people take care of this. Building too much on one large platform is a precarious way to build. We’ve already found, many times, that Google doesn’t care what we think. So let’s fix this ourselves, it’ll work much better that way, imho.

PPS: I linked this into a new Technical Issues section in the directory.

47 responses to this post.

  1. But you migh want to at least consider and take into account CSS media type as a discoverability method on a different level?


  2. Amy, work that out among yourselves, I’ve deliberately and carefully removed myself from the discussion.


  3. I understand you don’t want to participate in the discussion, Dave, but could you please answer a technical query: could you foresee any technical reason why you couldn’t use the CSS media type within the system you’re building?


  4. As a content provider with external links, won’t I always be relying on other content providers to have a mobile friendly feed? For now, I can hope that any outbound links go to a “browser sniffer” and redirect if a mobile feed exists, but clearly that’s not ideal. Any chance of an RSS spec update to indicate”mobile-friendly” for a feed? If so, I don’t recommend a short name of “MF”. 😉


  5. The problem with relying on the css/media attribute is that the mobile device will have to download not just the HTML+images but also the CSS, which adds to the user’s wait; plus, a lot of older devices (2G and 2.5G phones mostly) will not get any CSS. Dave’s solution, in my experience is the only one that works consistently, and it’s what I’ve used in memigo now which does exactly that: gives you a “river of news” while directly linking to mobile-friendly content (for the last oh 5 years or so).


  6. how about doing it like RSS autodiscovery i.e.



  7. Bah, WordPress escaped my HTML.

    how about doing it like RSS autodiscovery i.e. with a link rel=”alternate” in the head, type=”text/html”, media=”handheld”, title=”Mobile/PDA” and pointing to the mobile friendly version?


  8. I’m not sure why this problem needs to be addressed. If you want users to read your stuff on a mobile device, then you simply need to have full content feeds. The problem then becomes, how do you read comments on a post and post comments to a post. We have APIs for those too!


  9. Toast of the town: Came across this in the printed version. 😉,,1871367,00.html


  10. If you’re linking from an RSS feed (as opposed to HTML) then use the atom:link element with a custom rel attribute.

    (hopefully this markup will come through ok…)


  11. The markup didn’t come through, let’s try again..

    <atom:link rel=””
    type=”application/rss+xml” href=”…” />


  12. I see no reason why the auto-discovery solution would not work. I t was the first thing that came to my mind.

    However, I also agree that if everyone published full-text feeds, we’d have a all content in an xml format that we could apply our own xsl stylesheets or process it in any way we choose.

    For reasons I don’t agree with, many content publishers are afraid of full-text, and that’s their right, I guess.

    So I say the rel=”alternate” works, because the css folks can also easily just point to a page that they’ve applied a mobile stylesheet or else just to a full text feed.

    Then, the river applications know either to recognize that it is an HTML rendering, or that it is a full-text permalink (if it’s RSS) and need to process that subsequent page “river-style” and deliver it themselves.

    Which shouldn’t be tough. If that doesn’t make sense, please let me know and I’ll try again.

    In other words, much like processing OPML files, we continue to churn and include until we hit a link, and then we link. ; )


  13. I say graphicless Rivers are best, ala Nielsen.


  14. James, just curious, how would the consumer tell that that is the mobile-friendly rendering? It seems the XHTML version could be a “rich” rendering of the content. I like the idea of re-using a bit from Atom, but I don’t see how this would work. Could you explain…


  15. Posted by Chuck Jameson on September 14, 2006 at 5:58 pm

    I’m enjoying the bbc and nyt rivers on my Treo. I also read – their twist on dealing with wireless readers.


  16. my girlfriend just said about the zune: “gross, I would never buy a microsoft one, even if it was better”


  17. Hi all,

    It seems to me a namespace extension to RSS could be the way to go. That way if the namespaced tag is missing from the feed you are reading then you know the content provider does not want their content viewed on a mobile device. If it is there then it points to a mobile friendly version, tailored for the mobile by the best person to do it, the content providers themselves.

    A solution for this needs to come quickly though, my river currently just points to the rich version and that doesn’t look good on a mobile device.



  18. James, I think the goal is a mobile-friendly permalink, not a seperate feed.

    If so, the simplest thing I could think of is just an optional mobile:link element, which works just like link.


  19. Dave, if i understand what you’re asking for correctly, you essentially want to link from a feed (rss or atom) to some mobile friendly rendering of the content. Within the atom:link, the value of the rel attribute tells the consumer the purpose of the link. You could define some URI value like “” or whatever and simply declare that any atom:link that uses that rel attribute value is a pointer to a mobile friendly view. You could even go one step further and register some value (e.g. “mobile”) with the IANA registry link rel values. The atom:link’s type and href values would provide the rest of the information the client needs.

    <atom:link rel=””
    href=”” />

    If I want to know if a RSS channel or item has a link to a mobile friendly view, all I have to do is look for the atom:link with a rel attribute value of “”.


  20. Dave: The @rel attribute tells you that it’s a mobile-friendly link… anyone with an app designed to use such a feature would simply look for a link with an @rel=”” and immediately know that the content on the other end of the link’s @href is supposed to be mobile-friendly.

    (I figure James just picked a URI for the sake of discussion… it could just as easily be a purl URI or something else.)

    Matt: The @type in the example could just as easily be text/html or something else.


  21. Matt, in defense of James’s suggestion, I don’t think he’s saying there should be a separate mobile feed, which would be awkward. Atom is a namespace, and RSS 2.0 feeds can include elements from other namespaces. Politically, it would be desirable to use Atom to solve a problem in RSS, to show that they’re not technical adversaries. However, mobile:link is simpler (zero attributes instead fo three) and virtually self-documenting.

    We also need some idea of what makes a page “mobile-friendly.”


  22. I think a mobile:link namespaced element is great.

    In my response above I was thinking we were talking about any link inside the body of a post, not only feed elements.

    Which meant the software that created the mobile version might be detecting mobile versions and replacing links within the description or content:encoded with mobile links.

    If we are just talking about a mobile alternative to the RSS link element, I think a namespaced element is the way to go.

    But you are still going to have a lot of links in the description that go to rich content, no?

    Perhaps that is unavoidable


  23. Hey Dave, I personally don’t give a rip about what the “politically desirable” approach would be. If I choose to add support for these kinds of links in Abdera, I don’t want to have to support two different types of link elements. If atom:link would work, why not use it?

    p.s. the type attribute on the atom:link is optional. the only two things you absolutely need are the rel and href attributes.


  24. Most readers probably classify this as “not my problem,” but…

    Is there any way for these “plain janed” mobile rivers to help pay the salaries of people who report, write and publish the stories in the first place? Subscription charge? In-line ads? Other ideas?

    If mobile rivers generated income, they could pay the salaries of “rewrite” editors finding ways to tell stories on that small screen… ways that might be better than simply using a narrow column for a “plain jane” copy of a story originally meant for a bigger space.

    Or is the plain version of the full story so readable on a Blackberry that the author or editor would be wasting her time trying to rewrite it in layers or non-linear chunks? I have some colleagues who think that’s what “online journalism” students should be learning how to do — write in a new “layered” style for mouse-pushers to click.

    [[ If this seems off-topic here, make your comments over at my place: ]]


  25. Bob, there’s no reason why the Plain Jane renderings can’t have ads on them?

    This came up in a discussion I had with the people at a major news organization this week. I only used the print version of the stories for the NY Times because that’s all I had to work with.

    I also discussed this in the piece I wrote about mobile rivers.

    You might think of the river as an ad for the stories it links to. In that model you would put the ads on the stories, and think of the river as an index.

    In fact the Times stories do have small ads on them.

    The BBC is non-commercial and therefore doesn’t have ads on anything.


  26. If we use atom:link by declaring the atom namespace, then the whole atom spec would be legal.
    Not of great importance here, but interesting if this took off and most feeds declared it.
    It would be like the United Federation Of Planets.
    I guess that would make you Captain Kirk, Dave. ; )


  27. Thanks, Dave. True, the Times has “sponsorship” flags on its river-worthy printable-format stories, and there’s nothing to keep it from adding more, raising the ad rates, or (I guess) making its “printable” or ad-free stories a paid subscription. Coincidentally, I just noticed who is buying today’s printable-format sponsorship: Rupert Murdoch! (News Corp’s Fox Searchlight Pictures.) Hmm. I went looking for ad rates and got a timeout error at That can’t be good for business!


  28. I’d vote for atom:link – not for simplity but for interop.

    Regarding simpleness: any decent developers use off-the-shelf XML-software for feed parsing, meaning the access for the link information is done with an standardised API, DOM or XPath. I don’t see any substanional differece between these XPath expressions:




    Sure, the latter expression ist longer in in terms of string length – but not much more in information density.

    The key is interop – as soon the value ist registered at it can be used without problems in atom feeds _too_. The real problem is the definition for “mobile friendly”. You’ve got to explain why publishers should offer _another_ version of their content for every entry, article, thing – instead of just offering an additional CSS mobile stylesheet for the existing pages. The latter is easier to implement and it is more in tune with the concept of the web – at least since 1998.

    Why should anyone evangelize for yet another version of “mobile-friendly” if there exists an mobile-friendly concept for years – which ist practical and usable today?


  29. Tim, what do you get interop with?

    Also, what are you responding to in your last paragraph. If a publisher already has a mobile-friendly version of the content, why wouldn’t they just link to it? I don’t see anyone here asking for “yet another version.”


  30. Why should anyone set a second link to the same URI, if there is already an mechanism for mobile browsers to automagically render content from the URI mobile-friendly?


  31. If you have a solution, tell us what it is. Please.


  32. Hm. We’ve seem to have an misunderstanding in our views of the web. I’ll try to explain mine. I beg your pardon if it sounds too lecturing, at this point I really can’t estimate your knowledge about web standards, you see me baffled.

    A thing on the web (article, weblog, blog entry, whatever) has an address, the URI. If anyone want to get something he visits this address, metaphorically speaking. All he need’s to know is this address. And if this someone want’s suddenly to visit this website on his mobile – why should he know another URI/address?

    How do you explain Aunt Tilly, that the homepage of her girlfriend martha is located at but if you want to visit the homepage on your handheld it is Or Or Or Or That’s as absurd as telling someone “I live at 300 Desktop Av., but if you’re driving a Smart please visit me at 400 Mobile Rd. and if you’re driving a Vespa please visit me at 500 Superslim Plaza”.

    I consider this mostly a usability and accessibility problem for users, a thing has one address not two. So it is better to have only one page with one address where the content is viewable and usable from desktop browser and handheld browser.

    And such a solution exists. Today. And it is usable.

    The answer since years are mobile stylesheet, meaning an additional CSS Stylesheet with the media type “handheld”.

    While developing a layout you start with just plain HTML, just content, this is a link, this is emphasised, etc. Then you crosscheck with a handheld browser if it’s ok and not to crowded. Then comes part two, the desktop layout, a complete and complex stylesheet which got integrated like this:

    <link rel=”stylesheet” media=”screen” href=”desktop.css”>

    Step three: the mobile stylesheet. Which is extremely simple, as you know the key of usable mobily layout ist mostly the absence of layout. Embedded like this:

    <link red=”stylesheet” media=”handheld” href=”mobile.css”>

    A desktop browser will fetch and use the desktop stylesheet. A decent mobile browser will only fetch the mobile stylesheet and render the bare page with the minimal style.

    And voilá! you’ve got one page with one address but with multiple styles for multiple devices. Today. Opera Mobile? Check. Nokia Webbrowser for S60? Check. Mozilla Minimo? Check. And it is not exactly rocket science. It ist standardised since 1998, it es usable at least since two or three years, since the mobiles ascended from the WAP Ghetto. It is simply a non-brainer for someone who have worked with CSS in the last years.

    If you’re evangelising a content provider for mobile friendlyness which of the following ist easier to say:

    a) Please modify your CMS to eject not only the deskton version of a page but a second mobile version under different URI and please modify your feeds for that. Yeah, it’s new, secondary infrastructure, but hey!

    b) Hey, develop a extremely simple stylesheet and paste a link to it in your pages.

    I’d say the latter. My problem with this hole mobile river story is: It is all about _duplicating_ content, building yet another infrastructure for it while there is an elegant solution on hand. Which leaves me wondering about you. Don’t understand this as critisicm, your recently awakened awareness for mobile devices is great. But did you take any look at existing, working solution before you coded your mobile rivers? Really, I’m flabbergasted.


  33. Tim, you’re right, you are lecturing, and you’re not solving the problem. You’re also being ageist and sexist (the Aunt Tilly thing). If you think someone is wrong, and should do something a vastly different way, you don’t get anywhere by insulting them at a personal level. Almost no one is willing to listen to that kind of argument. You can try again if you want. Tell me what the New York Times to do, and what Matt Mullenweg should do. And if you want people to listen to you, seriously, consider using your full name. Thanks…


  34. I’ve implemented the mobile stylesheet at my blog.

    I’ve designed the HTML layout so that the sidebar is physically at the end of a rendered page, so that the content is displayed first.

    This means that it’s really simple for me to access my reading list (books I’m considering buying) when I’m in a bookstore from my mobile (I have it bookmarked for just that eventuality).

    I’ve implemented my site in XHTML-MT, (even though it doesn’t always validate ;-)). I get a lot of hits on popular search terms from Google mobile search portal, simply because I announce that I’m mobile friendly.

    IMHO, Tim is right. Moore’s law says that mobile browsers will soon be nearly as powerful as desktop browsers, modulo stuff like graphics and Javascript. The simplest solution is to use a CSS stylesheet to strip stuff like that from the mobile view.

    The ideal is *not* to have a bunch of different links in the feed saying:

    * link to full graphics content
    * link to mobile friendly version
    * link to content for the visually impaired

    etc etc

    The ideal is for me to click on a link on any device and get content that’s appropriate for that device (which could be telepathic in the future, who knows :-)).

    The continued success of light-weight content management systems like WordPress in lieu of hand-crafted HTML means that it’s easier for normal people to generate content that’s mobile friendly out of the box. More and more web content will be mobile friendly by default.

    just my 0.02 EUR…


  35. The concept of not duplicating content by using stylesheets is a valid way to design your site.
    However, by looking at an RSS feed, there is no way to tell in advance whether a site is offering a mobile-friendly stylesheet.
    Thus, the mobile link and the link could be the same URI, if that’s what you are offering.
    The challenge at hand is to give river readers links to mobile-friendly content only.
    How a site-owner wants to deliver that content is their business, but we still need a way to communicate that in a feed.


  36. The challenge at hand is to give river readers links to mobile-friendly content only.

    Matt thank you. That’s is exactly what I wish to do.

    The other issues people are raising are valid (except for the personal comments), and may be viable ways to help achieve the goal.


  37. Almost every major news site has a print version or similarly stripped down version of their content that reads nicely on a mobile device. (Today.) Getting them all to switch to proper XHTML, add a mobile stylesheet, and redo their normal stylesheet and HTML to properly order things, is a boil-the-ocean approach.

    As a member of WaSP, I’m completely behind standards-based approach to all things, and I would encourage sites to support mobile stylesheets in addition to mobile:link or whatever. As a tool maker, however, I’ve found the best method to bootstrap something is to do what works today and once people’s appetites are whetted then educate them and improve the marketplace over the next 5-10 years.

    (This is the approach the web standards community took, for example with transitional CSS/table layouts, and it has been very successful.)

    Mobile stylesheets can hide and style elements like sidebars and navigation, but it’s still in the markup and mobile devices (often on slow connections) would have to download it anyway.


  38. If registered, the link would simplify futher to

    <atom:link rel=”mobile” href=”…”/>

    The idea of a generic link element with a rel attribute predates Atom; you will find it in HTML. What it helps with is bootstrapping. At the moment, precisely zero tools support mobile:link. But with a rel attribute, a tool that doesn’t know to look for the link could still do something useful. All such links have a short, human meaningful name, (e.g., “mobile”), and a link. They could display all such links at the bottom of every news item.

    And even those that don’t buy into the more general support will find this syntax both familiar (again, from both HTML and from feed autodiscovery) simple enough to parse (simply look for rel=”mobile” and grab the href). Having an IANA registered IETF standard extension may also gain some additional adoption.

    You can find other RSS 2.0 examples of this in feed history and pretty much every RSS 2.0 feedburner feed has a link rel=”self”.


  39. Dave, thanks for starting this conversation. I’m not the smartest guy I know, and this thread really helped me clarify my thinking.

    I totally support the idea of an RSS namespace, but that wouldn’t help us at digg, because we don’t get stories through RSS, but rather directly from users. And user submit mostly URLs of pages that don’t work well on mobile devices.

    Sure, it’ll be a happy day when all web sites use clean XHTML and a mobile stylesheet, but there are zillions of web sites (digg among them) that simply don’t have time to do that right away. Until then, we need to offer sites an easier way to create mobile-friendly pages and tell us where they are. (i.e. It was way easier for me to quickly create than it would be to make itself mobile-friendly.)

    If we could look in the head of the page to find the corresponding mobile-friendly page, we’d be ecstatic. Therefore, I strongly support recommending the link element in the head, as Kevin Hinde suggested:

    link rel=”alternate”

    We already recommend that as one approach for video thumbnails:

    I’m interested to hear what you folks think of this idea: might apply the following strategies in order.

    1. We’ll keep a list of sites like and, where the URL can be easily transformed, and apply those transformations. (Sites would be invited to submit their transformations to get on this list.)

    2. For sites with the link element in the head, we’ll store the mobile friendly URL and link to it from

    3. For other sites, we’ll probably use a transcoder.

    Yes, this means that sites with clean XHTML and a mobile stylesheet will have to add a redundant link element to avoid being transcoded for now. I’m open to suggestions for how to avoid that.

    In future, when XHTML and mobile stylesheets become the norm, we’d remove the transcoder.

    Thanks again, everyone, for sharing all these great ideas!


  40. I’m such an idiot: Obviously, if the site has a mobile stylesheet, we shouldn’t transcode it. So the strategy would be:

    1. For sites with a mobile stylesheet, just use the URL with confidence!

    2. Keep a list of sites like and, where the URL can be easily transformed.

    3. For sites with the link element in the head, store the mobile-friendly URL.

    4. For other sites, use a transcoder.


  41. Steve, clearly we need to have a way to link from a rich HTML page to a mobile-friendly version of the page. I’ve updated Scripting News to support the syntax you suggest. Could you View Source and tell me if I got it right?


  42. Dave, your link tag looks correct on, thanks!

    But I think we need it on each of the permalink pages, too, e.g.

    Because those are the URLs folks submit to digg.

    Whoops! That wouldn’t work with, which doesn’t have permalink pages!

    You’d need to add permalink pages to (You’d probably want to change the permalinks on to point to those mobile-friendly pages.) and then add link elements to the permalink pages on Scripting News that point to the corresponding permalink pages on

    Does that make sense? Is there an easier way?

    And this raises an interesting point: For sites like Scripting News that use anchors in the permalink URL, I suppose the app should scrape the #anchor off of the base URL and paste it onto the mobile URL, so it goes to the right spot within the mobile-friendly page. (Is there a better way to handle this?)


  43. I know you want to keep things simple, but when reaching for the low hanging fruit be careful not to box all mobile devices in when trying to accomplish simplicity.

    What works for the Blackberry may not work well on other mobile devices. The phrase “mobile device” implies more then what works well on the popular Blackberry mobile device.

    An example of a totally different type of mobile device would be the Origami – UMPC. It runs XP today and typically has a 7 inch touch screen. A typical web page designed for the desktop wouldn’t be optimised for it nor would a html page for the Backberry.

    The Origami is only one type of mobile device that is different then the BlackBerry.

    Maybe instead of trying to pursue a one size fits all mobile device solution, think about defining a solution that would work for all present and future mobile device displays.


  44. Harold, I agree with you. When we talk about “mobile-friendly” pages, it could mean any number of things.

    For example, we made as simple as possible, but we knew before launch that it doesn’t work on devices that only do WML. We decided to live with that limitation for now. In future, we may have several different mobile-friendly sites for devices with various capabilities.

    Now, if a publisher advertises “mobile-friendly” pages with one of the methods discussed in this thread, we still won’t know what KIND of mobile–WML? Simple XHTML browser? Javascript required?

    You’re right that we’re glossing over that fine-grained distinction. Can you recommend a way to add that?


  45. This morning, digg took two baby steps, which should be considered experimental:

    – The home page and popular stories pages for each topic (e.g. Tech News) now carry the link element discussed, pointing to the corresponding pages on

    – now rewrites nytimes and bbc URLs in the same way as and (Thanks, Dave!) That’s essentially Number 2 in the strategy I described earlier: doesn’t yet look for the mobile stylesheet (Number 1) or the link element (Number 3) or use a transcoder (Number 4), but stay tuned!


  46. I like the idea of a meta tag or link to specify the alternative mobile version and the “discovery” process outlined by steve is easy enough but effective!

    On my blog i have posted on some idea about how to structure/style a page to mobile friendly (nothing too technical).


  47. Another small step today: digg River now looks for a link element with a handheld URL or mobile stylesheet.

    So we’ve completed steps 1 through 3 of this strategy:

    We’re still evaluating transcoders. Stay tuned!


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: