The search on the scientific libraries returned 147 papers and 14 works about content design tools were selected for analysis. Moreover, 10 commercial tools that are well consolidated or relevant in the market were chosen. Thus, taking into account both academic and commercial realms, there were 24 content design tools. Thereafter, a dataflow analysis was performed in each of the selected tools.
3.1 AR Authoring Paradigms
Once individual analyses were performed in each of the previous selected content design tools, it was observed that two authoring paradigms have been used to create AR solutions: stand-alone and AR plug-in approaches.
Stand-Alone. AR authoring tools that use the stand-alone paradigm are software with all the necessary components for the development of complete AR experiences, as can be seen in Fig. 2(a). In turn, these components may include a graphical user interface, a series of importers, sensor interfaces, tracking and rendering engines, among others. In this sense, each stand-alone content design tool is a new software that allows designers to create their custom AR projects with more or less ease.
As an example, the Layar Creator  provides a complete set of features along the entire creation workflow, such as graphical user interface including drag and drop to ease the scenario creation.
AR Plug-in. Similar to conventional digital plug-ins, AR plug-ins are third-party software components installed on host applications in order to enable additional features, as illustrated in Fig. 2(b). In this sense, these authoring tools provide AR capabilities to software that natively does not support it, such as tracking techniques, access to physical sensors, three-dimensional rendering engine, among others.
It is relevant to note that, from the practical point of view, an AR plug-in instance will appear in the target software as a set of GUI elements, such as one or more menu items and toolbar buttons. Therefore, the whole AR authoring process occurs within the hosting environment, as the designer completely configures the desired AR experience by means of those elements along with the ones already provided by the target software.
As an example, the DART  system is built as a collection of extensions to the Adobe Director , a widely used environment for multimedia content creation, to support the development of a variety of AR applications.
3.2 AR Deployment Strategies
It was noticed that two deployment strategies have been applied to make these AR experiences available for end-users: platform-specific (PS) and platform independent (PI) methods.
Platform-Specific. In the PS approach, AR projects built using authoring tools are exported to archive files to be independently distributed. Some common archive file formats include .exe in Windows, .dmg or .app in Mac OS, .apk in Android, and .ipa for iOS operating systems. Note that these archive files are software packages used to distribute and install native application software. A native app, in turn, is considered a stand-alone program itself since it is a self-contained program that does not require any auxiliary software to be executed, as can be observed in Fig. 3(a). Native apps are usually available through application distribution platforms, such as App Store, Google Play, and Windows Phone Store. However, they must be downloaded from the platform to the end-user devices, such as iPhone, Android, Windows phones, or even laptops or desktop computers.
As an example, the Wikitude Studio  supports deployment options to mobile applications for iOS/Android platforms, and to executable programs for Windows/Mac OS computers.
Platform-Independent. The PI approach delivers the AR solutions as data files read and executed on a software platform (SP) running on the end-user device. Also, it is worth pointing out that, after the authoring process, the generated content requires a platform on which it must be executed. Therefore, the content cannot be considered a stand-alone program. Rather, it comprehends data files (commonly structured in XML-based formats) that are interpreted by the SP, as illustrated in Fig. 3(b).
As an example, k-MART  allows designers to export AR solutions as X3D-based data files. In turn, these files are later executed on a separate content browser.
Furthermore, since the content does not need to be installed in the device, a major advantage is the possibility of implementing a cloud-based deployment service. This increasingly popular variant approach uses a server infrastructure as a backbone. The remote server is responsible for content storage and retrieval as requested by the clients. The clients, in turn, are responsible for presenting the retrieved content on end-user devices. Also, a client comprehends a cloud-based SP that reaches into the cloud for contents on demand. In turn, all data files remotely accessed are here referenced as cloud-based applications.
As an example, AR companies like Layar and Wikitude developed Layar App and Wikitude World AR browsers, respectively. To the end-user, an AR browser looks very similar to a typical native app: it is downloaded from an app store, stored on the mobile device, and launched just like a native app. However, the most prominent advantage of AR browsers is that end-users need only one app for multiple contents. Once installed, they pull new cloud-based apps on demand.
3.3 General Models
Given the authoring and deployment trends explored in the previous subsections, it was possible to elaborate four general dataflow models that represent the content design tools’ dataflow analysed in this work.
Model 1: Stand-Alone PS Model. As can be observed in Fig. 4(a), this dataflow model embodies a stand-alone authoring approach combined with a native distribution strategy. In this sense, the designer first creates AR experiences through stand-alone content design tools. Then he exports the project as PS files, which are used to deliver stand-alone, native applications for Android, iOS, Windows or other operating system.
Model 2: Stand-Alone PI Model. Similarly to the previous model, the designer first builds AR experiences using stand-alone content design tools. However, this model applies a PI strategy for reaching interoperability and maintainability. In this sense, the designer exports the authored AR solutions as data files that run on a separate SP. Note that, a content design tool can generate one or more data files which can be interpreted in a single SP and in different periods of time, as seen in Fig. 4(b). Yet, since each stand-alone content design tool is a brand new software, the data files created by distinct tools generally differ in their structures, logics, and formats.
Model 3: All-in-One Model. As illustrated in Fig. 4(c), in this model, both designers and end-users utilize the same environment to build and access AR solutions. In the sense, the designer creates and saves AR solutions as data files. Eventually, these files are read and executed within the same environment in order to present the AR experience to end-users. Hence, similarly to the previous model, the all-in-one comprehends a stand-alone authoring approach combined with a PI distribution. However, the major difference resides in the fact that production and delivery services are merged within a single system.
Model 4: AR Plug-in PI Model. In this dataflow model, the designer first builds AR projects using hosting software integrated with AR plug-ins. Then, these projects are saved as data files that are later retrieved and executed on a separate application. In other words, this model includes a plug-in approach combined with a PI deployment strategy, as can be observed in Fig. 4(d).
All the content design tools that were selected and analyzed in this work are listed in Table 1. The table divides the commercial and academic tools and indicates to which of the four general dataflow models each tool belongs. It is important to keep in mind that it is not mandatory for a tool to be categorized into only one general model since a content design tool can provide different distribution approaches and, consequently, different dataflow models.