Open Source Mobile Augmented Reality
- 1. Open Source Mobile Augmented Reality
- 2. Open source AR in the wildStatsGoogle Code: 104SourceForge: 37GitHub: ~75Mostly sketches, ARToolkit projects, libs and utilitiesNot seeing many full clients
- 5. Native Apps vs. Web Apps
- 6. Native Apps
- 7. Barriers to open sourceWalled gardens/silosFragmentationAndroid 1.5, 1.6, 2.0, 2.1,2.2apps vary across carriersAppleiPhone, iPod Touch, iPadiPad video out, determined by application
- 8. Web Apps
- 11. Content Problem
- 12. The UI ProblemIn 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)
- 13. Standards are a growth medium
- 14. So many to choose from!HTML5X3DARMLKARMLKMLGeoRSSWave Federation ProtocolW3C
- 15. Unintended and unexpected outcomes
- 16. Going forwardUse existing standards, extend when necessaryUse existing projects, extend - dont reinventIterate quickly, make lots of prototypesRespect todays architectures, plan for the future architectures
- 17. ContactSophia Parafina, OpenGeo (opengeo.org)Email: sophia@locativemedia.orgTwitter: @sparaBlog: locativemedia.orgBlog twitter: @locatively
Editor's Notes
- #2: Sophia Parafina, locativemedia.org
- #3: 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
- #6: As with other mobile applications there is a tension between native applications for mobile devices and web applications
- #7: 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
- #8: 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
- #9: Web apps can currently access geolocation through HTML5, but they can not access the phones 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
- #10: currently AR Browsers based on a web application does not exist
- #11: however, the Kamra system (possible release summer 2010) is an AR browser using HTML5 and KML
- #12: AR content varies widely from POI annotation, virtual objects representing real word objects, and completely virtually objects
- #13: Excerpt from Jakob Nielsens report iniPad usability testing, AR applications face the same hurdles
- #14: Standards provide a way forward for developers they act as a growth medium for emerging industries
- #15: 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
- #16: Even with standards, AR experiences, especially if they are web based, will lead to unexpected outcomes expect dancing baby avatars in the streets
- #17: 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