So you want to sell your Creative Suite extensions?

This article discusses how third party developers can use existing technologies to help distribute and sell Creative Suite extensions.

The 'App store' concept is commonly associated with mobile devices, but in recent months this has begun to extend to applications based on web technologies (generally running in the context of the browser). In this section we discuss how you can use two such stores, Chrome Web Store and Intel AppUp, to help sell and distribute CS Extensions.

Chrome web store

The Chrome Web Store is an online marketplace for apps, extensions, and themes that can be used within the Google Chrome web browser. The apps, extensions and themes extend the capabilities of the web browser, offering a different and more interactive experience to the user.

For our experiments we looked at developing an app for the Google Chrome browser that acts as a distribution mechanism for an extension. Apps that can be developed for the Chrome Web Store can be Hosted or Packaged. In both cases, the app is structured like an ordinary website with the addition of a CRX manifest file. Hosted apps are described as 'ordinary web app[s] with a bit of additional metadata', while Packaged apps are marketed as 'installable web apps'. This means that Packaged apps can work offline and make use of the Google Extension APIs.

How does this relate to monetizing CS Extensions? Packaged apps have the feature that you can include additional files and refer to them with the JavaScript code:

By including our CS Extension as an additional file, we can:

• Download the ZXP extension package on initial loading of the page.
• Make a download link available on the page.

From a user's perspective, the workflow is like this:

1. Navigate to the Google Chrome Web Store.
2. Find your Chrome App.
3. Pay for and install the application.
4. Navigate to your application homepage (the HTML file included in the app bundle; in Figure 1 this is index.html).
5. Trigger the downloading of the ZXP.

Figure 2 shows the ZXP being downloaded. When the user clicks the lower left button, Adobe Extension Manager starts up and installs the extension.

In this example, the ZXP is freely available in the user's download folder and can be easily shared. To protect your extension from being unfairly distributed, we are looking at another technology, the Netscape Plugin API (discussed in the following section).

Intel AppUp

AppUp is Intel's app store contribution. It focuses on delivering apps to Intel® Atom™ processor-based devices. The AppUp SDK supports a number of languages including C/C++, .NET, Java, HTML5 and Adobe AIR. For our experiment, we used the Adobe AIR SDK to submit an app that contains the packaged CS Extension. When the AIR app was downloaded, it launched Adobe Extension Manager and installed the CS extension.

You can implement the same workflow using the C/C++, .NET and Java libraries.

Summary

This section has identified a couple of app stores that have extended their audience to deliver content beyond mobile devices. We have showed how you can use these to increase the availability of your CS Extensions and avoid risky infrastructure costs. The examples here are not optimized solutions, but illustrate how you can work these technologies into your deployment workflow.

The Netscape Plugin API (NPAPI) is a plug-in architecture that was initially developed for the Netscape family of browsers. It has evolved to include cross-platform support, and is used by a number of browsers. The obvious exception is Window's Internet Explorer, which deprecated support in version 5.5 and now uses ActiveX.

The architecture enables developers to provide native code to handle unsupported content-types in the browser. A well-known example is for PDF document viewing; instead of downloading the file locally, the PDF plug-in enables you to view the document within the context of the browser.

The same workflow applies to viewing Flash content. Communication between the browser and the plug-in is established using JavaScript, with a number of required functions implemented in native code.

In creating apps for the Chrome Web Store and Intel AppUp, you may have noticed the lack of cross-browser support or reusable code. We could have encapsulated the AIR application developed for the AppUp store into the Chrome packaged app, although we didn't do it for this example.

Our interest in the Netscape plug-ins is not so much the cross-platform capabilities, but rather the ability to gain control of the installation process. As noted in the Chrome web store example, once the ZXP file was downloaded, there were no restrictions to prevent the user sharing the ZXP. With the NPAPI, we have better control of the download experience in the context of the web browser.

Prototype

We decided to develop a Netscape plug-in that would support the ZXP content-type. Using Chrome and Firefox for our experiments, we embedded a content-type x-zxp-helloworld into a simple HTML page:

Using JavaScript, we communicate with the Netscape plug-in to pass the file contents. Once the file is loaded, we launch Adobe Extension Manager via the native plug-in to install the CS extension.

Summary

Using this workflow, we can improve security because we have much better control over both the launching of Adobe Extension Manager, and of cleanup tasks including the removal of the ZXP package file.

For example we can use an encrypted package, or simply remove the downloaded content once the CS extension is installed. Both of these measures can help to prevent unlawful distribution.

These are clear advantages of implementing a Netscape plug-in. Our example shows how, with relative ease, you can piggy-back your extension distribution to an existing channel that provides payment options.

For a different approach to monetizing a CS extension, we looked into available Payment Web Services such as Paypal and Google Checkout. This changes the point at which we monetize the extension. Instead of using a Web Store that expects payment upon download, we request payment when the user first loads the extension within a CS application.

This approach means we can integrate a number of payment web services, and are not restricted to one supplier. All payment logic is contained within the extension. We can also use ActionScript instead of requiring an additional native extension, JavaScript, and HTML. In addition, it allows us to offer different options such as trials, subscriptions, and free/premium versions.

The actual purchase workflow experience depends on the actual system you connect to. Our prototype implementation used the HTML object class to embed the browser workflow within the extension.

Once the extension was initialized, the htmlField was assigned the correct HTML to interact with the Payment web service. Alternatively, you could open a web browser for the purchase, before allowing the use of the extension in your application.

Summary

This alternative approach to monetizing extensions doesn't require a costly distribution workflow, or a commitment to one Web Store. However, unless you have your own payment service, you must adopt the workflow of the supplier; this might mean opening a browser, or displaying the supplier's UI within the context of your application.

This article signals the beginning of an investigation by Adobe on the topic of CS extension monetization. We have identified a few existing 3rd party technologies that are available to help you distribute and monetize your CS Extensions, and provided some guidance on how to do so. You may want to use one or a combination of these examples, or develop a different approach.

We understand the importance of extension monetization for the Creative Suite developer and user base. We will continue researching the space, and sharing our findings and thoughts with you. Stay tuned on CS Extension Builder for more updates.

See below for further information about the technologies discussed in this article:

• Google Chrome
• Chrome Web Store
• Intel AppUp

Additional technologies not discussed in this article:

• Chrome Licensing APIs
• Google In-App Payment APIs
• Pepper Plugin API
• Firebreath