usability

Together with zrpnr, gabesullice, lauriii, bnjmnm, yashrode and hooromoo in Acquia’s Drupal Acceleration Team, I’ve been working on getting Drupal on CKEditor 5, because CKEditor 4 is reaching the end of its long and productive life.

zrpnr got it started in January 2021. We’ve been meeting with Reinmar ¹ from the CKEditor 5 team to ensure a smooth automatic upgrade path from CKEditor 4: all functionality should be even better! Less than 10 months later, on November 11, 2021, CKEditor 5 was committed to Drupal 9.3!

2007 is the year of my first DrupalCon, and the year the #1 most wanted end-user feature was Better media handling. 2019 is the year that Drupal will finally have it. Doing things right takes time!

Back then I never would’ve believed I would someday play a small role in making it happen :)

Without further ado, and without using a mouse:

The text editor assisted in producing this HTML:

<p>Let's talk about llamas!</p>

<drupal-media alt="A beautiful llama!" data-entity-type="media" data-entity-uuid="84911dc4-c086-4781-afc3-eb49b7380ff5" class="align-center"></drupal-media>

<p>(I like llamas, okay?)</p>

If you’re wondering why something seemingly so simple could have taken such a long time, read on for a little bit of Drupal history! (By no means a complete history.)

Drupal 8 will ship with big authoring experience improvements: WYSIWYG editing & in-place editing, thanks to the Spark distribution that Acquia — my employer — is sponsoring.

But how well does it fare with the growing importance of structured content? Do Drupal 8’s WYSIWYG & in-place editing enable it or prevent it?

The new web world order: many form factors

The Big Thing of the last few years: the advent of mobile. Inherent to that: websites that are optimized for mobile devices and act as data providers for apps.

A new form factor — mobile devices — changed web development forever. Before mobile, the life of web developers and authors (content creators) was relatively simple: make sure websites work well on a few typical screen sizes (let’s deny the existence of Internet Explorer 6 and all the misery it caused).

But … we cannot predict what’s next. We cannot predict new content consumption form factors. That’s where content strategy becomes vitally important:

content strategy is to copywriting as information architecture is to design

A few weeks ago, we showed the in-line editing prototype we had built for Spark, which has now blossomed into Edit module. Additionally, we also pointed out that we were in the process of selecting the WYSIWYG editor to use in Spark. This selection process was performed in the public Spark issue queue, in order to gather community feedback and to attempt to reach consensus. 73 people followed that issue, about two dozen of whom contributed to the discussion as well.

API {#api}

The API of the previous version of HS was a beast. Well, not the API, but the implementations. This has been fixed in version 2 of HS: it’s now much more elegant and much easier. If you don’t have to alter any forms, you can easily implement all hooks in less than a hundred lines, probably even less. The content_taxonomy implementation for example, is about 75 lines if you don’t count the form altering. That should make HS much more attractive to other Drupal developers.

Support Hierarchical Select Dynamically {#support-hierarchical-select-dynamically}

One of the low-hanging fruits is to support HS dynamically (i.e. use hierarchical select form items when HS is installed, use normal selects otherwise).

If your module provides its own hierarchical structure for which you want to use HS, you’ll have to implement the hooks. Next, I assume you have something like this in your form:

What is Hierarchical Select? {#what-is-it}

For those who don’t know Hierarchical Select yet, or HS in short, this is a module that provides a new form element. If you’re new to Drupal, you may just have frowned upon reading that. A ‘form element’ in Drupal’s Forms API is something like a button, select or textarea element in HTML, or a GUI widget in a GUI.

Now, the goal of HS is actually very narrow: making selections in hierarchies (hence its name) really simple: improve usability. The prime example and candidate for this is of course Drupal’s Taxonomy module. The idea is to first select an item from the root level, then pick one of its children (if it has any), then one of the children of the selected child (if it has any), and so on.

New and Improved {#new-and-improved}

There are many new features in version 2 of Hierarchical Select (or HS in short):