The discussion has started. If you're reviewing potential sessions for DrupalCon London or attending any of the Drupal camps around the country, you know that the question of "apps" for Drupal is a big one. How can we make advanced functionality, third-party services, and beautiful themes easy to install, configure, and use for everyone? Features took us far along that path, making functionality pluggable and "packageable." Now Apps, a concept we are integrating into our distributions and soon to be a full contributed Drupal module, will make creating apps and even your own "app stores" possible.
I hope to continue this discussion from Drupalcon Chicago in a session that Robert Douglass and I have proposed for Drupalcon London.
For Phase2, the apps model will have a big impact on our ability to incorporate more functionality into distributions while also making them overall lighter and more performant, and will allow interested collaborators a straightforward and simple way to contribute to the distribution. We're using the Apps module to build app stores for each of our distributions, and we're eager to see what it means in reality for contributors to these distributions.
We're working with an outstanding group of collaborators on a first round of apps now, getting the kinks of the system smoothed out. In the coming weeks, we'll be providing a great deal more documentation on the concept. But in the meantime, we thought you might want to get started with some answers to the questions we're hearing most about apps. Ready? Here are the top questions we're hearing, and some steps to get you going.
1. What is an App?
An app is a collection of code (modules, features or themes) that delivers a discrete piece of functionality fully and clearly, upon installation. The goal of the “Apps” module is to reduce the number of steps required of users from installation to usability for functionality for their Drupal sites. By creating a specific protocol for installing and configuring apps, we’ve streamlined the end-user experience, making Drupal functionality more “pluggable” and inherently easier to use.
2. Can any module or theme be an App?
Apps are specific and not broad, in nature – they are designed to solve one problem, solve it well, and solve it completely. Generally, an app will both keep track of data in some way (as a content type, etc) as well as use it or display it in a specific way (on a map, etc). So, an app like Ideation, created by Development Seed is a great example of an app that solves one problem, solves it well, and solves it completely. Ideation provides feedback functionality for organizations. It solves it well, with a ready interface and simple-to-configure set-up, and it solves it completely, giving users the ability to not only suggest ideas, but also give feedback on that idea and rate the idea; and giving administrators the ability to accept or remove ideas from rotation.
Many excellent modules would not be considered an app, but perform vital functionality as modules. For instance, modules like CTools or Panels add enormous functionality to a Drupal web site, but perform their function very broadly, and therefore do not fulfill the “specific functionality” guideline for apps.
3. Who Can or Should Create an App?
App development is open to any member of the community. Apps can be developed by organizations or individuals who want to make their functionality simple to install, configure, and use within a distribution like OpenPublic. Organizations who want to integrate their third-party applications should also consider creating an app. Apps that link users to other applications such as analytics, data storage, or social media aggregation can provide new customers to companies seeking integration with open source Drupal sites and distributions.
4. Are Apps just Features?
Apps need not be Features, but a really good start for an App is to simply to create a Feature. You need a good use case and functionality that can be isolated, self-contained and individually exportable and Features support that. They can contain Content Types, Views, Permission settings, Panels pages, Context/Spaces/Strongarm/Boxes settings, etc. Here are some good resources for learning how to build a good Feature.
Additionally, creating a Feature with KIT compliance ensures it does not have incompatibilities with other Apps. At its basis, KIT is a strategy for naming conventions and component exportable strategies that aim for independence and interoperability. Read more about KIT here.
5. Why should developers create apps?
The main reason is the ability to easily add, configure or remove functionality from a site. However, there are important usability reasons as well. Often when you are finished installing many Drupal modules you need to track down where the modules many configuration forms are located. Sometimes they are in admin/config sometimes they are in admin/structure, other times in a more specialized location. The point is that, currently in Drupal, once a module is enabled you need to track down forms to allow for information gathering and configuration. Drupal 7 makes it a step better by providing a configuration link in the modules page but sometimes you want a more integrated and self contained experience.
This is where Apps shine, giving you a configuration form presented immediately after enabling your module and in the context of where you read about, downloaded, and enabled your App. At any point in the future you can return to the App Console and find your app and configure it directly and completely from the console. This configuration form can be used to gather API keys, set permissions, or any other thing you might need the app to be configured to do. This configuration destination also natively support the enabling/disabling of demo content and the ability to get updates.
6. Are Apps generic to Drupal, or specific to OpenPublic?
The Apps module is a contributed Drupal module on Drupal.org. OpenPublic’s app server is specific to OpenPublic and apps contributed to it are considered for this distribution alone. So the apps here are designed for use in the public sector, specifically. Organizations who use the Apps module in Drupal may create app servers of their own, with their own specifications on what types of Apps they’ll accept for their distributions.
Phase2 plans to incorporate apps into OpenPublish 3.0 (for Drupal 7) later this summer and then into Open Atrium where it is arguably the most useful. So if you have apps ideas that you want to incorporate into these distros we are ready to start planning that as well.
7. Can I charge for an app?
GPL licensing does not prohibit the selling of code, but does pose restrictions on its fair use and distribution. Therefore, Apps can be sold and we expect there will be a market for selling apps even if the modules it packages are contributed to Drupal.org (our preference actually). While we don’t have the facilities to charge for apps currently in our distributions, that is definitely something we realize many people are interested in. We hope to be able to address that in a very transparent and fair way that can benefit everyone in the community without subverting the open source contribution model.
8. Do I have to build an app for one of Phase2's products or can I build one for my own?
You can build an app for anything you want. But if you're interested in distributing your app through OpenPublic, OpenPublish, or Open Atrium, here are a few tips for getting started.
If you're ready to get started building an amazing app for OpenPublic (or for one of our other distros, once their app stores are ready), we want to hear from you. Here are a few quick steps to kickstart the process:
1. Plan Well: If you're building an app for OpenPublic's app store, make sure the app will serve the public sector market that's using OpenPublic. You'll want to start with some basic planning - make sure you know what your app is trying to accomplish, for whom, and how. Document this as you would any module, but perhaps with a more user friendly set of instructions, feature information and screen shots.
2. Build a Great Feature: Yeah, that's it. Build a great Feature. The tutorials on Features above will get you started, and in the coming weeks, more documentation on what else to include with your great Feature will help you get it all packaged up for the App store on OpenPublic.
3. Give us a Shout: If we can help you in any phase of this, or if you're all set and ready to roll with your Feature, drop us a line. Our team is really eager to help you get your app ready to go.
If you're like us, you're ready to stop talking about what "apps" might be in Drupal, how they might work, and what might be in store for the community and ecosystem around Drupal because of it. If you're like us, you just want to start testing it out. Let's get started, shall we?