Right of the bat, the community summit experienced a small change compared to the previous years – unregulated discussions among participants were replaced by a more organized ones. This year, we were divided into small groups. Each group focused on various problems and issues in the Drupal community and tried to apply agile methodology to them. First, we created some initial analysis of the situation, came up with a solution that was later validated, adjusted and modified by other participants based on their comments and feedback.

I was part of a group where we were discussing the future of DrupalCon in Europe. We are aware of the scarcities of this event. That’s why we compared it to other Drupal events and tried to find out in what ways are those events better. As a result, we concluded that DrupalCon in Europe targets substantially different audience than in America and the needs of this target audience are already adequately satisfied by existing events.However, we’ve found an audience that is currently not being covered by any of the European events. This group of people seeks an event where successful case studies are presented along with their technical solution. By organizing such event, we could possibly attract potential people interested in Drupal.

We came to the conclusion that if DrupalCon would not be held next year, it would offer the opportunity for other, already existing events to thrive. As an example, we can mention the suggested plan of Frontend United or the information about the growth of Drupalcamp in London. Given the circumstances, the return of DrupalCon 2019 might be more complicated than it may seem.

Workshops

The main topic of the “Publishing” summit was decoupled Drupal. Decoupled Drupal means that Drupal is used as a data provider and the whole frontend is built on a different system.

In the first lecture, Richard Jones presented his perspective on personalization of websites based on data from visitors.  By leveraging this data, visitors can be divided into several groups based on, e.g. location, age, or different user habits and browsing routines. Having this type of information at our disposal and analyzing it, gives us the opportunity to tailor individual pages for different groups of visitors, making them more personalized for the user. But Richard also pointed out that with great power (data) comes great responsibility.

The next presentation by Preston So from Acquia highlighted the current need of displaying the same content on different devices – websites on desktops, applications on mobiles, smartwatches, etc. Each of these devices has its specific features, e.g. the amount of information displayed on the screen or the possibility of interaction with the content. Preston even mentioned a completely new way of presenting content by utilizing home (voice) assistants (Google Home, Amazon Echo), where the visual aspect of the content is missing and the interaction with it is done through voice commands. It’s inefficient to create individual content for each device in Drupal. We can’t demand it from the editor to write unique content separately for each device. This is when decoupled Drupal might come in handy. The editor creates one type of content and then, by using the frontend tools, creates a suitable presentation of content for a particular type of device. However, there are some questions left to answer. Is it necessary for the editors to see how the content they created would look on different devices? If yes, then how can we implement this in Drupal?

 
The Burda team created a demo about the newest features of Thunder.  Thunder focuses on publishing houses and offers some interesting modules for Drupal 8 that make it easy to publish stories for the visitors of your website. I like the idea that publishers should not be competing by leveraging their technology, but rather with the quality of their content. This is what led Burda to release Thunder. Good choice of words, right?

After lunch and a few cups of coffee, Sebastian Siemssen and Philip Melab were talking about GraphQL from Facebook and describing how you can easily integrate it with Drupal through the GraphQL module. It was a great example of decoupling and how easy it is to obtain structured data from Drupal. They also explained how this data can be created and updated as well.

The last two presentations showed different approaches to decoupling – distribution Reservoir and distribution Contenta. Both of them focus on the creation of back office systems in a more accessible way, which then can provide data for a frontend application through simple and documented API. I like the approach of Reservoir that uses general software development terminology, which means that a developer who hasn’t worked with Drupal before, should be able to create a simple API. There are some great news for frontend developers as well. They can finally work with the latest frontend technologies without any restrictions.

Here, at MADE It Digital, we consider decoupling the future of web development. It can bring back simpler and more affordable Drupal websites. Based on these technologies, we have just launched a website for the  24 Production marketing agency. If you are interested in our approach, don’t hesitate and feel free to contact us.