This is a message to the team currently working on CEUX, a project to improve the Content Editing User Experience in a future WordPress update.
I have been following their progress on make.wordpress.org, and I think that this has lots of potentional. The following comments are intended as a constructive critique.
In short: the CEUX project aims to improve the handling of content blocks inside the body of the post. That’s fine, but we should also consider the possibility of content blocks outside the body of the post.
Among the types of content blocks (images, audio, video, quotations, code, tables…), the type I am dealing with most frequently are galleries. I’m slightly biased, as I mostly build custom WordPress themes for designers, artists or art-related organizations, where image galleries are a substantial part of the site design. Broadly, they fall into the “portfolio websites” category.
Featured Galleries
A typical pattern for portfolio or magazine websites is that the article is accompanied by what I call a “featured gallery”. That gallery relates semantically to the post as a whole, not a particular paragraph. It’s similar in concept to the “featured image” that we have in WordPress, but with a series of images instead of just one.
Here are a couple of typical examples:
Sources: Qubik, LIFE Magazine, Quadrant Theme, Editions B42, James Bridle, Fast Company
In each of those cases, the gallery container is separated from the body of the post. It’s a separate content block – as are the title, or the metadata (tags, publishing date). In the present state, such a layout cannot be handled by the native gallery implementation of WordPress, which always places the gallery inside the body text.
Note: two of those websites are built with WordPress – would be interesting to know what method they use!
Embedded galleries
Another type of galleries are those contained (embedded) inside the body of the post. They mostly relate to a specific part of that post, rather than the post as a whole. I call that an “embedded gallery”. Some examples:
Sources: Craig Mod, Subcompact Publishing / Andrew Kim: America Elect.
This type of “embedded gallery” is fully supported by WordPress, since the new media manager was added to WP 3.5 (however those two websites run on Expression Engine and Squarespace respectively).
My purely subjective feeling is that the “featured gallery” pattern (a gallery that illustrates the post as a whole) is a very common use case – at least in the category of portfolio websites, it’s the rule. The “embedded gallery”, where the gallery has a precise place in the flow of writing, is useful for long-form articles, essays, cases studies. The handsomely crafted essays of Craig Mod are a perfect example. But looking at the real-life use of my real-life clients (which aren’t writers), it’s quite rarely needed.
So currently, the media manager offers full support for the edge-case of “embedded galleries”, but not for the generic “featured gallery” model.
Solutions
Of course, WordPress being so easy to extend, there are many workarounds. In my work, I have used two ways for handling “featured galleries” in WordPress themes:
1 – The most simple solution
Generate the gallery automatically by using all images attached to the post.
Pros:
- Relies only on built-in features. “Look Mom, no plugins!”
Drawbacks:
- Not very flexible (you can’t exclude images, or use images from another post).
- The workflow of uploading, and then simply closing the media modal is unintuitive. The user needs to press some action button (“Create gallery”, “Save gallery”…).
- There’s no visual indication in the backend that the gallery exists, unless you open the media modal.
2 – A better solution
The Advanced Custom Fields plugin, which has an excellent “Gallery” content block (a paid add-on).
Pros:
- Easy to implement in a custom theme.
- Perfect solution for the “featured gallery” use case, resolves all the workflow issues above.
Drawbacks:
- Website becomes dependent on a third-party plugin.
- Even if well designed, the UI doesn’t feel 100% native.
- If CEUX content blocks were to enter core, the ACF gallery would feel like a parallel workflow (unless the plugin author adapts the UI to the new content block standard).
So, what’s the issue?
It isn’t really an issue, since there are good working solutions already… Rather it’s an opportunity – the CEUX project could bring us an improved content editing experience that supports different common workflows.
Here’s some wild speculation:
The CEUX interface could be extended in order to allow additional “content areas”, activated and defined by the theme. This could happen the same way we can register areas for widgets (register_sidebars()) and menus (register_nav_menus()).
Even better: a custom content area could be pre-filled with one of the available Content Blocks (image, gallery…). And the theme could decide if that area is open to further editing (adding more content blocks), or if it’s locked.
Yes, I should draw some mockups for that…
Other voices
Jen Mylo (UX designer at Automattic) has also asked for a bigger look at content blocks:
has there been any talk about real content blocks that can go other places in theme so it’s not dozens of text widgets and plugins as a workaround to achieve a similar end? Would it make sense to think bigger instead of smaller and look at content blocks as all content on the site, not just within a single post?
Azizur Rahman has voiced it this way:
I am interest[ed] in seeing how the actual data will be architect-ed. Would we have all the block somehow composed into a single field (ie: post_content) or would the block themselves be stored such a way that it can be re-used and re-purposed for a different presentation?
So, what do you think?
Please post your comments in the CEUX discussion thread over here.