Improving the UX of updating Drupal sites with Composer: Greg Anderson & Ryan Aslett | DrupalCon Vienna

At DrupalCon Vienna I had the pleasure of meeting Greg Anderson & Ryan Aslett. Greg is a Open Source Contributions Engineer at Pantheon & Ryan is the Testbots/Composer/QA/Infra Engineer at the Drupal Association. The main DrupalCon had finished the previous day, but as there were still a few people around, they had organised a hotel lobby sprint along with Joël Pittet.

They’d asked me to feedback my experiences as a sitebuilder updating Drupal 8 websites and I mentioned that I was using Composer, but also knew that I was working much like a developer would than other sitebuilders that may be doing manual updates or using Drush.

I felt the cogwheels turning in my head and thought it would be great if we could make video together highlighting the project and raising awareness of such a great initiative. The conversation continued over burgers, and the inspiring architecture you see in the video was the building next door. It was at this moment we all knew we had to make the video.

Read more about our day in my other blog post The power of community collaboration at DrupalCon Vienna.

 

Transcription

Greg started by sharing that face to face collaboration was a lot faster than communicating online. He had been talking with Ryan about modules and extensibility.

For many years people have loved the fact they can just download Drupal from Drupal.org, and how easy it is to download the modules you want and customise your site for your market.

But now as the PHP world is evolving we have this new thing called Composer. Now Composer is really cool in some respects as it being a dependency manager allows you to pick software from other places and compose them together in a really cool way, which helps Drupal get off the island. Its not just our software in a self-contained ball, but we can leverage things that are done in other parts of the community.

But with all of this great power, Composer also brings with it some challenges. One of these is that as a dependency manager, its really important that you let Composer do its job. You have to take all the dependencies and put them together at the same time, so that the Composer solver can decide which versions of the software are going to work together. This makes our existing model of just easily downloading modules from Drupal.org difficult because it makes it difficult for end sites to have the resources to run the Composer solver. We’ve been talking about different ways that we might break this open, and preserve the same user experience while still enabling the power of Composer.

Ryan mentioned that he worked on packages.drupal.org for the Drupal Association which enabled Composer to be a tool that the community could use with our existing module set. Once that was in place, and he saw it was in place, with more and more people adopting it, that’s when he realised there were some users that were being left behind. He was afraid that he had created this new thing, that was a monster, and wanted to go back and see how we could solve this problem so that everyone that built a Drupal site had an easy and valuable experience that made it possible for them to build a site.

Lots of ideas have been flowing around, starting with some at DrupalCon Baltimore where there was an initial plan but it never really took off. The plan was to have a desktop application to manage your Drupal site. They realised that they didn’t really have the skills and resources in the community to manage something like that. Once they really started looking at the problem, they realised that we already had a solution built into Drupal core that we could use for this, but it had been a bit neglected. Once they started assessing the Update Manager in core, they realised that this could actually be the avenue by which people have a great experience extending Drupal.

They feel that part of the reasons that Update Manager became neglected was as it was an alternative path to update sites than the ones that hard-core developers or people with complex sites used, leading to it not seeing any development or features being added. They decided what we really needed was a tool in core that both developers and consumers of the Update Manager used.

They’re brainstorming some ideas around including Task Managers. If they can get one of those into core, that will also help us solve some of the problems we’re seeing in the testing and deployment spaces.

The project is really preliminary at the moment, they’re currently asking a lot of people what their needs are and making sure all the use cases are covered because they don’t want to leave anybody behind. We want to make sure that Drupal had the ability to be used where people want to use it.

Greg mentioned that DrupalCon Vienna had been an excellent place to talk about these things and that it was really exciting to see some of these things and issues move forwards. It makes things more concrete and real.

Ryan has received a lot of feedback.

When speaking to his friend Amber from Portland, who works for Drupalize.me, she suggested “if this tool does all of these hard core developer things under hood, maybe give the end users the ability to expand that out so if they’re curious and want to learn, they have the ability to see what it’s actually doing”. I thought that was a great idea as it allows people to transition from not knowing what the tool does, to allowing them to look under the hood and see for themselves.

Another suggestion was that it might be that the task runner might not have the resources it needs to run on the local system so we might need to provide a service that allows that. It may be that that could be offered by Drupal.orgnext to packages.drupal.org, or we resolve their dependencies for them and give them back out.

Ryan has been working with other people apart from Greg on this project too, including Bojan Živanović (Commerce Guys) and other people in the #Composer channels in Drupal slack & IRC.

He’s noticed a lot of threads opening up on Drupal.org saying things like “don’t leave us behind”, so he’s been speaking with them by email and in the issue queues to ask “what do you need, how can we help you, how can we make sure that this does what we need it to do”.

Greg said he thinks its a really exciting opportunity to make Drupal every bit as excellent as It was for the older mechanism as it will be in the future. Really easy for new users, while yet being powerful enough for developers. It’s a really exciting time to be involved with Drupal.

They’re currently working on the project plan with the starting point of “what if it did everything we wanted it to do” and then going from there. Then go down to the minimal viable product, but still have the vision of a future roadmap. This is better than making a quick bandaid for what we need.

Once the project plan is in place, usr experience will be the need consideration. Like Dries said in his keynote “design first”, we’ll look at what are the use cases, how do I concentrate on how this looks, feels and works so that we can provide what people need rather than a bottom up thing inside the development space.