A follow-up on yesterday’s posts, I wasn’t really as depressed as it might have seemed because I have a way of dealing with everything seeming to be totally fubar. I have at least three approaches. #
- First, if there’s nothing I can do about something I give myself the choice of not worrying about it. I’m just one person in a world of billions, and I basically have no power over any of the messes I was writing about yesterday. #
- Second, I remind myself that it always feels like everything is about to unravel. I was born in 1955, ten years after the first nuclear weapon was used in war. When I was a draft-age teen, the Vietnam War threatened to become the first world wide nuclear war. We’re still here, proving that maybe it wasn’t as bad as it appeared at the time. (If you think that was bad, my parents’ generation had to run for their lives from the Nazis and their Holocaust.)#
And a third reason — the young folk blame my generation, which is stupid, there are all kinds of boomers, people who marched for peace and to save the earth (I was one of them) and people who thought abortion was evil and there is no climate change, and we’re all in it for ourselves so let it be. Blaming something as abstract as a generation is a way of shifting responsibility from yourself. Young people of today — you’re the ones who have to live with the world we’re all creating now, why aren’t you doing something about it? When you find the answer, you’ll then understand why we didn’t either. The human species appears to have been willfully driving off a cliff for my whole life, and as far as I can tell nothing will stop it. If you know what we can do, speak up and let’s do it. #
So with all that in mind, today I’m going to drink some coffee, roll up my sleeves and write some software that helps dig us out of a hole I do understand and feel I might have some impact on. #
Namaste y’all! ❤️#
Scripting News Annex 
Posted by amyloo on September 14, 2006 at 6:06 am
But you migh want to at least consider and take into account CSS media type as a discoverability method on a different level?
Posted by Dave Winer on September 14, 2006 at 6:09 am
Amy, work that out among yourselves, I’ve deliberately and carefully removed myself from the discussion.
Posted by Paul Montgomery on September 14, 2006 at 6:18 am
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?
Posted by Kevin C. Tofel on September 14, 2006 at 6:43 am
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”. 😉
Posted by Costas on September 14, 2006 at 7:07 am
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).
Posted by Kevin Hinde on September 14, 2006 at 7:34 am
how about doing it like RSS autodiscovery i.e.
?
Posted by Kevin Hinde on September 14, 2006 at 7:40 am
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?
Posted by randymorin on September 14, 2006 at 7:53 am
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!
Posted by Johan van Rooyen on September 14, 2006 at 9:18 am
Toast of the town: Came across this in the printed version. 😉
http://technology.guardian.co.uk/weekly/story/0,,1871367,00.html
Posted by James Snell on September 14, 2006 at 9:30 am
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…)
…
Posted by James Snell on September 14, 2006 at 9:31 am
The markup didn’t come through, let’s try again..
<rss>
<channel>
<atom:link rel=”http://scripting.com/mobile”
type=”application/rss+xml” href=”…” />
…
Posted by Matt Terenzio on September 14, 2006 at 9:38 am
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. ; )
Posted by Mike Levin on September 14, 2006 at 10:58 am
I say graphicless Rivers are best, ala Nielsen.
Posted by Dave Winer on September 14, 2006 at 3:21 pm
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…
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 mobile.latimes.com – their twist on dealing with wireless readers.
Posted by etienne on September 14, 2006 at 5:59 pm
my girlfriend just said about the zune: “gross, I would never buy a microsoft one, even if it was better”
Posted by Gary Short on September 15, 2006 at 12:14 am
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.
Cheers,
Gary
http://www.garyshort.org/
Posted by Matt on September 15, 2006 at 12:31 am
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:linkelement, which works just likelink.Posted by James Snell on September 15, 2006 at 12:51 am
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 “http://scripting.com/mobile” 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.
<rss>
<channel>
<atom:link rel=”http://scripting.com/mobile”
type=”text/html”
href=”http://bbcriver.com/” />
…
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 “http://scripting.com/mobile”.
Posted by Roger Benningfield on September 15, 2006 at 1:18 am
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=”http://scripting.com/mobile” 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 scripting.com 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.
Posted by Dave Winer on September 15, 2006 at 5:53 am
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:linkis simpler (zero attributes instead fo three) and virtually self-documenting.We also need some idea of what makes a page “mobile-friendly.”
Posted by Matt Terenzio on September 15, 2006 at 7:02 am
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
Posted by James Snell on September 15, 2006 at 12:26 pm
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.
Posted by Bob Stepno on September 15, 2006 at 4:51 pm
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: http://tinyurl.com/n6xtd ]]
Posted by Dave Winer on September 16, 2006 at 8:10 am
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.
http://www.newsriver.org/howMobileRiversWork#couldYouPutAdsOnARiver
In fact the Times stories do have small ads on them.
The BBC is non-commercial and therefore doesn’t have ads on anything.
Posted by Matt Terenzio on September 16, 2006 at 12:49 pm
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. ; )
Posted by Bob Stepno on September 16, 2006 at 8:30 pm
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 http://www.nytmarketing.com/ That can’t be good for business!
Posted by Tim on September 17, 2006 at 2:54 am
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:
/mobile:link
and
/atom:link[@rel=”http://www.scripting.com/mobile”]
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 http://www.iana.org/assignments/link-relations.html 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?
Posted by Dave Winer on September 17, 2006 at 5:09 am
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.”
Posted by Tim on September 17, 2006 at 5:18 am
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?
Posted by Dave Winer on September 17, 2006 at 5:43 am
If you have a solution, tell us what it is. Please.
Posted by Tim on September 17, 2006 at 8:25 am
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 example.org/martha/ but if you want to visit the homepage on your handheld it is mobile.example.org/martha/? Or m.example.org/martha/? Or example.mobi/martha/? Or example.org/martha/mobile? Or marthasriver.com? 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.
Posted by Dave Winer on September 17, 2006 at 9:25 am
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…
Posted by Gustaf Erikson on September 17, 2006 at 10:01 am
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…
Posted by Matt Terenzio on September 17, 2006 at 2:11 pm
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.
Posted by Dave Winer on September 17, 2006 at 2:19 pm
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.
Posted by Matt on September 17, 2006 at 8:14 pm
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.
Posted by Sam Ruby on September 18, 2006 at 2:30 pm
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”.
Posted by Steve Williams on September 21, 2006 at 10:10 am
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 http://diggriver.com/ than it would be to make digg.com 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”
type=”text/html”
media=”handheld”
href=”http://…”
title=”Mobile/PDA”
We already recommend that as one approach for video thumbnails:
http://digg.com/tools/thumbnails
I’m interested to hear what you folks think of this idea: diggriver.com might apply the following strategies in order.
1. We’ll keep a list of sites like nytimes.com and bbc.co.uk, 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 diggriver.com.
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!
Posted by Steve Williams on September 21, 2006 at 10:33 am
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 nytimes.com and bbc.co.uk, 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.
Posted by Dave Winer on September 21, 2006 at 10:34 am
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?
Posted by Steve Williams on September 21, 2006 at 11:02 am
Dave, your link tag looks correct on http://scripting.com/, thanks!
But I think we need it on each of the permalink pages, too, e.g.
http://www.scripting.com/2006/09/21.html#When:11:16:48AM
Because those are the URLs folks submit to digg.
Whoops! That wouldn’t work with pda.scripting.com, which doesn’t have permalink pages!
You’d need to add permalink pages to pda.scripting.com (You’d probably want to change the permalinks on pda.scripting.com 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 pda.scripting.com.
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?)
Posted by Harold Gilchrist on September 21, 2006 at 11:49 am
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.
Posted by Steve Williams on September 22, 2006 at 6:26 am
Harold, I agree with you. When we talk about “mobile-friendly” pages, it could mean any number of things.
For example, we made diggriver.com 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?
Posted by Steve Williams on September 22, 2006 at 6:33 am
This morning, digg took two baby steps, which should be considered experimental:
– The digg.com 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 diggriver.com.
– diggriver.com now rewrites nytimes and bbc URLs in the same way as nytimesriver.com and bbcriver.com. (Thanks, Dave!) That’s essentially Number 2 in the strategy I described earlier:
diggriver.com 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!
Posted by Luca Mearelli on September 23, 2006 at 5:18 am
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).
Posted by Steve Williams on September 29, 2006 at 2:13 pm
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!