Hey, website developers! Give me a standard mobile URL please!

*sigh* Why can’t web developers agree on a standard naming convention for accessing mobile-device friendly pages?!?!

Tonight I was trying to search on Amazon for a book from my iPAQ h6315. The full interface was frustrating and slow, so I wanted to find one friendlier to mobile devices. I tried mobile.amazon.com, wap.amazon.com, www.amazon.com/mobile, etc. No dice.

Finally, I searched their help and there, in an obscure FAQ entry, I located my goal: www.amazon.com/pocketpc ! Like that was intuitive…

To Amazon’s credit, they do have a nice looking mobile interface. In fact, the shopping cart is shared with the desktop version of the site.


Here are what sites need to do to be friendlier to devices (in decreasing order of preference):

1. Detect my browser type and redirect me to whatever your mobile device friendly home page is.

2. Provide a standard URL for mobile device users so we all know what to ask for. I suggest mobile.yoursite.com

3. Provide SOME kind of link on your home page - as in “mobile users click here”

What do you think?

Comments (8)

  1. Jeff Parker says:

    Well I don’t know about a standard URL, that wouldn’t be good, would confuse the millions of people surfing the web that don’t know what a URL is and trust me there are millions of them.

    However the real sollution is Number 1

    Detect the browser and redirect you which any good web developer worth his salt should be doing anyway.

    This is not hard to do, in fact it is built into the .net framework. No more old browser agent string parsing.

    Copied from the IBuySpy Portal SDK from Microsoft. Very first page example of good developer practices.

    if (Request.Browser["IsMobileDevice"] == "true" )








    While not everyone uses .net it could still be done in any language even old CGI and perl. Blame the poor developer practices on the site not a lack of standard.

  2. John Dowdell says:

    Good problem, thanks. I’d be leery of per-site client detection, just because it’s so snafu-able.

    But there’s already precedent in a similar realm, when XML (RSS) clients access an HTML page and find a "rel link" (sp?) in the HTML HEAD, which the client can then follow to find the accessible version. (My connection is spotty right now and I can’t search the syntax… search terms like "rss autodiscovery" should reveal it.) This way the site provides what it knows, the client handles its own responsibilities, and we don’t have to worry about zillions of sites correctly detecting zillions of clients.

    Hmm, let me stress this — with the Macromedia Flash Player I’ve seen *tons* of poor handrolled detection schemes, and I’d hate for the same decentralized responsibility to go mobile. Better for each player to handle their own realm than to attempt to handle other people’s work. Does this concern seem sound to you…?


    John Dowdell

    Macromedia support

  3. JD on MX says:

    Mobile autodiscovery: Glen Gordon of Microsoft raises a good question, about being able to easily locate appropriate versions of web content from mobile devices. Suppose you’re using a pocket browser and visit a new online bookstore… how can you avoid…

  4. Jeff Parker says:

    I guess to me the easiest way to do this is is have the site detect it. We have been doing this for years now. HTTP Standards the browsing angent and the operating system are sent with the HTTP request to the server.

    Like I said for years we have been doing this, determining on the server if the client is coming in via Netscape, or IE, or something else then present them with the dynamically generated HTML from the server specific to their browser.

    The Information passed in the http streams has everything you need to know both client and server side. I am not going to get into detail on the http streams but as an example http://news.netcraft.com/ use the what is that site running. It just simlpy queries the site and gets an http response back from the server. It also sends one. The http stream specifics never change. Otherwise your client and your server wouldn’t be able to comunicate with each other This information is passed each and every page request. Now can someone change their http settings. Yes they can, you have to really dig in to code and the registry change it, however if someone just wants to change it to think they are cool well then they pay the price of being inaccessable. They have corrupted the standard stream.

    But just looking at the information passed in the http stream from IE or Firefox, from a windows machine any version. I can tell they are running Windows. I can tell what version. I can tell what browser. I can tell what version, I can even tell you what all versions of the .net framework are installed if any.

    Now same goes for Unix and Linux and the mac, CE, what ever else they all send their information and recieve back from the server.

    http has been there and defined as a standard since 1992.


    The User Agent(Firefox, Mozilla, MSIE, etc) is also defined in that spec from 1992 as part of the header information sent with an http message.


    So basically in the standards for http this is defined. I still say it is up to the developer of the website to detect this and present the correct material to the user. Users should not have to think if they are at the right spot or using the correct language or if their device works or not. When I refer to developer I am not talking about someone that throws up a front page or dreamweaver site and says he look I am a web master. I am talking about the guys that know how the web is really supposed to work. Guys like the developers for Amazon.com, Microsoft.com, cnn.com and so on.

    Thoughts? I don’t see where this is that hard to do it has worked fine for me for years and yeah I used to have to manually parse this all out of the stream, but now this has been built into the .net framework as well. they are basically doing the same thing parsing the stream they just go if for me now.


  5. Randy says:

    I wrote an ISAPI DLL that used to break down redirection to the following logic:


    Pocket PC

    Handheld PC

    Palm VII (dated, true)

    RIM Browsers

    HDML Phone (also dated)

    WAP Phone

    We had different pages that were designed to support each of these "platforms" and anything that wasn’t specifically supported fell into one of these. FOr example, RIM and Palm’s browsers only had vertical scrolling and not Horizonal, but Palm could hand grayscaling.

    The only thing it takes is a check on both the browers type and the HTTP accepting tag – you can’t get by with just one of them, it has to be both: a majority of these browsers lied about their capabilities on HTTP requests. They would say */* is accepted, which of course never worked: send a WAP phone an HTML page and it chokes.

    Anyway, the company I was with that cared about this is long since gone, but the idea remains the same – it’s just that most webmasters don’t care about it.

  6. rolandog says:

    Excelent point you are raising. I’m moving my blog from blogspot to my own filehost, but apparently I’m going to need to learn automatic redirection.

    It’s a loooooong way till I get there, but when I get there, it’s going to be cool.

    For web developers, you can use a javascript emulator of a cell phone: <a href="http://pukupi.com/tools/mimic/">cell phone emulator</a>.

    So far, I decided that I first needed to validate my page… so far, <a href="http://rolandog.swifthost.net">so good</a>

Skip to main content