What is an app?
Before we say what an App is it's helpful to know who it's for: An App is for the end user, typically a non-technical user of a Drupal site such as the site administrator. These are the users we are thinking about when we discuss Apps:
An App is an installable package which solves a concrete task specific use-case. The complexity of its installation should be hidden as much as possible keeping the process uniform and simple. The goal of the App concept is to make extending the functionality of a Drupal site with discrete functions in a polished, "user friendly" way its main goal.
An App is a piece of packaged functionality. Upon installation, an App delivers a polished solution for a specific need.
The goal of the "Apps" module is to reduce the number of steps required of users from discovery to usability for functionality for their Drupal sites. By creating a specific protocol for installing and configuring apps, we'll streamline the end-user experience, making Drupal functionality more "pluggable" and inherently easier to use.
Technically, an App is a collection of new or existing Drupal functionality, including Modules, Features, and Themes along with some simple additional code that publishes the existence of the App to the rest of the App infrastructure.
What distinguishes an App from a Module or Feature is that the App includes all of the additional polish, end-user UI, configuration UI, sample content, and documentation that are needed to fully meet a specific need. Whereas Modules and Features are more developer-centric and provide building blocks for larger functionality, Apps are larger blocks of completed functionality.
Unlike a Distribution or Product, one App only solves one specific problem. A collection of Apps might be seen as a full Product, just as a collection of Modules and Features might be seen as a Distribution.
What is the purpose of an app?
The primary purpose of an app is to simplify and make consistent the discovery, installation, setup and use of a specific piece of functionality on a Drupal site.
Examples include a Mailchimp app, which synchronises site users with a MailChimp list, a Project Mapper app that provides geolocation around specific projects for an organization, and then displays them on a map, or an ImageSlideshow app, which displays your images in a slideshow.
The App Philosophy: Why do apps exist?
There are a couple of things about Apps that are important to understand. First, that apps exist to solve specific problems for specific users. And second, that apps are generally built for the benefit of Drupal consumers, as opposed to modules which are generally built for the benefit of developers or site builders. To explain further:
Apps exist to solve specific problems for specific users.
To be clear from the beginning: the Drupal framework for creating functionality (modules), for creating specific designs (themes), and for delivering combinations of functionality and design (distributions) is a solid framework, from which the concept of "apps" does not deviate, fork, or undermine.
Rather, apps adds another piece to this framework -- the ability to solve very specific problems, for very specific end-users in a highly user-friendly way, using Drupal. Apps do not seek to add blanketing functionality to every part of a site, or to provide multi-function solutions to complex problems. Apps resolve discrete, specific needs for very specific groups of users.
Apps are built for Drupal consumers:
First, let's clarify the concept of "Drupal consumer." A Drupal consumer is a site builder or site administrator or site owner (such as a Blogger) who is using a Drupal site. Drupal consumers are often not comfortable working in the code of a web site and may not have the knowledge to do so. These consumers are not visitors to sites, but rather, the owners/administrators who make decisions about what content and functionality they need for their site, and require a solution to provide it.
Consumers & end users are a picky bunch. They say things like 'it's almost there, but I also need this ...' But in a distribution or a SaaS product, "almost" isn't good enough. "Almost" is what drives end users 'back' to find something else. Borrowing from the Pareto principle, Drupal itself solves 80% of these problems, but consumers of Drupal need that last 20%. Apps can solve this problem, by simplifying the process of adding functionality to one's Drupal web site.
Components of an app:
At a minimum, an app should include the following components:
- specific functionality or the connection of the end user to a third party service that provides specific functionality
- the ability to install, uninstall, enable, & disable, cleanly
- settings or configurations for the end user to customize their use of the functionality
- descriptions, screenshots, and graphics that tell an end user what the app is, what it does, and how it is used
What's Not an App:
The following are characteristics that preclude something from being an "app":
- It is not a complete solution: if an app only provides raw materials or building blocks, of a solution, it is not a good app.
- It is trying to solve too many problems, or too big a problem: Apps that install functionality into many different places in a site, or that try to solve a large host of problems, will not be good apps. (e.g. A CRM app would likely be too large a problem to solve)
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 and contributed 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 beautiful 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.
What is the difference between apps and "Features?"
Features allows the export of configuration to a module, while the Apps module provides an interface for delivery of modules and their dependencies, as well as an API for configuration. Another way to look at it, if you're more of a businessy person and less of a technical person, might be this: the Features module packages up Drupal functionality and configuration in a way that makes it easy to use and share among developers. The Apps module wraps a layer of usability around Drupal functionality that makes it easier to use and share among a distribution's end users. You'll often combine them, wrapping the Apps layer of usability around the Features packaging of functionality."
Apps need not be Features, but a really good start for an App is to simply 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.
An App may actually consist of more than one Feature to encourage Features to focus on smaller blocks of general-purpose functionality.
How do Apps work with the rest of Drupal?
Apps are designed to work within the Drupal framework, not outside of it. The following diagram outlines how Apps work in concert with the Drupal framework, and how they relate to Drupal Core, modules, Features, distributions, and SaaS platforms.
Who can 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 with Drupal or with a specific distribution of Drupal such as 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 sources CMSs like Drupal distributions.
The Apps Ecosystem
The purpose of this section is to define the components of the "ecosystem" around Drupal apps, and to show the relationship between that ecosystem and the larger Drupal ecosystem.
- App: a discrete piece of functionality that is focused around managing the UI interactions and data to perform a particular task. e.g. adding a mailchimp signup form block to a page's region. The process of 'installing' an app should be a simple click operation for the end user and the app framework would take care of any underlying dependencies required.
- App Market: An app market is the user interface that allows a Drupal site owner to extend the functionality of a site with apps located on a App Serve and provide payment processing and checkout functionality as needed.
- Distributions: a collection of Drupal code combined with an installation profile to accomplish specific functionality for a user group
- Apps Manifest Specification: A technical specification that describes which apps are available, what their dependencies are, and associated information such as descriptions, logos, and screenshots.
- Apps Manifest API: the bi-directional interface between the App Server and the App Client which mostly consists of requests and deliveries of data that adheres to the Apps Manifest Specification.
- App Server: An app server is responsible for publishing a catalogue of its apps, synchronising versions with d.o. and other appstores, allow searching over the catalogue, packaging and delivering the apps and providing a payment infrastructure. It is thought appstore servers will be focused on serving a particular domain problem, e.g. Open Public, SubHub, etc. The App Server is a provider of data that adheres to the Apps Manifest Specification.
- App Client: An app client would allow the user to browse/discover a remote collection of apps, prompt for any necessary technical and monetary requirements and install them on the chosen site. A process that should convey a simple, robust and secure UX. It is required that the client abstract as much technical information away as possible making the process of using and extending a Drupal installation as simple as possible. It's likely this would be a module. It is a consumer of data that adheres to the Apps Manifest Specification. Technically, one client could browse multiple "app markets" pointing to different servers, if desired.
- Apps module: the open source Drupal module that allows for the installation and use of apps in a Drupal distribution. This is an implementation of an App Client as defined above.
Definition of Roles Involved in Apps
- App owner: the person or organization who owns or maintains the code for the app.
- 3rd party service provider: a company who provides a service that they would like to make available to a platform's app consumers through an app. (e.g. if MailChimp wants to sell its services to users of the SubHub platform through an app, MailChimp is the "3rd party service provider")
- Platform owner: the person or organization who owns or maintains a distribution or SaaS platform which utilizes apps or an app market. This owner defines which App Client gets used, and which stores it provides. (e.g. SubHub is the "platform owner" of the SubHub SaaS offering; Phase2 Technology is the "platform owner" of the OpenPublic distribution)
- App market owner: the person or organization who hosts an app server, curates a collection of apps for that app market, and makes the app market target specific platforms. Often, a platform owner will also be an app market owner. However, another organization could host an app market and implement it in an instance of an open source Drupal distribution, and in that case, this organization would be the "app market owner," but not the "platform owner."
- App consumers: app consumers are the site administrators or site builders who make decisions about which functionality to include on their sites.** Direct app consumers: site administrators or builders who are making decisions for their own sites.**Indirect app consumers: site builders who are making decisions for their clients' sites. (e.g. a development shop using OpenPublic to implement sites for public sector clients chooses apps appropriate for each client. This development shop is an "indirect app consumer")