The Web, in its purest form - declarative HTML and CSS documents, XML feeds - is mashable, linkable, sharable. It's easy to create documents that slot into the global Web and can be accessed on any device; accessed by just a simple link. Servers can easily scale through statelessness and cacheing.
Native Mobile Apps are fast and slick. They are intimate with the dynamic, interactive, tactile mobile user interface, intimate with the capabilities of the device and intimate with the domain of mobile: photos, locations, contacts, messages.
OTS is a simple, clean, powerful approach to delivering Mobile functionality and content that is designed to realise these benefits of both Native Apps and the Web.
How OTS Works
OTS - Object Type Specifications - achieves this by defining open JSON object types for people, places, dates, photos, messages, feeds, lists, galleries, user interfaces, forms, maps, calendars, etc., all linked together into the Web.
These dynamic OTS objects are published or shared instead of native apps and instead of Web documents.
A native OTS mobile client for Android, iOS, etc. can then render those objects and allow the user to interact with them, using its understanding of what they mean to deliver a slick user experience.
The user will start with the link of an object to look at, then may see immediately-linked objects nested into the same view, perhaps summarised and/or with open/close sliders. Any linked object can be jumped to as the new top view. If an object being viewed updates, the view, or the corresponding part of the view, updates.
Indeed, you are an OTS object, that others can see, and that gives access to stuff you want to make public from your device, such as photos you've only just snapped, your current location if enabled, status and text messages, selected contacts, links of interest, etc. SMS and MMS will be mapped to OTS photo and message objects on your device.
Your user object and your shared stuff are automatically pushed to shared servers when you make them public or when they update. All of this could use contacts, photos, reviews, messages, etc., from your and others' Twitter, Facebook, Google, etc. accounts, adapted to OTS objects server-side.
Many applications can be built through simply wiring up some OTS objects. Indeed, you can do this yourself through the mobile client, including creating and publishing new objects and lists of existing objects. You can plot on a shared map any OTS object that has a location field, or lists of such objects all at once.
Such as lists of your contacts or friends - to watch your party on the map as it converges on the restaurant, perhaps. That restaurant may be publishing an OTS object describing its outdoor Jazz schedule this week, which can be plotted on a shared calendar along with the weather report objects, retrieved from another server. If you discover a list of review objects about the Jazz via an OTS search form, you can save the link and then instantly share it with your party.
If your friend takes a photo, you can instantly 'join them on the map' where they stand and chat about it - and the weather conditions they're experiencing. No need for them to upload to a photo-sharing site, with login and file finder dialogues, or for you to download and launch separate, unrelated chat, photo-sharing, map and weather apps.
Programming OTS in Fjord
None of the above would need any code to be downloaded and run on the device. It's interesting to notice just how much can be achieved simply by leveraging the client's understanding of the object semantics, and through generic declarative interactions with points in the dynamic Web of OTS objects. With object cacheing, once the objects needed have been seen once, the user can still use them when the network breaks, alongside the on-board objects.
Well, being based on the FOREST architecture, OTS would use Fjord as its declarative programming language. And Fjord is just another OTS JSON object type, that can be fetched along with the objects it animates, for on-device program execution.
Server-side, again, so much can be achieved simply by publishing OTS objects, and adapting existing services. For more interactive applications, behaviour could be programmed in Java, etc., against a FOREST declarative API, or again in Fjord.
NetMash and Fjord Development
NetMash, as well as being the Java reference implementation for FOREST - networking, persistence, declarative API and Fjord implementation - is also an Android app that forms the reference implementation for OTS.
Fjord is very much in flux and hasn't been updated to the latest way FOREST works, but a version of it I built on Node.js has worked as expected. Based on that work, NetMash should have a Fjord implementation this year, which, being in Java, will thereby be available on both the Android client and the server side.
So, as always, it's all coming along slowly, and I can always use help with all this. Ping me via email (see left bar) if you want to be involved in the OTS Mobile Revolution!
Applications and content built with OTS don't need to be downloaded or updated via app-stores, and have no app boundaries - all applications can build on one another. They share one user, one map, one calendar, one combined view of the on-device and on-line world of interlinked, dynamic mobile objects from multiple sources. Your, and your friends', location, message, photo, list, contact and date objects are pushed and pulled automatically when made public or when they change.
As Martin Fowler points out, there is a gulf between native and Web applications on mobile that seems like an "uncanny valley" when you attempt to work within it by patching up the differences with hybrid technologies that pull too hard away from the respective comfort zones of pure native or pure Web.
OTS is a clean alternative that effectively brings native and Web closer together, thus squeezing out this "uncanny valley" discomfort zone. Being both a native mobile app and a first-class player in the Web, OTS brings out the best of both, then goes beyond either.