Apps in Drupal and on the Web: The Why and The How
One of the main reasons Drupal is so popular, among hundreds of other open-source content management systems, is due to its developers' constant thirst for innovation and the ability to push the limits of the possible. From its roots as a flexible, hooks-based CMS to modules like Views and CCK, CTools exportables and Features, the Drupal community has been challenging the status-quo, re-thinking the old ways of doing things and constantly delivering more usable, flexible, superior solutions.
Today we are pleased to introduce a new paradigm in content-management systems: an App. Apps are very popular and well-established in the mobile world, but have not been as present in content-management systems until now. We think it's time for that to change.
Future of Drupal for Distributions: Apps?
It's safe to assume that most readers of this blog post have a "smartphone". Probably an iPhone, Android, BlackBerry, Palm Pre or a Windows7 phone: all of which have a well-developed infrastructure for apps. We love apps, not just because they greatly enrich the functionality of our beloved phones, but more importantly because vendors have made finding, installing and updating apps super-easy.
Imagine if installing an app on your phone was anything like installing complex functionality on your Drupal site: you have to browse through several thousand modules, find the best/most stable module or modules for what you need, track down all the dependencies, manually upload all required modules to the server... should I continue?
Now imagine that finding, installing and maintaining a media gallery, ideation or a project mapping functionality, in Drupal is just as easy as installing an app on your mobile phone:
Imagine a future where instead of an overload of thousands of modules that take weeks to explore, end-users have to deal with functionally much richer, well-tested, vetted set of apps that work well with a specific distribution of Drupal; and in many cases: even with several distributions.
Tell Me Again: What is an App?
Business people love to talk about "disruptive" and "revolutionary". The reality is that in technology and science nothing is really ever "revolutionary". Nobody knew this better than one of the brightest minds this world has ever seen: Isaac Newton, and one of the fathers of open-source: Linus Torvalds:
Similarly, despite our belief in the disruptive power of the usability that apps bring to the table, and the uniqueness of the concept in the CMS world, Drupal Apps obviously did not emerge out of nowhere. Apps are a very natural evolution in the direction Drupal has been progressing. First we had flexible, hook-able modules and powerful theming engine, then Earl Miles introduced CTools exportables, which enabled Features. Apps use all of the above, as well as the module download infrastructure introduced in Drupal7, plus some new "hot sauce" to deliver the user-interaction that looks like magic for end-users (at least the ones we showed Drupal apps to).
In reality, there, of course, is no "magic". Apps are based on core Drupal tools present in Drupal7: ctools, features, module download infrastructure, theming engine (allowing apps to provide appealing UI out of the box, but make UI overridable). On top of the existing tools we have added an app server which can bundle all modules, dependencies, libraries and features required by an app using a simple JSON-based manifest file and communicate with the app server client present in a Drupal distribution, providing a holistic experience to the end-user.
App client and server are also responsible for creating a centralized hub where user comments and ratings can be aggregated from all installations, enhancing the crowd-sourced decision-making process geared towards solving the module-overload problem that Drupal community has been challenged with for a while now.
Apps are not meant to "replace" Drupal modules or Features, rather they are a new construct that utilizes both and provides enhanced experience and usability.
What About the Elephant in the Room: Store?
Lately there has been a lot of discussion on Twitter and in Drupal community about "App Store" and issues related to paid apps. That is not the part we are interested in, at this point. We think paid open-source (GPL) apps have both significant opportunities, as well as challenges. Before we, in the community, can even discuss those, however, we have to first prove technical viability of installable apps in Drupal [distributions]. To quote Phase2's CEO Jeff Walpole: "iPhone App Store makes no sense if you don't have iPhone/iOS to begin with". At this point, for us, apps are all about usability and user experience: ease of finding, voting, vetting, installing and maintaining complex functionality in a CMS.
We do realize that monetization is equally important for commercial, as well as open-source communities, and the app infrastructure we are working on could eventually be used to run an app store which will contain both free and for-pay apps. However, our motivation right now is solely to improve on the traditionally challenging aspects of building Drupal websites and distributions. Whether and how Drupal decides (or not) to monetize apps is a completely separate discussion for the community to have.
Also, to clarify any confusion: we do _not_ advocate or support creation of commercial or proprietary modules on drupal.org. Apps are _not_ modules. We believe that paid model only makes sense for complex business functionality like that delivered by apps. We are also sure that there will be a great number of apps that will be free. But it's a subject of another blog post, since in this one we are discussing mostly technical aspects.
Why Phase2?
It's very hard to create apps that would work properly in any Drupal installation. Apps are all about streamlined experience. An app that works perfectly in one website but is totally broken in another is quite worthless. As such, it makes a lot of sense to test app infrastructure in a more well-defined field of distributions first. In our experience it's easier to create an interoperable app that can work with multiple distributions (e.g. Ideation app can work with both OpenAtrium, as well as OpenPublic) then target large variety of Drupal-built websites.
Phase2 is known in the community for being a dedicated Drupal distributions creator/maintainer with four popular distributions under the belt. It's very natural that we ran into the need and necessity for app infrastructure and decided to give its implementation a first shot. We do not expect to be alone in this however. You probably have heard the news of Acquia Network 2.0 launching and the new API Acquia launched which offers some very interesting monetization opportunities. It's a great example of the infrastructure that the app servers we are developing would need to integrate with. We look forward working with the community and our partners to smoothly integrate all the ongoing initiatives.
OK, I am convinced! Where can I see it?
First beta implementation of apps is present in OpenPublic, the Drupal 7 distribution for governments. It is being demoed and discussed during several sessions presented by myself, Frank Febbraro and Jeff Walpole at DrupalCon chicago. To see Apps in action and play with them, feel free to download OpenPublic Beta. Source code for app server client is being released on: drupal.org. Server component is still under heavy development and will be released later.
You can try apps today!
OpenPublic Beta ships with three fully-functioning apps in the console: pre-installed OpenPublic Demo Content app by Phase2, Ideation app developed jointly by Phase2 and Development Seed and Project Mapper app by Development Seed using their amazingly beautiful MapBox maps to visualize government agency's projects or initiatives on a slick map with extreme ease. We are actively discussing apps model with a number of leading Drupal companies and see a lot of enthusiasm, so we expect the number of great apps in distributions to grow significantly and quickly.
Comments
Great news!
Sounds fantastic. Look forward to learning more about writing apps for Drupal.
That's some good rhetoric.
That's some good rhetoric. Apps are modules that you pay for. Enough said. I wonder if the code ends up on your server, whether you can say it's GPL and release it to the public.
Apps could not be further
Apps could not be further from being just "modules that you pay for". You can download existing apps and see if they are "just modules" - they are not. And I am certain future apps will not be either. But I guess "a picture is worth a thousand words" - skeptics will have to wait and see to believe.
As for GPL: not only you can release, but I am certain source code will be made available on Drupal.org by app vendors themselves. People will pay not because they can not get source, but because of the superior user experience provided by app console that is not present when you have to download source, track-down dependencies, figure-out compatibility and go through rest of the hassle of installing a complex app.
User experience is of paramount importance. Even beyond open-source, it's actually why most people buy reasonably-priced apps from Mac app store too - it's not like you can not get pirated copies of proprietary software, if you really wanted to.
3rd party apps?
Great article and even better initiative.
I'm curious what the process will be (if any) for apps from 3rd parties. We would be interested in providing some apps for this marketplace if there is a means for 3rd parties to do so.
Absolutely
Greg,
absolutely. We've had discussions with a number of Drupal shops who are interested in writing apps for OpenPublic. It's great to hear that you are considering some too.
We will try to write another blog post with more technical details about building apps, but in general: a module/feature or a collection of those that is Kit compliant and implements default theme tpls in module but allows overriding according to Drupal guidelines in a theme + understands and exposes itself in distribution's regions + is well tested with a distribution is 99% compliant to being an app for that distribution. The remaining 1% is just writing a simple manifest JSON on the server side to provide URLs of all dependencies etc., which usually takes minimal time.
Feel free to shoot us an e-mail if/when you have more questions.
Thanks
P.S. Thank you for your kind words.
Post new comment