Josh Gee, former product manager for the City of Boston's Department of Innovation and Technology, recently shared how identified 425 PDF forms used by citizens and moved 122 of them online. Not only did it improve the accessibility of's government services, it also saved residents roughly 10,000 hours filling out forms. While is a Drupal website, it opted to use SeamlessDocs for creating online forms, which could provide inspiration for Drupal's webform module. Josh's blog provides an interesting view into what it takes for a government to go paperless and build constituent-centric experiences.

Caribbean sunset

Spending a few days at the Cayman Islands, where the WiFi is weak and the rum is strong. When I relax, I become creative and reflective. Writing helps me develop these creative thoughts and deepens my personal reflection. It's a virtuous cycle, because when I see my world, myself and my ideas more clearly, it helps me relax even more. Relaxing makes me write and writing makes me relax.

Join more than 5,000 others and subscribe to my blog by e-mail:

Last week, Matthew Grasmick stepped into the shoes of a developer who has no Drupal experience, and attempted to get a new "Hello world!" site up and running using four different PHP frameworks: WordPress, Laravel, Symfony and Drupal. He shared his experience in a transparent blog post. In addition to detailing the inefficiencies in Drupal's download process and end-user documentation, Matt also shows that out of the four frameworks, Drupal required the most steps to get installed.

While it is sobering to read, I'm glad Matthew brought this problem to the forefront. Having a good evaluator experience is critical as it has a direct impact on adoption rates. A lot goes into a successful evaluator experience: from learning what Drupal is, to understanding how it works, getting it installed and getting your first piece of content published.

So how can we make some very necessary improvements to Drupal's evaluator experience?

I like to think of the evaluator experience as a conversion funnel, similar to the purchase funnel developed in 1898 by E. St. Elmo Lewis. It maps an end-user journey from the moment a product attracts the user's attention to the point of use. It's useful to visualize the process as a funnel, because it helps us better understand where the roadblocks are and where to focus our efforts. For example, we know that more than 13 million people visited in 2017 (top of the funnel) and that approximately 75,000 new Drupal 8 websites launched in production (bottom of the funnel). A very large number of evaluators were lost as they moved down the conversion funnel. It would be good to better understand what goes on in between.

An example Drupal conversion funnel and the primary stakeholders for each level.

As you can see from the image above, the Drupal Association plays an important role at the top of the funnel; from educating people about Drupal, to providing a streamlined download experience on, to helping users find themes and modules, and much more.

The Drupal Association could do more to simplify the evaluator experience. For example, I like the idea of the Drupal Association offering and promoting a hosted, one-click trial service. This could be built by extending a service like into a hosted evaluation service, especially when combined with the upcoming Umami installation profile. (The existing "Try Drupal" program could evolve into a "Try hosting platforms" program. This could help resolve the expectation mismatch with the current "Try Drupal" program, which is currently more focused on showcasing hosting offerings than providing a seamless Drupal evaluation experience.)

The good news is that the Drupal Association recognizes the same needs, and in the past months, we have been working together on plans to improve Drupal's conversional funnel. The Drupal Association will share its 2018 execution plans in the upcoming weeks. As you'll see, the plans address some of the pain points for evaluators (though not necessarily through a hosted trial service, as that could take significant engineering and infrastructure resources).

The Documentation Working Group also plays a very important role in this process. After reading Matthew's post, I reached out to Joe Shindelar, who is a member of the Drupal Documentation Working Group. He explained that the Documentation Working Group has not been meeting regularly nor coordinating initiatives for some time.

It is time to rethink our approach around Drupal's documentation. Adam Hoenich, a long-time Drupal contributor, recommends that documentation becomes a full-fledged core initiative, including the addition of a Documentation Maintainer to the Core Committer team. His proposal includes blocking commits to Drupal on documentation.

I've no doubt that we have to evolve our governance model surrounding documentation. It's hard to write world-class documentation by committee without good governance and Adam's recommendations are compelling. Drupal's API documentation, for example, is governed by the Core Committers; while there is always room for improvement, it's really well-maintained. Some of you might remember that we had an official Documentation Maintainer role in the past, filled by Jennifer Hodgdon. Reinstating this position could bring documentation back into clearer focus and provide the necessary governance. I also suspect that a stronger emphasis on coordination, governance and recognition for documentation work, would inspire more contributors to help.

Last but not least, this also affects the Drupal (Core) Contributors. Evaluators often spend hours trying to get their web server configured, PHP installed or their database setup. As a community, we could help alleviate this pain by deciding to have a single, recommended default installation environment. For example, we could maintain and promote a Docker container (including an official docker-compose.yml) that ships with the latest version of Drupal. It would simplify many of our documentation efforts, and eliminate many roadblocks from the evaluation process.

To narrow down my recommendations, I would propose the following three steps:

  1. A single, recommended default installation environment (e.g. Docker container) for evaluators or developers taking their first steps in Drupal development.
  2. Infrastructure budget and engineering resources for the Drupal Association so they can offer a true hosted "Try Drupal" service.
  3. A Documentation Maintainer who can focus on end-user documentation, is a member of the Core Committer team and is responsible for defining the scope of what should be documented. Given the amount of work this position would entail, it would be ideal if this person could be at least partially funded.
Of course, there are many other solutions, but these are the areas I'd focus on. As always, success depends on our ability to align on solutions, coordinate all the work, and allocate the time and money to implement the necessary improvements. If you think you can help with any of the proposed steps, please let us know in the comments, and we'll help you get involved.

Earlier this month, I uninstalled Facebook from my phone. I also made a commitment to own my own content and to share shorter notes on my site. Since then, I shared my POSSE plan and I already posted several shorter notes.

One thing that I like about Facebook and Twitter is how easy it is to share quick updates, especially from my phone. If I'm going to be serious about POSSE, having a good iOS application that removes friction from the publishing process is important.

I always wanted to learn some iOS development, so I decided to jump in and start building a basic iOS application to post notes and photos directly to my site. I've already made some progress; so far my iOS application shares the state of my phone battery at This is what it looks like:

My phone's battery level is 78% and it is unplugged

This was inspired by Aaron Parecki, who not only tracks his phone battery but also tracks his sleep, his health patterns and his diet. Talk about owning your own data and liking tacos!

Sharing the state of my phone's battery might sound silly but it's a first step towards being able to publish notes and photos from my phone. To post the state of my phone's battery on my Drupal site, my iOS application reads my battery status, wraps it in a JSON object and sends it to a new REST endpoint on my Drupal site. It took less than 100 lines of code to accomplish this. More importantly, it uses the same web services approach as posting notes and photos will.

In an unexpected turn of events (yes, unnecessary scope creep), I decided it would be neat to keep my status page up-to-date with real-time battery information. In good tradition, the scope creep ended up consuming most of my time. Sending periodic battery updates turned out to be difficult because when a user is not actively using an iOS application, iOS suspends the application. This means that the applications can't listen to battery events nor send data using web services. This makes sense: suspending the application helps improve battery life, and allows iOS to devote more system resources to the active application in the foreground.

The old Linux hacker in me wasn't going to be stopped though; I wanted my application to keep sending regular updates, even when it's not the active application. It turns out iOS makes a few exceptions and allows certain categories of applications – navigation, music and VOIP applications – to keep running in the background. For example, Waze continues to provide navigation instructions and Spotify will play music even when they are not the active application running in the foreground.

You guessed it; the solution was to turn my note-posting-turned-battery application into a navigation application. This requires the application to listen to location update events from my phone's GPS. Doing so prevents the application from being suspended. As a bonus, I can use my location information for future use cases such as geotagging posts.

This navigation hack works really well, but the bad news is that my application drains my phone battery rather quickly. The good news is that I can easily instruct Drupal to send me email notifications to remind me to charge my phone.

Scope creep aside, it's been fun to work with Drupal 8's built-in REST API and to learn some iOS application development. Now I can post my phone's battery on my site, posting notes or photos shouldn't be much more difficult. I'm guessing that a "minimum viable implementation" will require no more than another 100 lines of code and four hours of my time. My current thinking is to go ahead with that so I can start posting from my phone. That gives me more time to evaluate if I want to use the Micropub standard (probably) and the Indigenous iOS application (depends) instead of building and maintaining my own.