• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Building Drupal Apps for Distributions
 

Building Drupal Apps for Distributions

on

  • 1,198 views

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 ...

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)

Statistics

Views

Total Views
1,198
Views on SlideShare
1,198
Embed Views
0

Actions

Likes
1
Downloads
22
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Apple Keynote

Usage Rights

CC Attribution-NoDerivs LicenseCC Attribution-NoDerivs License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • \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
  • Hit us up!\n
  • \n

Building Drupal Apps for Distributions Building Drupal Apps for Distributions Presentation Transcript

  • Design & User ExperienceBuilding Apps for Distributions Frank Febbraro James Walker
  • Building Appsfor DISTROSFrank Febbraro / James Walker
  • OverviewWhat is an AppApps & DistrosBuilding an App
  • What an appisn’t
  • controlhttp://www.flickr.com/photos/10789705@N05/5986332740
  • thefthttp://www.flickr.com/photos/40098193@N07/4389889375/ http://www.flickr.com/photos/theloushe/3636110509/
  • greed
  • What is an APP?
  • MODULE
  • MODULE MODULEMODULE MODULE
  • FUNCTIONALITY USABILITY
  • FUNCTIONALITY USABILITY
  • billy mays?!?!?! Infomercialhttp://c0dereality.com
  • Why Apps inDistros?
  • USERS http://www.flickr.com/photos/40627908@N00/5496545575/
  • Targeted
  • Specific http://www.flickr.com/photos/72429059@N00/2695225235/
  • DEVELOPERS Developershttp://www.flickr.com/photos/slworking/5757370044/
  • Integrationhttp://www.flickr.com/photos/37996588780@N01/4625882159/
  • Lighter
  • options & variation
  • AppsEcosystem
  • What are the Pieces?
  • site What are the Pieces?
  • site App Server What are the Pieces?
  • site Apps App Server What are the Pieces?
  • open Appsite Apps standard App Server What are the Pieces?
  • open Appsite Apps standard App Server What are the Pieces?
  • Open AppStandardhttp://groups.drupal.org/open-app-standard/oas
  • WHYAPPS
  • DISCOVERABILITY
  • Module list page screen shot
  • App Browser Screenshot
  • INSTALLATION
  • Drush Screenshot
  • Updater Console Screenshot
  • Configuration
  • Module page Screenshot
  • Console Screenshot
  • Console Screenshot
  • DEMONSTRATION
  • Screenshot
  • ScreenshotAppDETAILS
  • Directory structure.....
  • .info specification
  • Manifest Specification
  • http://www.flickr.com/photos/35258026@N03/4321365261/ Magician’s assistant live disaster demo
  • Questions?
  • Frank Febbraro@febbraroFRANK@Phase2technology.comJames Walker@walkahwalkah@walkah.net
  • What did you think? Locate this session on the DrupalCon Denver websitehttp://denver2012.drupal.org/program Click the “Take the Survey” link. Thank You!