Developing ( Mobile)



About a month or two ago I took on the task of developing the mobile( For those of you that don’t know. I work for A Job Portal like no other. We do a lot of cool stuff. A topic for a whole ‘nother post. With the barrage of mobile web frameworks out there it was easy to make a decision on which one to use. Non of them. I’m a fan of mobile frameworks but I believe they have their place on the mobile web. They are perfect for “mobile web applications” where your target is more likely smart phone users(iPhone, Androids). But we decided to target your everyday Tom, Dick and Harry. Or is it Thabo, Pule and Jabu. Whatever your school of thought. But at the same time you don’t want to compromise your high end user’s experience.


No Javascript(Zero, Non)
Well except for the registration page. We used javascript to try and get your current location(From your GPS) so you don’t have to go and search through the drop down for your location. Works pretty well especially if your GPS is enabled.

No device capability detection
There is no device capability detection libraries like Wurfl or Device Atlas. These are really awesome tools. I’ve only ever used Wurfl in the past. It gives you all kinds of details from screen width to supported images. But I personally think if you can do it without them then do it. So the approach I took was to develop an “adaptive site”. So instead of trying to get the device’s width and adjust time the web pages width, I simple gave it a width of 100%. Which means it will grow and shrink with the device.

Geolocation API
The Geolocation API can be used to locate devices. But obviously it will request permission from the user. This was used in the registration page to automatically select your location. Of-cause this assumes you are currently in the area where you live. Which is probably untrue. But any excuse to play with the API. 🙂 This is the only javascript that was used on the site.

Relative measures
There are no absolute measures like px, pt and so forth. The problem with these measures is that 1px to a Nokia’s screen will not look the same as 1px on an iPhone’s screen. So all dimensions are defined using the em unit of measurement. This means that the font-size will be defined in relation to the device its being viewed on. 1em the default size. For example, most web browsers(firefox, ie) default to 16px=1em

Tried our best to avoid images unless absolutely necessary, opting to use CSS creatively instead. On the home page only 2 images load. The logo, and rounded navigation bar, even that is a 1px wide images repeated using CSS(338bytes). The image dimensions are also defined using ems.
NOTE: Also playing around with DATA-URIs to reduce the number of requests on the home page from 4 to 2. This would result in a significant reduction in loading time but possibly an increase on the page size. The problem at the moment is that some phones just don’t support them.

UX Design
User experience is a HUGE thing for me. I love websites where as soon as hit the page, I know what the current state of the system is, what other states can be achieved and how these states can be achieved. I think we managed to achieve simplicity and didn’t compromise too much on functionality.

No Mobile frameworks
Firstly let me just clarify, I love Jquery mobile, its brilliant. But its also Beta. Beta 2 at the time of writing. My biggest issue is that it doesn’t degrade as gracefully as it should. So your non smart phone users are loosing out on the experience. So the one solution is to have multiple sites. Which Facebook did for a long time, until they realised some of the flaws in that architecture. With one code base you can roll out new features to all devices. Which enables you to be more creative.

So go ahead and play around on

This is a very draft post. Will be adding more stuff soon. Just wanted to get it out of the way or else I’d never write it 🙂

About the author

Talifhani Luvhengo

A collection of particles named Tali Luvhengo


    • Thanks Tshepo. Feedback is always appreciated. I see you’ve changed your blog design as well. Looking good. Appreciate the content as well.

      Meshack, Cool name.
      Sub domain decision was due to the fact that people are already used to the m. subdomain. Facebook does it, Twitter does it, Google does it. So people have been trained to associate m. with the mobile version of a site. Sometimes I even type m.sitename on sites that i dont know have a mobile version just to check. Didnt want to go against convention. And also was taken. But i think m. is still a better choice over .mobi. easier to remember.

  • Two thumbs up on the mobile site. I’m impressed by your practices, especially “no javascript/framework”. I’m a big fan of good mobile experience, which is why I avoid flash in my development (topic for another post)

    Some people have issues with developing m. and mobile. Sub domain content serving. What’s your take on that? What made you decide to use a sub domain.

  • Indeed.

    Thanks for dropping by on my blog too, saw your comment and quickly checked out your blog and read your posts. Keep the awesome work going, Real developers appreciate such work, beyond the naked eye. At Code of Conduct level 🙂

    *You have been Bookmarked*




Page optimized by WP Minify WordPress Plugin