Javia blog

I am a big fun of having the web’s huge and rich information available on mobile phones — it is really useful for the user to be able to browse the web with the mobile phone’s browser.

Some time ago I was wondering how this ‘mobile browsing’ experience can be improved, and at that point I was thinking that server-side page adaptation is the answer. In this approach, the web application generating the pages uses techniques such as User-Agent sniffing to detect that the client is a mobile phone, and returns a page specially-tailored for a mobile browser.

But now I realize that this approach is fundamentally flawed. It puts the burden on the web application developer to generate two parallel sets of outputs (one for desktop, one for mobile), and the hard part is keeping these two in sync. The problem is that the mobile version will get behind the desktop version, and the mobile user may be put in the paradoxical situation of wanting to browse the desktop version rather than the mobile version.

And the technology advances: my old mobile phone had a 128×128 screen, but now 240×320 is the norm for feature-phones (a feature-phone is the phone that is not as smart as a smart-phone). And the IPhone has a large QVGA screen (320×480). Such devices come closer and closer to displaying normal web pages, so the content-adaptation becomes less critical.

The solution that I see now is different: forget content-adaptation — instead design a single set of content, but take into consideration that a (growing) percentage of the users will be browsing from a mobile phone. So: keep the pages clean and streamlined, favour text instead of large graphics (text scales better), and keep the page size small.

Because the data connection on a mobile phone is slow, and often costs by amount of data transferred (not flat fee as on the desktop), it is important to keep the (total) page size small. This will greatly improve the browsing experience on the mobile phone.

In history there was a moment when most users were connected to the internet through a modem, with a maximum speed of about 5 KBytes/s. At that point, there was a lot of advice on the web on the lines of: keep the size of your web page under 10 KBytes — it would take so and so many seconds to download a web page of that size over the modem, etc.

I think it would be a good mind-set for present day web developers if they imagined that 20% of their users… are connected to the internet through modems again. So, forget the 1MByte (including images, ajax libraries, etc) web page, cause it takes 200 seconds to download it over the modem.

It’s true though, this new modem is getting faster…

Disclaimer: This blog expresses solely my own personal opinion — it is not endorsed by and does not represent the opinion of my employer.

I’ve just seen the new web application Jottit, and I liked the way they get simplicity right.

Because simplicity and elegance is not only in the way it looks, but also: in the size of the web pages, in the URL naming scheme, and most importantly in the interaction design.

About the web page size, do you know many sites with under-1KB size pages? To compare, what about sites with over-100KB size pages? Why would size matter — because more people are browsing the web on mobile phones; but also because simplicity and elegance mean minimalism, i.e. not to put on a page stuff that’s not needed. It doesn’t matter that the slack is not visible because it’s hidden inside the HTML source, having an unnecessarily large page is still a violation.

The URL naming scheme is of paramount importance, yet it’s surprising how much developers aren’t aware of this. I created a test page on Jottit, and it has the URL http://javia.jottit.com/. You can’t get the URL simpler than this. The URL must be short, semantic, and without arbitrary, meaningless parts in it. If you have to put some data key somewhere (in the URL or in a Cookie) make it short! Look at Jottit, when they put a page-code in the URL, it has 4 characters: http://jottit.com/xy4v/ .

Let’s compare: I was recently looking for where to host an open source project. Sourceforge.net is the venerable site, and I have respect for the good they did for many open-source projects, but the site IMO sucks. It is as complicated as it can get! I think they worked hard to put as much stuff as possible on as many pages as possible. And one of the smaller details: they also own the domain name sf.net, which only redirects to sourceforge.net. I can’t begin to understand why, having such an incredibly valuable domain name available, the 2-letter SF.net, they don’t use it. If my project was named let’s say “foo”, I’d love a domain name like “foo.sf.net”.

Google Code Project Hosting (I hope I got the official name right) is a breeze compared to Sourceforge, it is much simpler. Much better. I’d recommend GCPH (Google Code Project Hosting) to anybody over Sourceforge, if only for all the hassle you save yourself when creating a new project. Yet GCPH si far from perfect: they don’t get the URL naming scheme! Let’s consider a project named “menstral”, it will have this URL: http://code.google.com/p/menstral/, and the subversion repository URL http://menstral.googlecode.com/svn/. The problems with these URL names is: 2 different domain names (code.google.com and googlecode.com) inside a single project, and the redundant and arbitrary “p” in the project’s main URL. The URL for the project should have been http://menstral.googlecode.com.

The conclusion: bravo to Jottit for setting a new standarnd in simplicity and giving us an example. And I have a feature request for them: get HTTPS to work on all pages.