I’d disagree. I feel like this kind of format could easily be applied for different models. To me it just gives it a standard format. Their will always be exceptions, but I feel like this is a great direction to go for consistency.

Avryl
8:47 pm on August 8, 2013

What would be an alternative to a document model? What would the current model be, if not a document model?

Document model works okay for posts, which are essentially documents, but as we branch out into pages and custom post types, we need to think a little broader. For example, services likes Squarespace and Weebly do a really great job at page building. We want to build, not just write.

I’d imagine it as a post type “supports” feature. Added to posts and perhaps pages by default, with the ability to register support for whatever this is named in the registration of the post type. Otherwise leaving it to a standard content area.

Avryl
8:35 pm on August 8, 2013

I’d really like to help out with this, but I’m new to contributing to WordPress and don’t really know where to start.
Your concepts are great! They’re simple and intuitive. Will there still be a way to edit in html (and even maybe in markdown)?
Also, with content blocks, is it the intention to have more than one post format for a post? Or is that something separate/obsolete?

Please do not remove the html view. There are a lot of users (including me) who prefer using that when writing. One of the first things I do when setting up a new WordPress install is to turn off the visual editor.

For writing code in posts (tutorials) the text editor is a must. Now I can see defaulting to visual and maybe hiding text, since I suspect we’re more rare than the people who live in the visual, but it really needs to stay 🙂

Is there any reason the html view could not be ported to a plugin? Decisions vs options imo. If the visual editor was *really* good, we should not give equal weight to the html view. If nothing else, it should be less obvious an option. Perhaps off by default in screen options, maybe, if not a plugin.

For the majority of writers, the HTML view is a crutch for a visual editor that isn’t *quite* perfect. Right?

Consider how often you have to flip into the text view to clean-up your markup, or delete something that isn’t easy to delete in the visual editor. Or write code.

Sure, some folks prefer the HTML editor for whatever reason, but it’s existence — as a crutch— is not helping us make publishing easier.

There are a few problems that should be solved before we can hide this crutch:

Janky markup. The visual editor needs to produce markup of the gods.

Code editing. There are lots of code bloggers—at least as many as photo, video, or audio bloggers. Let’s introduce a good way to write code examples into the visual editor

Formatting weirdness. Part of this is due to the visual editor not always accurately showing what the front-end will look like (which I realize is editor-styles.css), part of it is due to it’s relatively small size.

For those that really just want to write in HTML (or markdown?) — perhaps we can repurpose some of that awesome code editor mentioned above for writing actual post content. There already exists an option in user preferences for the default editing environment. That can be repurposed as a toggle.

Mel and I mocked up two directions on improving the post editor experience. In my mockups, I worked on the assumption that post formats wasn’t a thing at all — that there were only content blocks that contained semantic structure for its type of content. For theme compatibility, you’d be able to assign a post format class based on what content blocks were there: if there was only one video block, it would be a video post format.

Two things I think would be really helpful: easy to establish “section” and “column” options. This would allow for pretty simple content section establishment. Could be plugin territory, but I think if we’re going to content blocks, core could much better handle such features than a plugin.

Sorry, I should’ve also noted: I basically envision these as classes that WordPress expects. Much like alignright and alignleft. Options like “content-section, content-column-group, content-column,” etc.

I like this a whole lot. I was going to sketch up some ideas of my own, but you’ve included many of the things i wanted to illustrate in your mockups. I especially like the sidebar content blocks and that the publish and category options are at the bottom, where they would most logically be used.

It definitely makes a lot of sense for block behavior to adopt such classes. Perhaps they even behave differently based on what the theme is capable of. If a theme doesn’t have an alignleft class, for example, such an alignment isn’t possible.

Your mockups are really good! To take it one step further I would suggest to add a semi transparent grid (improved table) to the layout area. Drag and drop an element into the grid. Click the element to add background color, curved corners, border, padding, margins etc. Select multiple cells and add a background color etc to the cells then drag an element into it, or just add some text to create a background color box. Here are my mockups: http://easywebdesigntutorials.com/wordpress/wordpress-mockups/
The grid will make it possible to push/pull the cells to make them bigger or smaller. Adding just a design to a cell(s) and/or the element. I also suggest to add templates into this mix. Design a page and save it as a template. Make a new page and select the custom template and see how the design of the page changes to reflect which template is selected. Also widgets should be dragged&dropped anywhere on the page.

To me post formats are really about applying differential layout in the blog-roll (and sometimes on the post itself) based on the content type. Making the edit surface easier to navigate – trimming down the options to avoid choice overload – seems like a secondary goal.

If you can make all the editing easier then that secondary goal is less important and you’re left with, “How do I tell WP to layout “Quote Format” posts in the blogroll differently from “Picture Format” posts?Why not make the layout automagical. If you have a post where 75% of the text is an inserted block quote, then that becomes a “Quote Format” for the purpose of layout. If you have a post that is 80% a gallery, then clearly that’s a “Gallery Format”.

Essentially I’m saying why bother asking the user to explicitly define posts as a being a particular format? They’ve already done that in their choice of what they put in the edit surface.

There will definitely be edge cases so you might want some ‘Advanced User Explicit Defining Format’ option, but my sense is that it won’t be that common.

As someone who currently does not use Post Formats on a regular basis, I would find it frustratingly annoying to have WordPress automatically applying post formats to posts. I structure posts in the way in which I want them to be displayed and if WordPress is going to get in my way to try and help me without me requesting it, it’s going to be a bad day. I am the edge case that explicitly wants to choose a post format based on when I want the content to take on the looks of that format.

Personally I ONLY use the html tab so I really want that kept – however I really like the look of this style of interface. What I would suggest is disabling html and having it enabled through the user profile (like the colour schemes) so that power users can toggle it on and regular users can ignore it.

Really like the idea. I’ve thought before that allowing the user to define ‘blocks’ of content within one page/post/etc would allow flexibility in defining what goes where. Start with text block, followed by an image, followed by more text… Advanced Custom Fields has given me some inspiration and capability on that front.

So, in sort of the same way unit tests should be written in parallel to a PHP (or soon, JS) patch, I think user testing scripts should be written in parallel to initial ideas. What exactly makes this hard now, both from an editing perspective and from a theme-making perspective?

During my happiness rotation and a lot of work with clients, I’ve seen a lot of folks that hunt and hunt, trying to find the publish button. Sometimes they don’t see it when its right in front of their face, other times they’ve inadvertently hidden it by moving the Publish meta box around the page.

My assertion is that, just like the editor, the publish button should be big, friendly, and consistently in one place.

I’ve also seen a ton of users struggle with finding the publish button – and even with finding it again after multiple exposures. OTOH, I’m not convinced that split buttons are usable or understandable for that same group of users.

I like the concept of content blocks. For some ideas you can look at this amazing group of plugins : http://www.advancedcustomfields.com
I always replace the traditional “content” by a “flexible field” where the user can add simple column, double colums, maps, accordions, carousel… it’s simple to understand than shortcodes.

Advanced Custom Fields is brilliant, I can’t remember the last time I built a site without ACF installed. We’ve implemented our own Content Blocks feature based on ACF & flexible fields which we re-use quite often. Here’s a screenshot of how we do it: http://cl.ly/image/0d1a1Y1L2J3f

I can imagine endless possibilities for this as part of WordPress core.

Seems to me that it could be possible to make this ‘block’ capability built in, where WordPress understand what each block represents, then can just render them in sequence. Yes theming work would be needed, but some core capability would be a good start!

I really like the concept of content blocks as well, especially in-line. I think this would also create a standard also for other things to be implemented either through core or plugins…for example Columns.

How can we make formatting easier and faster to use? – Maybe use “Markdown” with visual result by the side, like http://pad.haroopress.com/
How can we make it easier for users to include different types of media, such as audio, video, images and galleries? – I thought about the drag and drop working without clicking on any button.
How can we make it easier for users to embed external content, like tweets or maps? – Accepting pasting the embed code directly in the editor without having to switch to code/text

@Mel Choyce, your layout ideas are looking good! I would definitely stick to the first option though (http://melchoyce.com/wpadmin-ui/img/add-new.png), separating text from the inserting options cleared up a lot, plus the publish button and options solve a lot of issues.

Page Builder – http://siteorigin.com/page-builder/ – uses widgets in its drag/drop interface to very good result…Not sure if that is larger in scope than what most think of as content block, but if bringing that type of interaction / content design into core is a part of this feature…I’m quite on board for beta testing as a part of this team.

Avryl
8:51 pm on August 8, 2013

I agree, markdown shouldn’t be default, but it’d be great to have a markdown mode.
Btw, that’s exactly what Ghost is doing.

I suggested on Twitter after Matt’s SOTW that I think WP needs an open registry to collaborate on data structures and identifiers for post formats, such as maps. As I understand it, the reason post formats were closed was in order to ensure that the themes would have a fixed set of formats that they would have to account for, and that data structure for the media in the post format would (supposedly) follow a convention so that themes would know how to parse it.

However, the closed set of post formats was something that we always hit up against, and would often find ourselves wanting to register new post formats (like polls or maps). We would then resort to creating a new Media Type taxonomy which would automatically assign the corresponding post format if there was one, but this allowed us to create as many media types as we needed, and it also allowed us to associate a post with *multiple* media types (like a post that features an image, music video, and a separate audio track). This now makes much more sense, however, when paired with the newly-proposed content blocks, and that a post can have multiple content blocks each of which as a media type.

In order to allow new media types (post formats) to be registered, it seems there needs to be an open registry in which the community can collaborate on the identifiers for these media types (e.g. “map” or “vcard”) and also the data structure which this media type must follow (e.g. [map]45.523452, -122.676207[/map]); it seems shortcodes would be useful to specify in the data format, as themes could then easily override any default handlers for the formats. The WordPress media type registry could also refer to plugins which implement support for the media type in themes, and also themes that support the media type natively. Likewise, there should be a way for themes (e.g. via readme.txt) to declare which media types they support, so that they can be filtered when searching.

Love this direction Mel. I’ve been playing with Squarespace in the last while and these content blocks are fantastic. Having columns, spaces and horizontal rules (as SP calls them) makes for very quick and intuitive development. It feels like a massive task though!

I think the important thing for content blocks is that it needs to be easy to plug in to and create new ones, and also easy to retrieve that data in the front end templates. That’s what makes Advanced Custom Fields so brilliant from a developer perspective.

Definitely. Defining a managable set of blocks/types to start with, with a mind to expanding them in future releases help move this forward.

tomdryan
9:27 pm on August 8, 2013

Here are some thoughts on the Posts user interface as you re-envision the posts page:

1. All of the file operations (publish, save, preview trash) should be in roughly the same place on the screen and in a similar style (for example, they should all be buttons, but Publish could still be colored for emphasis).

2. The file buttons could “light up” once the user starts to edit a post.

3. When a post title is edited, there should be an easy way to update the Permalink without manually editing it. It should probably happen automatically if the post is still in draft mode.

4. There should be a button to revert the current edits, which deletes the current draft (the way it is now is REALLY confusing to casual users).

5. It seems that the post Status and Visibility controls could be combined.

6. Since Posts is where the least technical users will interact with WP, I would put some more interactive help access (hover for help).

7. For consistency, I would rename the first admin menu choice to “Manage Posts” instead of “All Posts”.

8. One thought on editing would be to have a text mode with or without tags. This is how WordPerfect used to do it back in the day. They had a visual mode and a draft mode where you could show or hide formatting tags. It made for a very clean, “heads down” content creation mode where you didn’t need to worry about formatting or tags.. Might be worth consideration.

Avryl
9:49 pm on August 8, 2013

2. What do you mean by file buttons?

3. That already happens after saving or publishing a post (but it would be nice to see it change before that).

I like the content blocks concept a lot, though I think some sort of drag and drop action would be more intuitive than the “add block” appearing when your cursor rests. That kind of continual suggestion is likely to get annoying very quickly. Give the users the tools they need in a logical, but out of the way place and let them decide when to use them rather than have the UI constantly ask them to.

I think your concept as a whole is several steps in the right direction. I’d like to see a more streamlined, page-first experience with all the menu and toolbar distractions isolated to one area. As it stands, having these tools at top, right, and below keeps the UI feeling more cluttered than it ought to.

I’d love to pitch in on this project and am glad to help in whatever way I can.

I think the big problem here is targeting the perpetual intermediate user. Beginners want things in their face so they don’t have to hunt for them. Experts want things out of the way so they only exist when they need them. We want to aim for the intermediate user — is comfortable enough to get what they need done, but still needs occasional reminders for where things are.

I’d like to see a more streamlined, page-first experience with all the menu and toolbar distractions isolated to one area.

Another consideration is small devices, that makes drag and drop problematic.

I think a better implementation would be drag and drop or click to add block. The “action text” should be obvious whether the user is hovering or not. I can’t link the direct post bc I can’t find it, but it’s an accessibility concern.

I don’t see why click or click+drag couldn’t both work. That way, on mobile, available content blocks could be available, perhaps toggled, at the top, and a touch/click could send it to the editor. On larger devices, drag and drop would be simpler.

Also worth noting, making content blocks collabsable once in the editor could be very nice. Similar to the way gravity forms fields work once in the form editor. In fact, we may be able to learn a bit from the GF UI in general for a project like this. The goals are similar (not that I think GF is a perfect UI at all).

Not sure what content blocks means here, so maybe this is already something you’re talking about?

I tend to write long posts with a lot of media – it would be really sweet to have the mark-up and media tools float along the side for easy use OR stay fixed and let the content scroll underneath (the way freeze frame works on Excel).

Where I work, in the last year we’ve built over 500 sites for clients on WordPress. The vast majority of these are for non-technical users running small businesses using WordPress as a CMS.

One of the biggest issues by far is TinyMCE, for these reasons:

It’s not WYSIWYG, at least not in any way that clients understand.

Doing anything other than a vertical block of text with some images is incredibly difficult. Tables, through a plugin, are very difficult to use and very very buggy (#20943 has driven more than a few clients mad).

Alternatives like Column Shortcode plugins are too abstract and confusing for most of our users.

Adding anything other than a standard gallery/image is difficult. It involves either using a shortcode or going to the HTML editor and adding code, which often breaks things when switching back.

I would like to see something where it’s easy to add rows and columns and then just drag a piece of content into it, like and image, gallery etc. as in the mockups, as well as just a simple HTML block when a user needs to embed something that isn’t available.

It should also be easy for plugin developers to make their own content blocks as a replacement for/representation of shortcodes.

I’m sure it would be incredibly difficult, but even with changes like this, a lot of our users will still struggle with anything short of front-end WYSIWYG editing, and I think that should be a goal for a future version.

I agree with the issues that users are having. wysiwyg is really not wysiwyg.. which is why I think a front end editing experience will be neat. but I think on first iteration, it might not be as robust in in content block creation as what is being discussed here.

I too have seen years of awful content created with WYSIWYG editors on a variety of platforms. The WYSIWYG editor creates a level of comfort and familiarity because most people are familiar with basic desktop publishing and word processing. But that type of content formatting is not suitable or desirable on the web. Especially with RWD, web content should be fluid, hierarchical, and relatively uniform.

In my experience dealing with clients, they feel intimidated by TinyMCE–It looks like a lot of work and makes “blogging” seem difficult. They feel that they are supposed to make every page “look pretty.” But those same people have no problem updating Facebook with relevant and even long-form content, and do it with ease. The struggle with the WordPress editor is to maintain a robustness of function while still feeling effortless and simple like Facebook, Tumblr, and the type of content editors people actually use quite regularly.

In this effort toward approachability, I’d love to see the WYSIWYG concept go away.

May I please suggest we turn this question around. Most of what I’m seeing here, and my apologies I have not read every word. We are back debating which keyboard makes you a better writer. Which always ends in disappointment.

How do people create content? If you look to writers, there are droves of people running away from MS Word and moving to tools like Scrivner. Which means they are more interested in crafting their words in a comfortable space and less about rows of buttons. I personally want an interface that lets me write in HTML, or Markdown or text and then lets me format it. With most WordPress sites using a dedicated theme with CSS that already defines the actual look of the formatted type, having lots of ways to ruin the design is not really a great solution. Media needs to be easy. Take a look at Koken http://koken.me/ to see a way of handling media. Not necessarily the right way, but a great model to think about.

If the interface is effective then there won’t be a front or back end it should just be content creation. Get out of modal thinking.

While we’re at it, why don’t we simply treat text as a content blocks as well? It’s text, so it would work a little bit differently, but it’s a content block just the same. I propose these simple rules:

One line-break creates two separate paragraphs but maintains the content block.

Double line-break separates the two paragraphs into two separate content blocks.

I think this would be an efficient way to deal with columns. If text is considered a content block, drag&drop columns would be easy. Imagine I’ve written two paragraphs of text, and then I drag an image block in to the right of it. By default the editor would recognize this as me wanting to create a 2 column layout, like so:

While I think a lot of these ideas are nice, it strikes me that the simplest thing to do would be to unify all the editing into a single tool bar/ribbon. For people coming from just about any commonly used word processor, they’re used to all the functions being in one place above the edit surface. Insert a picture? That’s in the tool bar right next to bold, insert link, etc. etc.

As it stands with WP, the toolbar does most of the work, then there are a few “privileged” functions like Add Media that sit above the tool bar. Things like Comments and social media (depending on plugin) tend to be check-boxes that sit in another box below the edit surface. Plugins that do things like forms are all over the map in terms of UI.

The way I’d like to see it is:
1) A single edit surface with everything that will appear on the post or page (Including comments, social media and other things that are set as the default in the theme).
2) Ability to delete/modify any of those things inline. So turning off comments would be clicking the red circle with the line through it just like deleting media).
3) All functions for inserting something into the edit surface together in one tool bar at the top.

One more suggestion. One source of confusion that a lot of my users have is that they don’t fundamentally understand that the layout of what they’re typing in changes based on the viewers screen/device. Any way that you can make that more obvious would be hugely useful.

One way you could do that is instead of one preview, have previews that are keyed to specific breakpoints in the responsive theme. So: View on 27″ monitor, View on 13″ laptop, View on iPad, View on iPhone.

Alternatively, give the Preview page a horizontal scroll bar at the top that lets the user scrub back and forth through various sizes and devices to see what it does to the layout. I’m thinking that the left side of the layout is big monitors and as you move right if becomes smaller laptop screens. Get even further and there are detentes for various common mobile devices.

Has anyone considered doing something like the theme customiser screen – where the WordPress nav is on the left – and the theme (website) is on the right, and then the post editor looks exactly like the website – so that you edit the theme in place, with styles and whatnot intact?

Avryl
1:46 pm on August 12, 2013

I’ve done it with a few websites, but font-end editing and post creation would be a lot more challenging to be compatible with all the themes. It could be opt-in for themes to add support, but there will still be a need to keep to back-end editor.

The mockups look great, but I had to comment on the formatting toolbar. Highlighting to reveal a set of essential buttons is not obvious. I’m all fine for that when on mobile where space is precious, but if my monitor can support the space I say keep that out in the open. It just sounds like a usability nightmare.

I like the ambitiousness of the new layouts and they’re certainly a lot less cluttered than the current editor, which is as a result of years of things being tacked on. An overhaul is needed, but what would be really nice would be if an API could allow for adding boxes and functionality to the post editor in a structured and uniform way (such as tapping into the “add content, layout and social” boxes that appear in your first mockup). The biggest benefit to this in my opinion, aside from a more structured and predictable post editor is the ability to transpose those same editor boxes and fields into the mobile apps. The mobile apps are good, but I can’t add SEO metadata using WordPress SEO for example, without visiting the site admin. But if plugins tapped into this API, the mobile apps could include these fields in the post editor to make the mobile apps more usable, which given Matt’s emphasis on mobile moving forward should be an important consideration.

As a non-technical person I can’t speak to how we would accomplish this, but something like that would be a goal with this project. It should be easy for plugin and theme authors to tap into the content block system to add their own blocks.

doughamlin
8:03 pm on August 15, 2013

Agreed. Something along the lines of register_content_block() is absolutely essential.

As an example, let’s say there is an FAQ page and I want my non-technical client to easily be able to add questions in a consistently formatted way. I could simply register and Question/Answer content block and my client would be able to add a new block, drag to reorder, etc.

I think the ability to line up blocks in columns would be huge. At the moment we have clients using Tables or Column Shortcodes, and both are a nightmare.

doughamlin
6:25 pm on August 16, 2013

And Matt, I love that you mentioned Storify’s interface in the State of the Word. I think that is a fantastic model, and a few months back I sketched out something for a plug-in based on their interface. I never started coding though because I realized what a big undertaking it would be. So happy it will (hopefully) make it into core before year’s end.

I think this (http://moc.co/sandbox/post-formats/) mockup is the best of all. The text formatting thing should be present all the time because new users might not find it. Keeping it on top of the text will do. Also keeping the blocks in the sidebar is just awesome. I would suggest keeping a embed box in there because I have seen users struggling to embed youtube/vimeo videos. But again if video and audio stuff(rdio and spotify) things were available in the video and audio boxes respectively than there was no need to add another box. Some themes add new items to the editor like columns and such, so I think keeping it all in the sidebar is the best decision.

I really like this concept (and Mel’s too)! Content blocks is a great idea, and this kind of concept reminds me a little of Behance’s project editing workflow, which I like very much.

I saw too one concept here, by Erlend Sogge Heggen, that kind of answer to me two questions that I have:

1) Sometimes whe want to insert custom fields in a post type that are not directly related to the layout or the content displayed (for example, via the_content() function), so where we would put these fields? The Erlend’ concept uses tabs to separate some sor of “content types”. I think that it is a good idea to use this to make a “custom fields tab”.

2) This kind of editing workflow (and so Behance’s) is really good when we work with linear content (without columns), but what we do when we need them? Again, Erlend’s concept brings a suggestion to insert a “column” content block to deal with it, and I think it’s a good idea. My only concern here how we could deal with the formatting options in this kind of situation. Also, I link the workflow of SiteOrigin’s Page Builder plugin to deal with columns (https://wordpress.org/plugins/siteorigin-panels/).

Anyway, this discussion is awesome and I hope to see content blocks really soon in the next releases of WordPress! 🙂