One thing that pretty much everybody seems to agree on is that browsing the Web on mobile phones isn’t what it should be, The disagreement comes in on what to do about it. One the one hand, you’ve got people pointing to the content as the problem, offering up the .mobi domain as a zone for mobile-specific content. On the other, you’ve got mobile browsers that aim to deliver a desktop-like experience, such as Opera, and Minimo — the release of a preview version of that this week having spawned this line of thought. (There are also proxy services to consider, like Google Mobile or AOL’s new mobile search, but I think they’re generally fairly frustrating and useless, so I’ll leave them out).
So, basically, what should change? Should sites adapt to the user, or should we all just get Opera? While I’m interested in finding the right answer from the publisher/content provider side as well, I’m going to focus on the user experience here. My primary concern (and frustration) as a user is being able to find the right content. Knowing where to go for mobile content can be a real problem, as it always has been. There was never a standard for where to find mobile-formatted content: wap.site.com. site.com/wap, site.com/mobile, mobile.site.com, even the ill-fated mmm.site com idea. That’s assuming the URL had any sense to it at all: ESPN’s mobile-formatted site sits at http://pocket.espn.go.com/ or http://proxy.espn.go.com/wireless/espn/html/pocketpc. How the hell am I supposed to find and/or remember that?
The .mobi idea is to have something like ESPN.mobi. That makes some sense, but how do I know which sites support it and which don’t? I guess I’m just supposed to check through trial and error. Using a browser like Opera’s got a simpler solution: I just punch in espn.com like on the desktop. The page loads, sure (though I get a memory full error), and the browsers got some nice technology to render pages for the small screen. But the result isn’t always real pretty.
The second issue is what content’s there. I’ve got certain things I’ve grown accustomed to seeing or using on certain sites when I access them from my desktop, and it’s not unreasonable — or at least it shouldn’t be — to expect them to be available on my mobile too. An advanced browser promises to give you everything on a site. With the mobile-specific content of .mobi, that’s less clear. This is what Tim Berners-Lee was talking about when he came out against .mobi because it promises to create device-specific areas of the web.
So I guess the score is 1-1, indicating the solution’s somewhere in the middle. While I think .mobi is a pretty stupid idea, it does highlight the need to make it easier for mobile users to find relevant content. But why not just have sites sniff what kind of browser or device is being used and change what’s displayed? On the other hand, just having a powerful HTML-capable browser is nice, but it creates a fair amount of usability issues.
The way forward: give me a browser that can handle whatever I throw at it, but make sites a little more friendly by realizing that I’m on a mobile device and don’t have a 1600×1200 display. Design the mobile site so it’s easier to use, but don’t cut out services and content I can access on the desktop. Don’t corral me over on one small part of the Internet, either — walling me into a garden will just annoy me.
Neither having a great HTML browser on a phone nor having a bastardized “mobile-optimized” site alone is the ideal solution, and asking for both isn’t unreasonable. But until phone vendors and carriers on one side make browsers a real priority and content providers on the other side begin to understand and respect mobile users, the mobile Net will continue to suffer by not meeting average Joe Users’ expectations of the Web.
Heh, noticed just as I was publishing that I’m not the only person thinking along these lines today — Russell Beattie’s got a nice post on reformatting vs. rethinking for mobile.
There is no way this situation can be fixed right now. This was something that should have been prevented by W3C years ago with the inclusion of a mandatory useragent-alike information that the device should send to the client where the resolution of the device and 2-3 more important other things are included in it (no, WURFL is no good as it is today). And then, based on this information the web masters would easily extract it and serve the right pages.
Instead, the way it has to be done today is the web master himself must literally HUNT for mobile user agents and then serve the right mobile pages to these browsers.
At OSNews I spent a few months to find all the major keywords that would prove if a browser is a mobile one or not. Right now, I have support for 120 such browsers. And based on this information, I either serve the mobile html page, the WAP page or the desktop one. All automatically.
However, this was quite some work to not only gather these keywords, but to also test with most of them. There are no emulators for all devices, I had to actually buy a lot of the devices to test my sites on. But it is a work that has been paid off as OSNews serves more about 4,000 mobile pages per day, out of the 275,000 ones it does overall daily.
Can it really be so hard to do some auto-discovery of the mobile URL, a-la RSS feeds? Yes, you might have to pull down a whole home page; but that’s what proxies are for, yes?
Thing is, the existing browsers must support this feature. And there is another problem with this too: the browser has to first download the normal page and then redirect. This can’t work because many mobile browsers crap out on more than 16 KBs of web pages (images inclujded).
This should have been an http extension instead, and it should have already happened. Now, it’s too late. There are 100 mobile browsers out there that they will never be updated for it.
Exactly, and because there are so much browserstypes out there plus zillions of websites, wouldn’t it be great to have some kind of middleware that would transform any webcontent into the right mobile format using useragent profiling? Well, there is, it’s called Filtering Integration Technology (FIT) and has mobilized services like mobile banking for Deutsche Postbank and Wikipedia. Could this be the solution for the everlasting mobile discussion? I think so…
Most mobile application developers are concentrating on advanced platforms as the S60 - Nokia has done a great job promoting it and has awesome developer programs.
But in the U.S. at least, S60 penetrations is something like 0.2%. If you want to reach the masses today (and maybe next 5 years), whether it’s an application or a mobile web site, you have no other choice than to get the crappiest “$0″ phone out there and make your thing work on that.
My bet will be on using just one address and automatically adapting that to the what ever browser or phone you are using. If you go to http://www.ibm.com or http://www.weather.com with Firefox, you get the full HTML site - if you go there with your phone you get the WML site. It doesn’t always work as planned but the point is that the consumer shouldn’t be confused with new URLs when there’s another ways to work it around.
Juhani