(Hint: If you don’t care to read too much, there are some screenshots of TYPO3 Neos UI sketches at the bottom of this post)
Here it goes, my long’ish initial conclusions about the WYSIWYG inline, in-page, in-place editing debate. Lengthy as it is, it’s actually an extremely compact, short version of what I’ve been thinking, dreaming, planning and discussing for a couple of months. Consider it a very small book.
To achieve reusable content in a multi-channel world, the seperation of authoring and presentation has its own problems as the path from editing to preview can easily get too long.
It’s abstract as hell but instead of decoupling authoring from presentation entirely, we need to help users to better grasp how content can be edited & previewed in multiple ways. I think there might just be an interface for that.
But before I get into all that, let me first use this image of personalized content variants to show that yes, indeed, TYPO3 Neos will work for both the content strategist community and marketing-driven enterprises:
WYSIWTF, the article that made me sleep less in the summer of 2013
I think, virtually no one active in the world of developing content management software failed to recognise and read McGrane’s WYSIWTF in may on A List Apart - or before that, Jeff Eaton’s Inline Editing and the Cost of Leaky Abstractions. Alongside the interesting comment dialogue between Dries Buytaert and Karen McGrane after her Drupalcon keynote, this issue has spawned many articles debating the good and bad of inline editing. Alongside the Spark project going into Drupal 8; Adobe, Sitecore, Magnolia, CoreMedia, Oracle and pretty much every other CMS vendor I’m following is working rather intensively on what to do with multi-channel and preview capabilities - alongside the crazy-many other tasks we try to solve in one software package. I think a lot of innovation is happening right now in this area.
For the Neos UX efforts, I talked this over in some detail with Leisa Reichelt in London a couple of months ago. One of our topics was whether we should just drop inline WYSIWYG editing all-together in TYPO3 Neos - a rather troubling idea for anyone who’s invested a gazillion hours into getting that thing to work properly.
Inline and Inline are not the same
This debate about inline WYSIWYG editing is greatly troubled by the lack of clear definitions.
As Eaton nicely writes, there are different types of inline editing that are not the same thing - and there are combinations of them, to make matters even more confusing. I personally feel that the different definitions we have today are very hard to explain to clients (and I do think I’m probably just too stupid - feel free to admit it, too) - so I’ll step a bit away from that whole line of thinking about inline distinctions and propose a different path - at least just for the CMS product, I’m personally working on. As I’m a UX’er, I tend to try to solve things with UI’s…
Inline editing in the backend is a good thing
Right now, I’m writing this post in a tumblr editor. It’s about the worst possible editing experience you can imagine. I need to go back and forth between the rich-text editor and the frontend preview of my post. It’s not just making the authoring experience less pleasant - it very directly kills my writing as I continuously get out of context.
So… I think much of the criticism in the content strategy community against inline editing has been based on the premise that inline editing is synonomous only with WYSIWYG editing, manipulating content directly in the frontend template. This has led to quite some disorientation as inline editing refers to such a bunch of different variations. That debate has been going on for ages by the way.
Inline editing is about changing what’s in your database without the annoying abstracted in-between steps. It doesn’t neccesarily mean it needs to be abstraction-free - and it doesn’t at all need to force away important metadata inputting while editors work in what looks like the frontend - as seen by the end-user.
Editing something can - and should be - done in different ways for different purposes - a few examples being:
- Inline edit in “template-less” views (like the wireframe mode in Neos)
- Edit in specialized backend templates set up to support multi-channel delivery (e.g. editors enabling users to tag different parts of the same piece of text to be published differently in different media types)
- Edit content variants (personalized or A/B) in the same view but without the surrounding context of the place content is residing
- WYSIWYG inline edit on the actual page (for small corrections of teasers or for all the scenarios where multi-channel, reuse of content doesn’t matter
As all of these take place behind the CMS login, they are all naturally part of a backend experience for the editors. Which leads to the simple conclusion that inline editing is just fine for backend usage - whereas WYSIWYG inline editing of one single frontend template should in many cases be avoided for all the many many scenarios where you don’t know where your content will show up in the future and don’t want content to be styled or finetuned to a particular context.
Clients will smile first, cry later
To repeat the general, unchanged problem: If every CMS on the planet starts doing WYSIWYG inline editing - without the metadata inputting - and let editors edit directly in particular frontend templates, then we’ll teach all our users to think in a potentially problematic way because controlling content in one specific context clashes with the rise of multi-channel delivery of reusable content.
We just don’t want editors to correct and finetune their content to match what they are looking at - in a specific browser - showing a specific template - at a specific screen width etc.
Recently, I collected a bunch of quotes for a 2017 WCM Forecast that we’re using for roadmapping the Neos CMS. There, Karen McGrane said that for organizations to “support true multi-channel publishing. They will need to invest in new systems to decouple the authoring and storage layer from the presentation and publishing layer.”
What that means is that WYSIWYG inline editing of a single frontend template view is about the dumbest thing you can do in a CMS - if you want your editors to think about their content being reusable in many different both known and unknown channels.
Yet, all that doesn’t really change the fact that giving editors a super simple way of typing text is plain great. And inline editing does that. Even more, for the many scenarios of CMSes just handling content for one channel in one template, WYSIWYG inline editing is nice.
Current state of Neos UX planning
For Neos, we currently plan and test a different approach. Instead of being stuck in the word game of trying to specify and define the different approaches to inline editing - or to completely seperate content authoring from presentation, we’d like to build a tool that lets you set up editor workflows in different ways. I thought about the possiblity of just dropping every single kind of content authoring in Neos, let that take place in one of the specialized software packages doing only content - and let Neos be the place to assemble, moderate and publish. But if you go down that road, many new problems arise. And the path from authoring to getting a feel for how it’ll look like in different contexts is broken - which is simply unacceptable to editors trying to crawl inside the minds of their readers to compose relevant content.
So what about previewing?
Newsflash! Preview is not only about devices!
Device simulation has been a major thing for a lot of CMS vendors the past years. It looks as if the new standard is a device preview menu that lets the user choose what kind of device simulation to preview the content in. Many of them even sport previews with photo frames of tablets and phones.
Yet, previewing is so much more.
In the Neos CMS (and I think every CMS must), we’re planning for a lot of different preview capabilities:
- Same content in different templates
- Same content on different websites
- Same content on entirely different channels
- Search apperances
- Social media representations
- Personalized content
- A/B testing variants
- Different workflow previews
- …and yes, devices & responsive widths
Digging into this complex preview issue we’d (presently at least, while testing and iterating) prefer a unified UI for previewing in many different ways - and I want it close to the authoring experience. We want our users to just learn one overarching way of handling editing and previewing.
Depending on how it’s set up on installation basis, it can be ultra simple and almost abstraction-free - if that fits your project and user roles. And it can be set up in more abstract ways for editors to start getting the feel for what it’s like to edit and preview for multiple channels - and start thinking about how content can live beyond what they can imagine.
A UI framework resting on top an application framework
As all of these preview functionalities would overwhelm even the brainiest of geeks, we need a generic UI that works as a UI framework for implementers to costumize on a project basis.
We could have chosen to work on a UI that would be entirely spot-on for multi-channel and leave in-page WYSIWYG editing behind - but we’d rather work our way up from the coding framework - to a UI framework - and then enable people to work on top of that, tailoring the interface to be optimal for their particular scenarios. I guess I just played with too much LEGO as a kid.
Combining Edit and Preview
The length of this post is partly due to the fact that I want to combine the editing and preview interface for editors in a somewhat different way. Sometimes software split the two completely - other systems combine them too closely. What all that means is slightly complicated to explain - but it’s easy to use it as a product UI.
Also, I would hate if we ended up doing yet another CMS with too great a focus on WYSIWYG inline editing that could cripple organizations ability to reuse their content properly in the future because their content will end up tailored to one specific, short-lived context. So, what if we set the split a bit differently?
This is just one of my first drafts of a UI combining editable templates with one-click access to presets of preview rendering:
After you’ve selected a content chunk via the Navigate node trees in Neos, you can turn on a view menu. On the left, you have all your editable modes. The default would just be the Frontend WYSIWYG inline editing and the Wireframe mode that strips away all styling and let’s you focus on semantically enriched content. In another part of the UI, there’s our inspector giving you metadata fields regardless of your Edit mode selection. If you like, you just turn off Frontend - thereby letting your editors work in something that looks more like the iA Writer.
In this next variant, the implementer has made the wise decision of making a specialized backend preview template for Google Glass, thereby enabling the editor to view content as Glass would show it. In the Google Glass template, nothing is editable - it’s just a preview based on the content edited in the Edit mode section:
In perhaps slightly more realistic cases, you could have different preview templates for different channels - which would make your editor able to extremely quickly see how content will appear in different channels. And then just one click away from correcting content in what-ever Edit mode. If a comma is edited in one mode, it naturally must change in all other modes.
The workflow could be something like this for an editor:
- Choose content chunk in node tree
- Select Wireframe mode
- Type away an article draft without thinking about where it’s presented
- Click on Mobile preview to see how that would look like in the preset frontend template showing the mobile view
- Back to Frontend Edit mode to see and edit the content in the default frontend template (whatever that is)
- Check how the content would look like in the workspace that my boss is working on (he’s fiddling with some template changes with some lame designer so I’d rather check if my content would also work in that context before getting too far)
- Back to wireframe mode to finish the base article
- Add metadata in the inspector on the right
- Click Google Search preview to see the frontend simulation of how a search result in Google would appear
- Iterate endlessly on SEO metadata
- Change headline in wireframe mode
- Click large orange button to send chunk to next step in workflow
See how this would faciliate playing around between editing and previewing, letting both sides of view modes improve the authoring? While previewing in many different contexts can obviously only show the known channels at the authoring time, the stripped, template-less wireframe mode helps editors to focus on content outside of context.
Case of the content strategist-focus on reusable content:
There your focus is on semantically enriched, template-less content. Frontend in-page editing could be switched off entirely - and preview templates could spawn to all relevant renderings of the known channels content will go into.
Or what about the case of personalized content variants?:
Here, the view is not an entire page but just one single part of a template in differentiated versions. The editor could be enabled to make any kind of personalized header image for different target groups based on data from social media, site history, language, CRM, login preferences and so on. The editing view is direct manipulation of styled text on image - from the frontend template - but can be reused without styling.
Or what about printing from Neos to the Berg Little Printer?:
Left to my own devices
These are just first drafts of the Neos interface for handling all of this - some of it way beyond what will be done for 1.0 (and surely, expanding the interface to include 107 editable languages will need a bit more work) - but I do feel it’s important to not limit preview to be about widths and devices - and to explore ways to implicitly teach editors how to feel at ease with authoring for multiple channels at the same time.
Next step here, will be to engage the Neos client follow-group to get more real-world costumer feedback to make sure we’re fullfilling real demands across the many, very different clients using TYPO3 content management products.
Feel very free to send me a mail at rasmus[at]typo3.org if you feel the urge to co-ramble about this subject or want to help build great UI’s for an open source, community-run CMS.Comments powered by Disqus