- Posts tagged distribution
- Explore distribution on posterous
Web development is changing to meet mobile needs
Since the I-Phone's release, the "general public" has been switched on to mobile computing in a new way. Previously expensive, high end, "smart phones"/mobile-devices were marketed to business users and geeks. Now the landscape has changed: devices are springing up from many manufacturers and Apple’s App Store model is popular across the board.
It seems logical that, as these devices become more widely used, the way users interact with web services will incorporate the mobile platform as a core method of interaction.
Next time I'm building a new service that needs to be accessible on multiple platforms I think it would make sense to build an API before a website. Until recently I've planned projects around browser based distribution, now the browser may become less dominant.
Having useful services open to many developers over an API will aid proliferation of the tool. Developers would be free to provide the applications for the various platforms (as Twitter have done, I suppose that's why the next step on from "hello world" is becoming the Twitter client on many SDK tutorials). I know this is nothing new, but as mobile becomes more embedded into daily life: the way developers build services on the web will need to shift to accommodate it.
This isn't really a "proper post" more of a stream of consciousness; I'm about to make the shift from Web Developer to Mobile Developer and am very excited about the new possibilities.
Goodbye Browsers: What Next?
It has been mooted fairly often: that the web may be breaking free from the browser, and I'm enclined to agree. So what does this mean to developers and how will this effect the web development process (and my first Erlang Web App)?
I'm currently upgrading a site that will need dynamic elements and interactivety intertwined with flat HTML files in a standard directory structure. During the technical design process it is also becomming apparent that these dynamic features will need to be distributed over various media and platforms.
None of these are unusual requirements and I've been developing similar projects for a number of years. However, my approach is beggining to change. Previously I would have built the whole system with my PHP framework of choice (CakePHP) and used it's inbuilt Views to publish the content in various formats (e.g. HTML and RSS), I'm now rethinking.
Our content needs to spread onto the ever widening array of platforms and media, so our publishing methods need to become more flexible. The solution I'm favouring is to publish content over some sort of web service or API and have the client platform, what ever it may be, interpret (and possibly redistribute) it. The RDF Standard is one format that is gaining popularity, especially as semantic technologies become more mainstream.
These principals are probably further advanced in the realm of Web Applications: it is becoming common place to produce an API allowing other platforms to interact with them. Turning the app into a platform (via an API) allows other's to build on top in turn engraining it into their business model (For example Good Baad relies on 5 or 6 different APIs). Google have been providing useful APIs for years and the results are plain to see.
It seem likely to me that the development process may change as a result. Currently an web app or content is built first as a website and then expanded into and API or feed. It seems more practical to build the API first and then this can be adapted to other platforms.
For example: I moved my blog consumption to Google Reader, now I rarely see the sites that the content originates from; I interact with blogs entirely via their RSS feed over the platform of my choosing. With web applications it seems like the same is becoming true, very few people interact with Twitter directly, but prefer to interact via the API (3rd party apps is one key to their phenomenal growth). And, if concepts like Ubiquity take hold: the web may break free of the browser entirely.
And this brings me around to my Erlang project: I'm still mulling over ideas, but it seems to me that a real-time app that is purely an API would be a very good first project. Also, Erlang seems very well suited to the Web API building task, e.g: from a data distribution view point Couch DB is pretty much all you need.
Over the next few weeks I'll build a simple Erlang app that interacts with the web over an API, it's possible I won't need to worry about building a client at all.
