27 June 2011
This article assumes a basic understanding of Flash-based extensibility for the Creative Suite.
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.
var zxpLoc = chrome.extension.getURL("HelloWorld.zxp");
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:
- Navigate to the Google Chrome Web Store.
- Find your Chrome App.
- Pay for and install the application.
- Navigate to your application homepage (the HTML file included in the app bundle; in Figure 1 this is index.html).
- 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).
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.
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.
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.
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:
<embed type='application/x-zxp-helloworld' hidden='true' id='plugin0' />
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.
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.
<mx:HTML height="100%" width="100%" id="htmlField" />
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.
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:
Additional technologies not discussed in this article: