The Inline Editing Kerfuffle

Aaron Manire // June 2013

One of the more memorable moments from DrupalCon last month was the keynote by Karen McGrane. It’s a thrilling and motivating speech, but the point that probably stood out most was McGrane’s dismissal of the Spark inline editing initiative as something that was “ginned up by marketing”. Personally, I wasn’t surprised, since she had expressed her feelings about inline editing back in November on Lullabot’s excellent Insert Content Here podcast. But I think many attendees were taken by surprise, including, Dries Buytaert, the founder of Drupal and Acquia.

I base this hunch on Buytaert’s recent blog post, which took clear, almost wounded, umbrage at this remark. Acquia, for good reason, is, no doubt, proud of their success at getting Spark into Drupal 8 core. This was no small achievement. If I recall correctly, Buytaert championed inline editing as a goal for Drupal back in 2011, and for good reason. Content editors have struggled with Drupal’s modal user interface since the beginning.

Content à la Mode

I should probably clarify what I mean by modal. When working with content, Drupal displays two tabs: View and Edit. By default, after clicking the edit tab, the user is whisked away to the administrative theme, which is distinctively spartan and linear in comparison to how site visitors see the content. There is no mistaking that this is the edit mode. After submitting, or navigating away, the regular theme reappears and the view mode1 returns.

Some text editing applications also use a modal interface. Vim is an example of a modal text editor. Personally, I prefer emacs, which is modeless.2 There’s something to be said for the ability to immediately and seamlessly insert or edit text as you are reading it. There is less work and frustration than having to ceaselessly toggle between modes. And less friction means less subconscious resistance, which means more and better content. So, I understand the attraction to inline editing. It isn’t just marketing hype, it solves a real usability challenge.

McGrane’s concern is that cross-channel publishing, responsive design and the rapid flux of display technologies have exploded the digital metaphor of the printed page. And, instead of dispelling content creators of this illusion, Drupal 8 core will reinforce this vestigial metaphor by providing an inline editing mode and built-in WYSIWYG editor that privilege the desktop web browser because that’s where content editors get their work done.

Instead, McGrane argues that Drupal’s developers should be inventing new approaches and technologies that compel content creators to understand semantic markup and visualize the wider display possibilities of their words and media. One example she cites elsewhere, is a rendering interface that previews content in a desktop web, mobile web and app. But, mostly, we are left to our imaginations for answers.

Content Lifecycles

First of all, I think the criticism of Spark inline editing is overblown. The inline editor mode only appears when content is being edited and is irrelevant during the creation of content. This means that Drupal 8 users are exposed to the full edit mode fielded user interface whenever they create new content, even if they always use inline editing for existing content. So, unless they are happy recycling their finite supply of nodes, post-launch, they will at some point, have to reconcile themselves to working through a fielded form replete with structures and metadata.

Secondly, projects have finite lifespans. The content of some websites just doesn’t need to be abstract enough to easily reorganize and re-render in any conceivable future device. Drupal site builders have to find this balance for every project. Budget constraints always impose a limit to abstraction and automation. At some point, a page or block text area instead of a dynamically generated list is going to be good enough. And good enough is beautiful. Some websites just aren’t meant to be browsed on the refrigerators of flying cars.

The Here and Now

The preview button may be dead, but It’s not clear that user interface design alone can cure this desktop myopia. It’s one thing to evangelize for the future of Internet publishing, but we are faced with the work of building websites today and tomorrow. Our work is filled with budgets, compromises and exigency. We have to prioritize website features. We have to collaborate with content editors to build appropriate structures and train them on their usage.

Ultimately, I don’t think this an either/or decision. I think inline editing and well-structured, semantic markup are solid ideas and we can have both.

For a more in-depth look at the trade-offs involved with inline editing, be sure to checkout Jeff Eaton’s awesome blog post, Inline Editing and the Cost of Leaky Abstractions.

 

1. There are actually six view modes (Full content, Teaser, RSS, Search Result, Search Index, and Tokens) bundled in core. Wouldn’t it be interesting if Drupal also came bundled with multiple edit modes?

2. While writing this blog post, I discovered that there is a modal version of emacs.

 

Aaron Manire Headshot

Aaron Manire

Director of Web Development

I coordinate Drupal development teams and plan technological growth, and like to get my hands dirty with code when I can. I enjoy that at Isovera I’m constantly learning new things, sharing that knowledge with others, and working with the terrific people who make our work possible.

Filed under: