Category: Mobile

Will Apple share ownership of the webKit?

Android SDK has been released. There are videos that explain how the platform works and that the browser is based on the webKit. This was a bit of a surprise for me, I think I was not even considering that Google could go for something that is not Mozilla/Firefox.

Anyway I think this is great news and means that the webKit will keep growing and more sites will work on my Mac. Actually most sites already work, but sometimes I have to fire up Firefox or Camino, especially for AJAX-intensive sites.

Anyway, today, during Future of Mobile, I asked Dan Appelquist (another happy Mac user) if he thought Apple would let any other company take control of the core of the browser. My feeling, so far, is that Nokia is using the engine, but more in their own separate silo and not with Apple… And I have to admit this feeling is not because I think Nokia is evil and do not want to share, but actually because Apple wants to have full control on the browser and does not care to get changes and updates from Nokia!
Dan, on the other side, thought that Apple would have to let go a little bit of control on it so that Google and Nokia would get some space in the project.

Well, it looks like he knows what he’s talking about, see this post on Surfin’ Safari about Android committing changes to SVN.

Now I’m even happier.

RSS reader and sharing

I am a bit in a middle ground these days jumping from one reader to another and also between sharing my favorite articles between two different services.

I used NetNewsWire (a Mac RSS reader) for almost 2 years now and I’m very happy with it. Joining newsgator also gave me a web (2.0) interface for free that is nicely integrated with the client. Since I really don’t go very far without my notebook, I never used it.

Recently James Pearce brought to my attention the beauties of the mobile version of Google Reader. The mobile version is very simple and effective at the same time. Like most Google products, it does it’s job efficiently. I also enjoyed sharing my favourite articles via Google (and also temporarily embedded them in this blog).

Nevertheless, I could never find myself entirely comfortable in the web interface, especially when I am on an airplane with no connection (if the feed provide the full articles, I can read them even when offline).
Anyway, the reason why I tried Google reader was to be able to access the feed on my mobile. I tried to access the website of newsgator hoping to use it with Opera Mini, but unfortunately their interface is too advanced for a small screen. Browsing around the web site (probably the first time in at least 1 year) I discovered that thanks to the iPhone-wave, they have launched a mobile version. So thank you iPhone!
Now I’m happily back to my Mac-client, have a mobile version and even found a way to share my favourite articles.

But of course there’s always something that’s missing. How do I add to my shared items pages and links that are not in my regular feeds? I still haven’t discovered this. So here’s a news item I wanted to share:
Red Hat and Amazon Team Up for Enterprise-grade Cloud Computing

RSS feed about user-agent strings

A few days ago, thanks to a suggesting from Tim Cleminson @ M:Metrics, I slightly update the query page at http://t.wurfl.com/query/ .

First of all I think there was some confusion about the “last 10 user-agent string”. My intention was to show the last unique strings that were stored. This of course creates some problems to users that might want to check their headers, but actually have a device that was already registered on the system. I split the functionality in two, now and you can choose if you want either the last unique user-agent strings or the last that were recorded. I also raised the limit from 10 to 50.
Please note that user-agent strings and the rest of the headers are registered only if there was something new. If you visited the site and the full headers were already recorded you won’t appear as a new header anyway. It’s a rare combination that will happen almost only if you used the same device, the same gateway and so on, but it could still happen. Storing every single header is out of the scope of the site so I have no plans to add that.

A new feature that I added is the possibility to see these latest recorded headers in a nice RSS feed. I also added the convenient buttons to add to Google reader, My Yahoo or Newsgator.
The feeds are cached for 1 hour to lower the load.

Apple is clearly making money

Someone should probably create a statistic (I’m surprised there isn’t one, yet) that shows how lawsuits grow in number when company earnings grow.

I don’t agree with all Apple’s policies, but it’s a pity that many people try to make money out of them (and other big companies every day) with lawsuits.

See here new lawsuits against Apple.

mobileAJAX Workshop

On Sep 28 2007, in San Francisco, USA, the mobileAJAX workshop was held. I have not joined it, but it was good to read a couple of reports.

The W3C has published the official minutes of the meeting.

Also interesting to read the scratchpad used during the meeting.

I wonder where will (mobile) widgets go. I’m a bit skeptic. I think there’s much more than widgets to use AJAX. It wasn’t the main topic of the workshop but seems like it was one of the main points.

iPhone: The Web Browser is the only user interface

I was reading this article @AppleInsider and thought that if Apple is thinking about extending Javascript to allow applications to access more of the features of the device and is going to provide more visibility for Web-apps, then maybe they think that the iPhone is a Web-appliance. This means that the iPhone is a pocket-web browser. It’s not a device to build applications for.

There are so many services that have moved from their original interface to a web interface. If you can use Javascript to access information on the device and you can store data on the filesystem (like Google Gears already offers) then why do you need to build your own UI?
See this older post I made on a similar topic and I think this rumor, if true, would confirm.

Google’s GWT

Transcoding is a hot topic these days in the mobile community. Google’s GWT has come up a couple of times in some conversations I had in the last 2-3 weeks. I never wondered how they decide to transcode or not, anyway.
I gave it a shot today using cURL and an emulator to get access to some devices quickly.

How I did it
I got on http://www.google.com/m and searched for “WURFL test”; I left the default “Web” setting. As expected my http://t.wurfl.com was the first link. I clicked on it and got to the page, the layout was unchanged, but that’s not a surprise, it’s so simple. Scrolling down I noticed that the user-agent string is not my phone’s, but an ugly generic MSIE user-agent string. Scrolling down a bit more I noticed the standard chrome provided by GWT that lets you disable images or request the page in the original source.

The solution
I sent an e-mail to Sean Owen, who is in the W3C MWI with me. Surprisingly he replied on a Sunday and was very helpful. He explained me how their crawler is able to mark mobile sites and make sure the GWT will not transcode anything. The problem is that at the moment this magic feature is available in the US only and will be rolled out to the world soon. Since I left “Web” in my search I got the web version of my site (t.wurfl.com has a very basic device detection that provides different markup based on the Accept headers). US users should already get the mobile version of t.wurfl.com. Anyway, Sean also suggested a trick that now provides the mobile version to all mobile users without any other update required. I added the following tag in the head of the page:
<link rel=”alternate” media=”handheld” href=”http://t.wurfl.com/index.php”&gt;

Seconds after the update I requested again the page with the emulator and got the mobile version.

PS: if you want to get a mobile page using cURL you can do this:
curl -D – -A “Nokia6600” “http://www.google.com/gwt/n?u=t.wurfl.com/&#8221;

You will see the page source and the HTTP headers sent by the server. Read the manual for more commands, cURL is super-powerful!

Are transcoding proxies needed on the mobile?

Most users have never used the mobile web, in some cases they have downloaded a few ringtones, a wallpaper or a java game. The operator portals are the still the first and probably only site that the average user has ever visited. Sometimes some brave individual looks for adventures and surpasses the borders of his operator portal. These users either know exactly what they want and know the URL or don’t have any idea of what they can find. Users who don’t know what they can find will go to some search engine like Google or Yahoo! (hardly the mobile versions) and type a keyword such as “tennis”. They will get a list of links and follow them. There are very good chances that they will reach a web site that doesn’t even take into consideration the possibility that a user with a mobile phone will visit and is not doing any device detection or content adaptation.
If this is case, and unfortunately still is for most sites, there are two chances, either the user has a really smart browser like Opera Mini or Nokia’s webKit-based browser, or he will download a huge page that he will not be able to read. After 2 or 3 different sites have been tested, users will be discouraged and will not take the risk of going out of the operator’s portal ever again.

Operators should be happy about this and try to disincentivate browsing outside of the portal. On the other hand, browsing means traffic, traffic means money, so accessing the “full web” can be a positive thing for mobile operators too. If browsing can be a revenue stream you don’t want your users to be discouraged, you want them to have a taste of what they can get on their mobiles.
Opera Mini is one possible solution, transcoding is the other. Google offers transcoding automatically, operators might choose to get their own transcoding software. The result is that users get what they want (the tennis site), operators get what they want, money from data traffic. Looks like a win-win solution.

Within some limits, this is effectively a win-win solution. The limits are defined by the user experience that the transcoding engine can provide. It is proven that transcoding a web page and fitting it into the small screen of a mobile device will not provide the best user experience, nevertheless it is still better than a kick in the teeth (like the average rendering of a full web site on a Motorola V3).
Transcoding is like a shortcut to get more users on the mobile web. Major web sites should consider developing a mobile version quickly simply because mobile is the future. At the same time there is a number of sites that will never be converted (think of all the geocities pages!) and there are many minor sites that will consider mobile only in 3 or 5 years from now. We do want users to be able to find information on the mobile today, don’t we?
Transcoding engines must be smart enough to recognize sites that are made for the mobiles and leave the content as is and convert the content only when this will not fit the features of the mobile device (or set-top-box). Transcoding engines should be smart and act when needed and never get in the way, they must be an extra tool, not a mousetrap that gets in the way of the developers and designers that are sweating to produce content that is optimized for mobiles. Transcoding the content of a site that was made for mobiles will most likely break the usability and optimizations that the designer put in place.

At the same time, users should be educated that there is a lot of information for them on the internet and that they should be looking and asking for mobile versions. We should not expect the average user to understand mark-ups, XHTML-MP [PDF], transcoding, image rescaling, but they do understand when a page is not usable on their mobile and if they can’t find anything interesting, they won’t come back.