by Jeff Eaton on December 11, 2012 // Short URL

Inline Editing and the Cost of Leaky Abstractions

Inline WYSIWYG editing can improve life for some content managers, but brings new problems for content-rich sites.

For several years, core Drupal contributors have been working on ways to improve the user experience for content editors. Since May of 2012, project lead Dries Buytaert and his company Acquia have been funding the Spark Project, an ambitious set of improvements to Drupal's core editing experience. One of the most eye-popping features they've demonstrated is Inline WYSIWYG editing, the ability to click on a page element, edit it in place, and persist the changes without visiting a separate page or opening a popup window.

Chances are good that inline editing functionality could make it into Drupal 8 -- specifically, an implementation that's powered by Create.js and the closely associated Aloha WYSIWYG editor. Fans of decoupled Drupal code definitely have something to cheer for! The work to modernize Drupal 8's codebase is making it much easier to reuse the great front-end and back-end work from open source projects like Symfony and Create.js.

With that good news, though, there's a potential raincloud on the horizon. Inline editing, as useful as it is, could easily be the next WYSIWYG markup: a tool that simplifies certain tasks but sabotages others in unexpected ways.

Direct manipulation: A leaky abstraction

Over a decade ago, software developer Joel Spolsky wrote a critically important blog post about user experience: The Law of Leaky Abstractions. He explained that many software APIs are convenient lies about more complex processes they hide to simplify day-to-day work. Often these abstractions work, but just as often the underlying complexity "leaks through."

One reason the law of leaky abstractions is problematic is that it means that abstractions do not really simplify our lives as much as they were meant to.

The law of leaky abstractions means that whenever somebody comes up with a wizzy new code-generation tool that is supposed to make us all ever-so-efficient, you hear a lot of people saying "learn how to do it manually first, then use the wizzy tool to save time." Code generation tools which pretend to abstract out something, like all abstractions, leak, and the only way to deal with the leaks competently is to learn about how the abstractions work and what they are abstracting. So the abstractions save us time working, but they don't save us time learning.

And all this means that paradoxically, even as we have higher and higher level programming tools with better and better abstractions, becoming a proficient programmer is getting harder and harder.

Those words were written about APIs and software development tools, but they're familiar to anyone who's tried to build an humane interface for a modern content management system.

At one extreme, a CMS can be treated as a tool for editing a relational database. The user interface exposed by a CMS in that sense is just a way of giving users access to every table and column that must be inserted or updated. Completeness is the name of the game, because users are directly manipulating the underlying storage model. Any data they don't see is probably unnecessary and should be exorcised from the data model. For those of us who come from a software development background this is a familiar approach, and it's dominated the UX decisions of many open source projects and business-focused proprietary systems.

At the other extreme, a CMS can be treated as an artifact of visual web design. We begin with a vision of the end product: a photography portfolio, an online magazine, a school's class schedule. We decide how visitors should interact with it, we extrapolate the kinds of tasks administrators will need to perform to keep it updated, and the CMS is used to fill those dynamic gaps. The underlying structure of its data is abstracted away as WYSIWYG editors, drag-and-drop editing, and other tools that allow users to feel they're directly manipulating the final product rather than markup codes.

The editing interfaces we offer to users send them important messages, whether we intend it or not. They are affordances, like knobs on doors and buttons on telephones. If the primary editing interface we present is also the visual design seen by site visitors, we are saying: "This page is what you manage! The things you see on it are the true form of your content." On certain sites, that message is true. But for many, it's a lie: what you're seeing is simply one view of a more complex content element, tailored for a particular page or channel.

In those situations, Inline WYSIWYG editing is one of Joel Spolsky's leaky abstractions. It simplifies a user's initial experience exploring the system, but breaks down when they push forward -- causing even more confusion and frustration than the initial learning would have.

A brief interlude, with semantics

With that provocative statement out of the way, I'll take a step back and define some terminology. Because Drupal's administrative interface, the improvements added by the Spark project, and the nature of web UX are all pretty complicated, there's a lot of potential for confusion when a term like "Inline Editing" gets thrown around. There are four kinds of editing behaviors that we'll touch on, and clarifying how they differ and overlap will (hopefully) prevent some confusion.

Contextual editing

When a content editor is on a particular portion of the web site or is viewing a particular kind of content, they should have access to options and tools that are contextually relevant. If an editor visits an article on their web site, give them access to an "Edit" link for that article. If it's unpublished, they should see a "Publish" link, and so on. Contextual editing also means hiding options from users when they're inappropriate. If you don't have permission to modify an article, you shouldn't see the "Edit" link.

Well-designed contextual editing is a great thing! It puts the right tools in the users' hands when they're needed, and helps prevent "option overload"."

API-based editing

Rather than rendering an HTML form, API-based editing means bundling up a copy of the content object itself -- usually in a format like XML or JSON -- and sending it to another program for editing. That "Client" could be Javascript code running on a user's browser, a native mobile app, or another CMS entirely. The client presents an editing interface to the user, makes changes to the object, and sends it back to the CMS they're done.

API-based editing is cool, too! It's not a specific user-visible widget or workflow. In fact, it could be used to deliver the very same HTML forms users are used to -- but it provides a foundation for many other kinds of novel editing interfaces.

Inline editing

Inline editing takes contextual editing a step farther. When you see data on the page, you don't just have a link to edit it at your beck and call: you can edit it right there without going to another page or popup window. One common scenario is tabular data: click in a cell, edit the cell. Click outside of the cell, and your changes are saved. A more complex example might include clicking on the headline of an article and editing it while viewing it on the front page, or clicking on the body text and adding a new paragraph then and there. The emphasis here is on eliminating context switches and unecessary steps for the editor.

Inline editing can dramatically simplify life for users by replacing cluttered forms, fields, and buttons with direct content manipulation. However, when direct manipulation the primary means of editing content, it can easily hide critical information from those same users. We'll get to that later.

WYSIWYG editing

"What You See Is What You Get" editing is all about allowing users to manipulate things as they will appear in the finished product rather than using special codes, weird markup, or separate preview modes. Desktop publishing flourished on 1980s Macintosh computers because they let would-be Hearsts and Pulitzers lay out pages and set type visually. WYSIWYG HTML editors have been popular with web content editors for similar reasons: finessing the appearance of content via clicks and drags is easier than encoding semantic instructions for web browsers using raw HTML.

WYSIWYG editing tools can help reduce markup errors and streamline the work of content managers who don't know HTML. Without careful restrictions, though, it can easily sabotage attempts to reuse content effectively. If a restaraunt's menu is posted as a giant HTML table in the "Menu" page's Body field, for example, there's no way to highlight the latest dishes or list gluten-free recipes. Similarly, if the key photo for a news story is dropped into that Body field with a WYSIWYG editor, reformatting it for display on a mobile phone is all but impossible.

Everything in-between

Often, these four different approaches overlap. Inline editing can be thought of as a particularly advanced form of contextual editing, and it's often built on top of API-based editing. In addition, when inline editing is enabled on the visitor-visible "presentation" layout of a web site, it functions as a sort of WYSWIWG editing for the entire page -- not just a particular article or field.

That combined approach -- using inline editing on a site's front end to edit content as it will appear to visitors -- is what I'll be focusing on. It's "Inline WYSIWYG."

Inline WYSIWYG! Can anything good come from there?

Of course! Over the past year or so, anything with the word 'WYSIWYG' in it has taken a bit of a beating in web circles, but none of the approaches to content editing listed above are inherently good or bad. Like all tools, there are situations they're well-suited for and others that make an awkward fit.

Ev Williams, the co-founder of Blogger and Twitter, recently wrote about why his team has made inline editing and WYSIWYG the native editing interface for their blogging tool, Medium.

As I’m writing this, I see not just a WYSIWYG editor, I see the page I’m going to publish, which looks just like the version you’re reading. In fact, it is the version you’re reading. There’s no layer of abstraction. This is a simple (and old) concept… and it makes a big difference. Having to go back and forth between your creation tool and your creation is like sculpting by talking.

That's an incredibly compelling argument for the power of WYSIWYG and inline editing. I've seen it in action on Medium, and it really does feel different than the click-edit-save, click-edit-save cycle that most web based tools require. However, and this is a big however, it's also critical to remember the key restrictions Ev and his team have put in place to make that simplicity work.

One of the reasons its possible to have this really WYSIWYG experience is because we’ve stripped out a lot of the power that other online editors give you. Here are things you can’t do: change fonts, font color, font size. You can’t insert tables or use strikethrough or even underline. Here’s what you can do: bold, italics, subheads (two levels), blockquote, and links.

In addition, the underlying structure of an article on Medium is very simple. Each post can have a title, a single optional header image, and the body text of the article itself. No meta tags, no related links, no attached files or summary text for the front page. What you see is what you get here, too: when you are viewing an article, you are viewing the whole article and editing it inline on the page leaves nothing to the imagination.

This kind of relentless focus -- a single streamlined way of presenting each piece of content, a mercilessly stripped down list of formatting options, and a vigilant focus on the written word -- ensure that there really is no gap between what users are manipulating via inline editing and what everyone else sees.

That's an amazing, awesome thing and other kinds of focused web sites can benefit from it, too. Many small-business brochureware sites, for example, have straightfoward, easily-modeled content. Many of those sites' users would kill for the simplicity of a "click here to enter text" approach to content entry.

The other side(s) of the coin

Even the best tool, however, can't be right for every job. The inline WYSIWYG approach that's used by Create.js and the Spark Project can pose serious problems. The Decoupled CMS Project in particular proposes that Inline WYSIWYG could be a useful general editing paradigm for content-rich web˙sites, but that requires looking at the weaknesses clearly and honestly.

Invisible data is inaccessible

Inline editing, by definition, is tied to the page's visible design. Various cues can separate editable and non-editable portions of the page, but there's no place for content elements that aren't part of the visible page at all.

Metadata tags, relationships between content that drive other page elements, fields intended for display in other views of the content, and flags that control a content element's appearance but aren't inherently visible, are all awkward bystanders. This is particularly important in multichannel publishing environments: often, multiple versions of key fields are created for use in different device and display contexts.

It encourages visual hacks

Well-structured content models need the right data in the right fields. We've learned the hard way that WYSIWYG markup editors inevitably lead to ugly HTML hacks. Users naturally assume that "it looks right" means "everything is working correctly." Similarly, inline WYSIWYG emphasizes each field's visual appearance and placement on the page over its semantic meaning. That sets up another cycle of "I put it there because it looked right" editing snafus.

The problem is even more serious for Inline WYSIWYG. Markup editors can be configured to use a restricted set of tags, but no code is smart enough to know that a user misused an important text field to achieve a desired visual result.

It privileges the editor's device

In her book Content Strategy for Mobile, author Karen McGrane explains the dangers of the web-based "preview" button.

…There's no way to show [desktop] content creators how their content might appear on a mobile website or in an app. The existence of the preview button reinforces the notion that the dekstop website is the "real" website and [anything else] is an afterthought.

Inline WYSIWG amplifies this problem, turning the entire editing experience into an extended preview of what the content will look like on the editor's current browser, platform, screen size, and user context. The danger lies in the hidden ripple effects for other devices, views, publishing channels, and even other pages where the same content is reused.

It complicates the creation of new items

Create.js and the Spark Project also allow editors to create new content items in place on any listing page. This is a valuable feature, especially for sites dominated by simple chronological lists or explicit content hierarchies.

On sites with more complex rule-based listing pages, however, the picture becomes fuzzier. If an editor inserts a new piece of content on another author's page, does the content become owned by that author? On listing pages goverened by complex selection rules, will the newly-inserted item receive default values sufficient to ensure that it will appear on the page? If the editor inserts new content on a listing page, but alters its fields such that the content no longer matches the listing page's selection rules, does the content vanish and re-appear in a different, unknown part of the web site?

In addition, multi-step workflows accompany the creation of content on many sites. Translating a single piece of content into several legally mandated languages before publication is necessary in some countries, even for small web sites. Approval and scheduling workflows pose similar problems, moving documents through important but invisible states before they can be displayed accurately on the site.

Complexity quickly reasserts itself

Many of the problems described above can be worked around by adding additional visual cues, exposing normally hidden fields in floating toolbars, and providing other normally hidden information when editors have activated Inline WYSIWYG. Additional secondary editing interfaces can also be provided for "full access" to a content item's full list of fields, metadata, and workflow states.

However, the addition of these extra widgets, toolbars, hover-tips, popups, and so on compromise the radical simplicity that justified Inline Editing in the first place. On many sites, a sufficiently functional Inline WYSIWYG interface -- one that captures the important state, metadata, and relational information for a piece of content -- will be no simpler or faster than well-designed, task-focused modal editing forms. Members of the Plone team discovered that was often true after adding Inline WYSIWYG to their CMS. After several versions maintaining the feature, they removed it from the core CMS product.

To reiterate Ev William's vision for Medium,

There’s no layer of abstraction. This is a simple (and old) concept… and it makes a big difference. Having to go back and forth between your creation tool and your creation is like sculpting by talking.

In situations where Inline WYSIWIG can't live up to that ideal, it paradoxically results in even more complexity for users.

In conclusion, Inline WYSIWYG is a land of contrasts

So, where does this leave us? Despite my complaints, both Inline and WYSIWYG editing are valuable tools for building an effective editorial experience. The problem of leaky abstractions isn't new to Drupal: Views, for example, is a click-and-drag listing page builder, but requires its users know SQL to understand what's happening when problems arise. As we consider how to apply the tools at our disposal, we have to examine their pros and cons honestly rather than fixating on one or the other.

The combined Inline WYSIWYG approach can radically improve sites that pair an extremely focused presentation with simple content. But despite the impressive splash it makes during demos, Inline WYSIWYG as a primary editing interface is difficult to scale beyond brochureware and blogs. On sites with more complex content and publishing workflows, those training wheels will have to come off eventually.

Is Inline WYSIWYG right for Drupal core? While it can be very useful, it's not a silver bullet for Drupal's UX werewolves. Worse, it can actively confuse users and mask critical information on the kinds of data-rich sites Drupal is best suited for. Enhanced content modeling tools and the much-loved Views module are both built into Drupal 8; even new developers and builders will easily assemble sites whose complexity confounds Inline WYSIWYG.

At the same time, the underlying architectural changes that make the approach possible are incredibly valuable. If Drupal 8 ships with client-side editing APIs as complete as its existing server-side edit forms, the foundation will be laid for many other innovative editing tools. Even if complex sites can't benefit from Inline WYSIWYG, they'll be able to implement their own appropriate, tailored interfaces with far less work because of it.

Like WYSIWYG markup editors, design-integrated Inline WYSIWYG editing is an idea that's here to stay. Deciding when to use it appropriately, and learning how to sidestep its pitfalls, will be an important task for site builders and UX professionals in the coming years. Our essential task is still the same: giving people tools to accomplish the tasks that matter to them!

Jeff Eaton

Senior Digital Strategist

Want Jeff Eaton to speak at your event? Contact us with the details and we’ll be in touch soon.

Comments

Micah Godbolt

Personal Experience

Content creating/editing workflow has always been an interesting challenge, and I like how thoroughly you've laid out those challenges.

I think the answer is that there is never going to be a perfect solution that works for every use case. The best a CMS can do is offer developers the tools they need to customize that workflow as best as they can.

I recall building a CMS Made Simple site recently that was 90% page based and 10% abstracted content. The 90% would have greatly benefited from inline editing as the content was very text focused, and that data only lived in a single place.

But the other 10% this data was created and edited in a separate modules (blogs, news, lists of vendors etc). This caused a bit of confusion for the users as they had to remember what data could be edited on the page, and what had to be edited in a separate module.

This might have made me think that some form of inline editing would be preferred, but as you stated, this form of abstraction would hide all of the non visual meta data about the object. Worse yet, this also lulls the user into a false sense of understanding of what editing this data will do. If I edit this news entry on this page, how is that going to change other pages where teasers and snippets are displayed, like the homepage?

So my TL:DR is that we need to first focus on the site's users, how they should be interacting and editing content. Maybe content creation needs to be through a wizard tool, and then further editing is inline. Whatever the decision is, it's important to get that nailed down early in the process so that you can pick the CMS, modules and workflow needed to make all of that work.

Reply

eaton

No silver bullets

I think the answer is that there is never going to be a perfect solution that works for every use case. The best a CMS can do is offer developers the tools they need to customize that workflow as best as they can.

Amen to that. This is where I want to be sure the intent of the post is tempered, too -- Inline WYSIWYG isn't a bad thing, just one that is dangerous to apply indiscriminately. In some ways it reminds me of the "endless scrolling" pages that took off a couple of years ago. It's a huge improvement over pagers for certain kinds of content -- river-of-news lists of microcontent, etc. For others, it's a detriment -- product listings, search results, and so on where you might actually need to return to specific *pages* of a discrete resultset.

Considering the implications of our UX tools, what trade-offs are inherent to them, and the nature of what we're trying to build with them -- all equally important tasks.

Reply

Lalit

Awesome

thanks for sharing. i have used spark profile. it really works well. but modules are not currently works well independently due to under development. i think after this module fully integration it make drupal really interactive.

Thanks

Reply

Bojhan Somers

Thanks for such an indepth

Thanks for such an indepth exploration into the details of inline editing. I believe we are technically getting closer and closer, to the point where inline editing is a significant alternative to actual editing interfaces.

Editing values/settings that are not part of the page

There are a lot of values and settings, that are indeed not visible on the page. That however is not different to many other visual tools; Photoshop, 3DMax etc. You will need a consistent "tools" area for these settings, and granularity to allow for this area to expand. You will see more and more tools that offer inline editing as the primary UI, use these kind of toolbox's (e.g. Concrete5) - it's not yet there in terms of UX - but getting closer to the earlier mentioned more mature tools. This could be placed within task-focused workflows, but its not easy - as Plone found, Drupal is not tackling this yet either - and that is worry some. I am not sure I agree, with the assumption it is therefor impossible - for it to exist within these more complex workflows.

Not a "true" inline WYSIWYG

The one thing that worries me deeply, is when a inline WYSIWYG does not resemble reaility. Having used many many inline editing tools, they still often break on more complex widgets (tables, images). Because the aim is "true WYSIWYG" and with that resemblance, whenever the inline editor breaks a significant part of the *magic* feels clunky and people will not trust it. An editing interface is not a resemble therefor people do not expect much. See http://scottmccloud.com/4-inventions/triangle/index.html more on the thinking behind this.

In the current state, I expect inline editing to be disabled on medium/large Drupal project. But attract a lot of new users to our platform in our bottom long-tail. Ideally we find ways to solve some the workflow problems, that arise for medium/large Drupal shops - but this would require people like you to help out :)

Reply

eaton

Agreements all around!

Thanks for replying, Bojhan! I want to make clear that I'm not suggesting Inline WYSIWYG is bad, just that it deserves a lot of caution before a site builder rolls it out for the long-term site administrators. Its appropriateness is site, content, and team specific rather than technology or size specific.

There are a lot of values and settings, that are indeed not visible on the page. That however is not different to many other visual tools; Photoshop, 3DMax etc.

Agreed -- we've had great success with floating toolbars and other contextual overlays on a number of sites, particularly the WWE.com redesign. Their internal team relies on a floating "administrator overlay" that gives all sorts of contextual information about the current page and the content on it, including publish/draft status, scheduling information, links to related sub-pages, and links to edit forms.

The one thing that worries me deeply, is when a inline WYSIWYG does not resemble reaility. Having used many many inline editing tools, they still often break on more complex widgets (tables, images). Because the aim is "true WYSIWYG" and with that resemblance, whenever the inline editor breaks a significant part of the *magic* feels clunky and people will not trust it.

Definitely. I tried to distinguish between "Contextually available tools" and "Inline WYSIWYG" in the article, but I'm not sure it was clear enough. The more overlays, popups, status bars, and so on we add to the mix, the farther we're moving from the actual "Inline WYSIWYG" paradigm. We're really just implementing "one-field-at-a-time editing," without the benefit of a focused, streamlined form that consolidates the relevant data. It couples the design of our editing interface and the design of our presentation interface unnecessarily.

3DMax is a perfect example of the problem that I'm trying to underline. Until we have ubiquitous 3D monitors, there's no way to give a truly accurate editing interface that captures the fullness of a 3D model at a glance. Sometimes, you have to pan around and look at things from a different camera angle. Other times, you'll open dedicated dialogue boxes that allow you to edit the profile of a given object in a dedicated space. The different tools are there to give modelers task-appropriate windows onto an underlying model that is (obviously and unashamedly) too much to fit into a single 2D image.

There are some 3D modeling programs that present a "WYSIWYG" view of the modeling space. (I'm thinking in particular of 123D Sculpt for the iPad, but there are more out there.) It allows users to rotate a model, deform it, shape it, skin it with textures, and so on. There is no separate "rendering" mode or additional step once they've finished: they simple stop tweaking the model, take a picture, and voila! It's done. It's the "Inline WYSIWYG" of 3D modeling, and it's incredibly accessible and straightforward.

However, it scales very badly to more complex 3D work. If you're building a large, multi-object scene where "the shot" is composed of several objects, 123D Sculpt's WYSIWYG approach becomes something to work around rather than a time-saver. Other natural applications for 3D models, like fly-throughs, are also tough to shoehorn into the direct manipulation model.

In the current state, I expect inline editing to be disabled on medium/large Drupal project. But attract a lot of new users to our platform in our bottom long-tail. Ideally we find ways to solve some the workflow problems, that arise for medium/large Drupal shops - but this would require people like you to help out :)

This is a good view, IMO -- one of the biggest concerns for me is the talk that I hear in many circles of Inline WYSIWYG being "the correct way to edit content". It has impressive demo-appeal, and it's good for models where direct manipulation of the full content model is possible without too much "editing chrome." Enabling it by default, I fear, will leave a lot of new site-builders with the impression that this is true.

In some ways it's like the "Endless Scrolling" pattern that became popular several years ago. It's a great way to present river of news style updates, but it's inappropriate in many other situations: product pages, archive listings, and other places where users should be able to return to explicit pages in a set; listings that are not at the actual physical bottom of a page; and so on. The fact that it solves real UX issues in one set of situations doesn't mean that it just needs "more polishing" to be applied in all situations.

I'm still unconvinced that Inline WYSIWYG -- as opposed to well-build contextually available edit screens -- is the right choice for those workflow-heavy, content-rich sites. But I'm happy to dive into the conversations. ;-)

Reply

Philipp Melab

Awesome!

A great writeup of whats bothering me with "WYSIWYG" since years. And there are arguments against it that are even new to me.
To be honest, I'm feeling a little disappointed concerning the possible integration of inline wysiwyg in Drupal Core. To me its kind of a "marketing over sense" move, similiar to the the taller iPhone (which doesn't make sense to me too). Wordpress has it, and to beat Wordpress we have to make it even better, doesn't matter if it will cause problems.

I can see a benefit of inline wysiwyg for content that is strongly connected to the current design, like static info blocks or pages. But these parts of a website are often uniquely designed, and if a wysiwyg editor can be helpful in this case is questionable.
For any content that has to be portable in any direction (display modes, screen sizes, devices, different layouts ...), WYSIWYG encourages the user to focus on the current display and thereby break portability.

That said, we didn't use any WYSIWYG editor in our client project for years now. At first sight our customers are scared of Markdown, but if you give them a chance to learn, they are completely fine with it. And i think we will keep it that way.

Reply

Kieran Mathieson

Separating concerns in mental models

Jeff,

Great stuff. Thoughtful. Here is one more thought.

Humans are used to handling complexity in various parts of their lives. Suppose we developed a mental model that we wanted users to adopt, to think with, that lets them use the approaches to complexity that they already understand.

A metaphor: a Web page is like the main course in a good ala carte restaurant (what is called the entree in the US). Like this:

http://mathiesons.com/eaton-dinner/dinner.jpg

(Sorry, I could resist eaton-dinner.)

Drupal is a robot. It assembles the final meal, placing every item where it needs to be.

The plate is the underlying template that supports everything. It's a standardized thing that is used for all meals. It can be changed, but the change would have implications for the entire restaurant.

Each item on the plate comes from a different process. The garnish has little processing. Just drop it on. You don't need a master chef for that. A novice chef can cut the parsley, and give it to the robot.

Some items need more processing. Some need a lot. Fugu, for example, that poisonous fish thing. Before it can be prepared, one chef needs to cut it from the fish. Another inspects it. A third cooks or does whatever to it. Then it is ready to give to the robot.

Why is this metaphor useful? A meal is a complex tangle of work flows, people, expertise, ingredients, etc. A complex tangle that people are used to thinking about.

- Different parts of the meal (page) come from different places.

- Different people are responsible for different parts.

- The people have varying levels of expertise. Some tasks require more training than others.

- People use different tools, depending on the task they are doing.

- Some raw ingredients require much transformation before they get on the plate. Same with Web page data. You need to change the underlying ingredients first, if you want to change the meal.

Fugu prep is a complex organizational work flow, with approval from legal, marketing, etc. Mistakes have implications.

What about mobile? Suppose the restaurant caters events. In that case, meals are put on smaller plates, that are transported more easily. Sometimes items are left off, so everything can fit on the smaller plate. So the meal that is served in the restaurant might not look the same as the one served off-site.

You could explain Viewsy lists this way, too. A content list is a mixed plate of hors d'oeuvres. Each one is made separately, a little sample of something larger. The robot takes them from different piles to make the final mix.

You could extend an abstract version of this into the editing interface. Different page elements could have different affordances, depending on where the data came from, and who gets to edit it. There could be a helpish icon on each element, telling editors about the source of the data, and who to talk to to change it.

Another important entailment of the metaphor: nobody expects any human to be able to make a four-star meal without training. Further, a four-start meal at restaurant scale needs a production team, with a well-organized infrastructure.

Entailment: nobody should expect a human to work on a Web page without training. Furthermore, the human is like a junior chef, with limits on what s/he is allowed to do.

With this metaphor, the idea that you can just look at an interface and know what to do, is brought into question.

Last thought: the mental model and the editing interface are built together, to support each other.

Kieran

Reply

eaton

Interesting!

I hope I'm not taking the metaphor too far when I say that your post has a lot of good... food for thought. Ahem.

Last thought: the mental model and the editing interface are built together, to support each other.

I couldn't agree more. This is one of the reasons that building well-suited editing workflows in Drupal takes time, and why one-size-fits-all solutions are rarely satisfactory. The nature of Drupal's content and page modeling tools means that every reasonably complex site will have a different mental model of the content and the desired presentation!

The work of matching those two aspects to each other is critical for the long-term sustainability of a content-driven site, IMO.

Reply

Jeremy Epstein

Great arguments

Ahhh, WYSIWYG... in all my years building CMS-powered sites, it's always been the feature that I try to leave out, or that I at least try to limit in its funcionality; but that clients ultimately all-too-often insist is available, and that is turbo-charged beyond their actual abilities.

Seems that with WYSIWYG finally in core for Drupal 8, in the future clients will be entering this battlefield having already gained the upper hand.

Just today, I had an anecdote that reflects the problem this article is describing. On a recently-built Drupal site, the client had insisted that TinyMCE was enabled with full table-editing functionality. Now, they've discovered that various fields of the table data they've entered via WYSIWYG can be fetched and updated from another API source. So, the client asks: "can you make that table dynamic?" Well, sure - but the current table is just dumb text, so changing it to a separate element that's populated from elsewhere is gonna cost you more $$$. "But isn't the data already in?" asks the client. "I already made the table - look, you can see it here!"

The traditional problem with WYSIWYG editors is, of course, clients copying in giant text grabs from Word documents, and the resulting markup soup. But really, that's only the tip of the iceberg. Thanks for digging deeper into the perils of WYSIWYG, Lullabot!

Reply

Lukas

very good summary of the key challenges

I absolutely agree with your assessment. In general for simple use cases inline editing works really well for content creation and editing. As the workflows get more complex inline editing becomes less useful for content creation, but usually remains fairly useful for editing.

One thing which you touched upon, but that I feel should be spelled out even clearer: Inline editing is also not great if the content needs to be reused in a lot of different places with different requirements as the editor will be too prone to optimize for one use case at a time. Then again stuff like create.js makes it possible to introduce editing into all the use cases and with things like backbone.js (and a good content repository) it should be possible to simply make all different uses of the content visible in different tabs at once.

As for the topic of metadata. Here the concept in create.js is to use overlays to automatically make metadata fields available for the given context. But there it can get fuzzy too. F.e. a publish date might be showing as number of minutes since it was published. Not really the ideal format to allow editing. Especially if f.e. for just published things it might just saw "just now". In that sense the content is shown, but not really in a form where inline editing makes sense.

Reply

Boris Kraft

Everything should be made as simple as possible, but not simpler

very well done. We have looked into this topic for many years, and while inline editing seems cool when you see it, it actually isn't once you work on complex, often composite content.

The frustrating thing is while proponents claim "well you don't have to use it for all use cases" the reality is that the genie is out of the box and prospective clients want this because they saw the demo from vendor X and thought its great. Well it feels great. Now here I come and need to argue against something that is not rational but emotions, and I can only lose that argument. This means I end up implementing something that makes our user experience worse, because otherwise I lose sales.

That is what I dislike about it. It is not for the better. If you want inline editing, use word. What is so hard about that? The web is not a word document. As others pointed out, we work on multiple channels, in multiple contexts. Inline doesn't help here.

There are also interesting possibilities of failure not yet mentioned. For instance, of you have a web page, it has a title, a navigation title and a window title. These are three distinct properties - often they are the same, but often they are not. IF all I see and can change is the title, it will easily get out of sync with the nav title or window title.

Maybe a teaser somewhere uses the content title. What should a user be able to do? Change the teaser title? Then what? Or not change the teaser title, in which case she would be disappointed or confused (why can I change this part but not that part of my page?).

As Albert Einstein put it: "Everything should be made as simple as possible, but not simpler". I think inline editing fails that.

Having said that, it should work fairly well for long texts like a news item or article, a job description or blog post. Just again, there will be the areas where the abstraction leaks. I usually prefer a UI that is consistent and doesn't leave me guessing if, how and why I am allowed to perform an action or not. Even if it means a popup with fields opens. At least forms can be structured and prioritized.

Reply

Tor Løvskogen B...

Pessimists

I'm sorry to see that everybody chimes in with negativity around direct manipulation. This should be viewed as a challenge, an opportunity.

Yes, the status quo sucks, but that doesn't mean it must be like this forever. As a product designer, I don't like products that require someone to learn the underpinnings of a system to understand how it works, and how to use it.

Everyone that mentions their customers: why do you think they want direct manipulation? Because it's a great experience. It's sad to see people dimiss this with "Well, it can't be done for the use case you want, it just can't.".

Writing and editing content should be as easy as Word and Pages. Handeling the web structure should be visual and easy as well. Let's work towards this, instead of telling ourselves that separate web forms is a be-all end-all.

Reply