AREA blog » Analysis

When a Developer Needs to Author AR Experiences, Part 1

There’s an established process for creating a new Web page. If it’s not already available, you begin by defining and developing the content. Then, there’s the formatting. Often there’s some scripting to provide interactivity. When the “authoring” is done, a page is published.

It’s not all that different for AR. Once an Augmented Reality project’s use case is clear, the experiences come about through an authoring process that resembles that of preparing and publishing content for the Web.

authoring-cycle
Figure 1. An AR authoring system combines trackables (created using features of the real world and a tracking library) with digital content that is encoded into presentation data and then assigned interactive functions (e.g., see more details, show relevant info, move and freeze in position, hide/close). The AR authoring system uses databases to store the scene elements – trackables, presentation data and interactions. (Source: PEREY Research & Consulting)

Today, Content Management Systems for the Web support the steps for page development with grace. Systems like WordPress and Drupal are so easy to use and commonplace that we hardly notice their existence.

In contrast, there are many AR authoring systems from which a developer can choose and none are as mature as CMS for the Web. The choice of tool and approach depends on the project requirements, skills of the developer and the resources available.

Define the AR Project Requirements

Before choosing an AR authoring system, the requirements must be clear. An AR experience design process should generate a storyboard and, from the storyboard, the following factors are defined:

  • User settings (indoor, outdoor, noise levels, etc.)
  • Need for a user management system to provide experience personalization or tracking
  • Need for live communication with any remote experts during the experience
  • Type of recognition and tracking required (marker, 3D, SLAM, etc.)
  • Need to access device GPS and compass for geospatial context
  • Preferred display device (smartphone, tablet, smart glasses or another type of HMD)
  • Human interaction modalities (hands-free, touch, speech, gaze)

In addition to the above variables that can be deduced from the storyboard, there could be other factors to consider. For example, if the target device is connected by an IoT protocol or if there are any supplementary files (e.g., videos, PDFs, etc.), then these need to be provided to the developer as early as possible. The project manager should also specify the frequency and types of updates that may be required after the initial AR experience is introduced to users.

When these project requirements and parameters are defined, the developer can choose the tools best suited for the AR experience authoring.

Want to know more about your choices of authoring platforms? There’s more in the next post