Building Drupal Apps for Distributions


Published on

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)

Published in: Technology, Design
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • \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 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

    1. 1. Design & User ExperienceBuilding Apps for Distributions Frank Febbraro James Walker
    2. 2. Building Appsfor DISTROSFrank Febbraro / James Walker
    3. 3. OverviewWhat is an AppApps & DistrosBuilding an App
    4. 4. What an appisn’t
    5. 5. control
    6. 6. theft
    7. 7. greed
    8. 8. What is an APP?
    9. 9. MODULE
    13. 13. billy mays?!?!?! Infomercial
    14. 14. Why Apps inDistros?
    15. 15. USERS
    16. 16. Targeted
    17. 17. Specific
    18. 18. DEVELOPERS Developers
    19. 19. Integration
    20. 20. Lighter
    21. 21. options & variation
    22. 22. AppsEcosystem
    23. 23. What are the Pieces?
    24. 24. site What are the Pieces?
    25. 25. site App Server What are the Pieces?
    26. 26. site Apps App Server What are the Pieces?
    27. 27. open Appsite Apps standard App Server What are the Pieces?
    28. 28. open Appsite Apps standard App Server What are the Pieces?
    29. 29. Open AppStandard
    30. 30. WHYAPPS
    32. 32. Module list page screen shot
    33. 33. App Browser Screenshot
    34. 34. INSTALLATION
    35. 35. Drush Screenshot
    36. 36. Updater Console Screenshot
    37. 37. Configuration
    38. 38. Module page Screenshot
    39. 39. Console Screenshot
    40. 40. Console Screenshot
    42. 42. Screenshot
    43. 43. ScreenshotAppDETAILS
    44. 44. Directory structure.....
    45. 45. .info specification
    46. 46. Manifest Specification
    47. 47. Magician’s assistant live disaster demo
    48. 48. Questions?
    49. 49. Frank Febbraro@febbraroFRANK@Phase2technology.comJames
    50. 50. What did you think? Locate this session on the DrupalCon Denver website Click the “Take the Survey” link. Thank You!