While developing our web app, which we hope to unveil this summer, we felt from the very beginning that we needed to reach out to mobile device users. So after a few months of hammering away at our web version, we feel it’s time to start working on the mobile side of things.
Taking advantage of some theoretical work for a university subject on user interfaces, I was able to gather some knowledge about the current state of the so-called mobile web. And from what I learnt, for us it pretty much boils down to picking one of two options, which are a) a mobile version of the website, which would be accessible through a URL using the device browser of choice or b) a stand-alone application, such as a Java MIDlet.
Both have pros and cons but we decided to stick with the latter. The support for handheld CSS seems to be crafty these days and I guess we’ve already had too much headaches with regular web browsers to plunge into building a mobile web site. Moreover, our conceptual model for the mobile app fits rather more naturally in a stand-alone app, basically because one of our primary goals is to depend a bare minimum on network connectivity. We want data to be synchronized with our server on demand and only then do we need the link. So, forcing our users to rely on network access to even use the app in the first place seems wasteful and uncalled for, no matter how coverage has been and will be improving over the next couple of years.
We still need to cover a lot of theoretical ground before we’re able to even think of pulling this off successfully - for instance, we’re pretty much clueless about SymbianOS support. But for now, I think we’ve laid the conceptual foundation of an interesting side kick for our web app which may - or may not - tell how successful it can ultimately be.