1. Open source augmented reality development is currently limited, with most projects being sketches, libraries or utilities rather than full clients.
2. Platform fragmentation across mobile operating systems and a lack of content and interface standards have hindered the development of open source augmented reality applications.
3. Existing web standards like HTML5 could be extended for augmented reality rather than creating new specifications to help drive more development while respecting current architectures.
2. Open source AR in the wild Stats Google Code: 104 SourceForge: 37 GitHub: ~75 Mostly sketches, ARToolkit projects, libs and utilities Not seeing many full clients
7. Barriers to open source Walled gardens/silos Fragmentation Android 1.5, 1.6, 2.0, 2.1,2.2 apps vary across carriers Apple iPhone, iPod Touch, iPad iPad video out, determined by application
12. The UI Problem “In different apps, touching a picture could produce any of the following 5 results: Nothing happens Enlarging the picture Hyperlinking to a more detailed page about that item Flipping the image to reveal additional pictures in the same place (metaphorically, these new pictures are "on the back side" of the original picture) Popping up a set of navigation choices” from Jakob Nielsen,iPad Usability: First Findings From User Testing (http://www.useit.com/alertbox/ipad.html)
16. Going forward Use existing standards, extend when necessary Use existing projects, extend - don’t reinvent Iterate quickly, make lots of prototypes Respect today’s architectures, plan for the future architectures
Stats were gathered from searches on repositories using the term “augmented reality” A quick survey of major code repositories reveal few complete AR browser clients
As with other mobile applications there is a tension between native applications for mobile devices and web applications
Currently native apps dominate the AR browser space: Layar, Junaio, Wikitude, and open source browser Mixare Native apps offer the benefits of access to sensors (compass, gps, accelerometer, and video) on the mobile device Developers can build a custom and tailored experience for users
Directly sharing data streams/channels (content) between native applications is not possible While many AR providers provide an API for authoring content, this is not an open ecosystem The problem of fragmentation affects both major mobile smart phone devices, software must be tweaked for each version of the OS or device
Web apps can currently access geolocation through HTML5, but they can not access the phone’s sensors A dev version of Android demoed at Google I/O 2010 showed the browser accessing the accelerometer, but these features could take several years to be implemented in a production version
currently AR Browsers based on a web application does not exist
however, the Kamra system (possible release summer 2010) is an AR browser using HTML5 and KML
AR content varies widely from POI annotation, virtual objects representing real word objects, and completely virtually objects
Excerpt from Jakob Nielsen’s report iniPad usability testing, AR applications face the same hurdles
Standards provide a way forward for developers they act as a growth medium for emerging industries
There are many standards to choose from that cover several domains these domains include data transport, 3D object formats, geo location, as well as methods for transactions
Even with standards, AR experiences, especially if they are web based, will lead to unexpected outcomes expect dancing baby avatars in the streets
Development patterns for moving forward include reuse of standards and code, rapid iteration, and mindfulness towards current information infrastructure (bandwidth, battery life) and being open to future architectures
