Drupal

There are a number of great reasons to consider a headless architecture for a web project. I sometimes hear site speed listed as a primary motivation. Is a headless website guaranteed to be faster? Let's explore this idea.

Conversations with other people in the Drupal community, and related communities, has been a continued source of inspiration for me. Back in September, in a discussion at the San Francisco Drupal Users Group, someone mentioned a Backdrop module that uses Javascript to automatically format dates and times in the timezone of any visitor using Javascript.

It's been a while since I shared an update on how Smart Date is evolving, so I thought I should do a rundown of some of the recent features and developments. Even people using the module every day may not be aware of all the changes, unless they've been combing through the release notes.

Something I've enjoyed since starting work on the Smart Date module has been seeing it grow and evolve in ways I wouldn't have expected, in response to the community. I had three specific goals in the beginning: a more "app-like" and intuitive widget, natural language, deduplicated date range output, and more efficient storage of dates and times. Soon after its release, requests started to come in for additional features: calendar integration, repeating events, support for timezones, and more.

When I think about the admin experience of Drupal, I often think about context. 

As a longtime Drupal user, it's easy enough for me to know that wherever I am in a Drupal site, there's a predictable spot in the admin menu where I can select a content type and start creating content. For people new to Drupal, or even new to the concept of managing website content, this is nowhere near as obvious. Training will help, but we can also employ the principle of multimodal interaction to provide additional options in ways that will be more obvious.

The JAMstack seems to be what's getting a lot of press lately, but there's actually a lot to be excited about in the Drupal technology stack of late.

Something I've been passionate about for a while has been the admin experience we create to support the sites we build in Drupal. I remember a while ago noticing that particularly for site I was building for less technical clients, I would often spend at least as much time making the content editor experience easy to use as I spent on the public face of the site.

There were a few key principles that guided me: