The Drupal Apps module and the Open App Standard was built to solve a recurring problem: How can we use Drupal to package up functionality in a way that makes it simple to find, evaluate, install, and use for site builders? Apps are built on existing Drupal building blocks - modules, Features, and Kit-compliance - and can be interoperable between different Drupal distributions. But how do you know what should become an App and then how do you build one? (Presented by Frank Febbraro and James Walker)
53. What did you think?
Locate this session on the
DrupalCon Denver website
http://denver2012.drupal.org/program
Click the “Take the Survey” link.
Thank You!
Notas del editor
\n
\n
\n
\n
Before we talk anything about apps, lets first decide what they are NOT.\n\nFRANK\n
Apps is not a way for one company to control or destroy Drupal (better gollum)\n\n
It’s not a way to take someone else’s module install it or make money of of it. (Even though we all do that with Drupal to our clients)\n
It’s not (yet) a way to a ton’ o money\n
JAMES\n
An app is a module, plain and simple.\n
Ok, actually it is likely a collection of modules, and often those modules are Features, but it need not be. Its just easy to package it up like that.\n
So you have your module(s) and they represent a certain group of functionality\n
Apps wraps a layer of usability around existing functionality\n
It adds discoverability, installation, configuration, and demo to the module experience\n\nFRANK\n
Billy Mays RIP! It’s like those infomercials where people can’t perform a silly basic tasks and need a specialty product to help them not spaz out. \n\n
Apps in distros offer compelling reasons. Not to say that apps won’t be useful more generally, but I think they are good in a distro context because you can focus.\n
Users are a captive audience. They downloaded your distro for a reason. It’s a collaboration tool, a publishing site, a higher education tool.\n
Distros provide a targeted audience for functionality. OpenPublic users are interested in security apps, Intranet distros can provide timesheet functionality, etc.\n
Use case specific functionality. A specific tool for a special job that is needed in the context of the vertical your distro targets.\n
The distro also creates a good playground for developers.\n\nJAMES\n
There are well known integration points. You know the regions, what the menu are. How landing pages are configured....at least initially out of the box. \n\n(Apple 5 display adapters in 5 years)\n
Apps allows for lighter distros. You no longer need to bundle EVERYTHING a user might want in one download. This allows for faster installations, and easier deployments. You dont need to have another distro release just to add some commenting or newsletter integration.\n
Allow for options and variation instead of baking one assumed “best practice” in place. You can provide apps for core commenting OR disqus commenting. you are not limited.\n
What pieces are at play here?\n\nFRANK\n
Distro/sites, App Server, then the Apps. All tied together with the Open App Standard\n
Distro/sites, App Server, then the Apps. All tied together with the Open App Standard\n
Distro/sites, App Server, then the Apps. All tied together with the Open App Standard\n
Distro/sites, App Server, then the Apps. All tied together with the Open App Standard\n
Distro/sites, App Server, then the Apps. All tied together with the Open App Standard\n
Open App Standard is a “standard” around defining the components and protocols for supporting Apps.\nMeant to ensure interoperability and to try to limit fragmentation as distros become more widely adopted. Essentially trying to ensure an App can be installed in any site that implements OAS.\n\n\n
We wanted to tackle a few basic shortcomings of the shitty module experience. Not to say modules are shitty, they are great in an of themselves, but they challenge the non developer. Modules were build by devs for devs. We want to target a different audience.\n
Discoverability. Modules are hard to find. Complete/polished modules/features are even harder\n
So tell me what is better? This....\n
Or this? The App Browser aims to make that process easier, provide for Ratings/comments, etc. and a bit more.\n
Installation\n\nJAMES\n
Drush is great if you have a command line, using hosting providers often dont provide you that ability\n
The updater console is still a bit too developer centric\n
But single click install is the goal.\n
Configuration\n\nFRANK\n
The module page to find a config link is a disaster, better, but still a disaster. Is it in the structure menu, the config section how to do you distill the config to simply what a users needs to know.\n\n
We wanted to unify config, so we put it in the console with the App. You installed it from there, so configure it from there.\n
These config screen can be more than just config, it can be intro and pointers to where functionality lives.\n
Demonstration of functionality.\n
Module are hard to know how to use. What collection of settings get content to appear in certain places? Providing content that can be enabled (and disabled) allows you to provide an example to get folks off their feet.\n
\n
For developing an app we have an app folder which contains app specific assets.\n
In the main app module .info file we specify which file is the apps manifest.\n
This is the specification of the App details.\n
ta-da!!!!\n\nJAMES\n
General author/meta-data\nDependencies/Downloadables\n