The MP6 team has been working on recommendations for plugin authors who add a top-level icon to the dashboard’s main menu. We’ve investigated a number of options, all of which have their own advantages and disadvantages. In this post, I’d like to share the options we’ve considered in the hopes of generating a larger discussion about what would be the best possible solution for WordPress and for plugin authors. An example of the two SVG methods is available at http://codepen.io/joen/pen/otdkK.
Method A: CSS-colored SVG icon
This method uses SVG (vector, infinitely scaleable) icons that are embedded inline in the HTML. Using this method, the icon is able to inherit the color of the admin and change depending on customizations chosen by the user (a high-contrast admin theme for vision-impaired users, for example).
Pros
- Clean, retina, and infinitely zoomable.
- Only a single icon file needs to be created, no need for 2x versions or separate hover/active states.
- With colors being controlled by the admin CSS, they will always match the core set of icons, as well as any further customizations made by the user.
Cons
- SVGs won’t render in IE8 and below. A number of possible solutions are discussed below.
- For the CSS coloring to work, the SVG markup has to be cleaned up either manually or via an optimizer, adding some overhead to the creation.
- The actual SVG markup has to be inline in the HTML. Hard to cache, requires core changes, potential security concerns.
Method B: CSS background-image SVG icon
This method also uses SVG icons for infinite scalability, but is applied via the CSS background-image property. Using this method, colors must be selected by the plugin author, and a separate file must be created for each color.
Pros
- Clean, retina, and infinitely zoomable.
- No security concerns (that we are aware of) with SVGs when used as background images.
- No WordPress core changes are necessary.
- SVG files can be used directly from Illustrator, no editing of the SVG necessary.
Cons
- SVGs won’t render in IE8 and below. A number of possible solutions are discussed below.
- Multiple files must be created for normal, hover, and active states.
- With colors being controlled by the plugin author, they won’t match any customizations the user has made (a high-contrast admin theme for vision-impaired users, for example). Plugin authors must be mindful to use the colors recommended in the MP6 style guide (and creative plugin authors could use any colors, gradients, or styles they want).
Method C: PNG icons (the “no-build option”)
Alternatively, plugin authors could specify new MP6-style icons in the PNG format, using the same technique they use currently.
Pros
- Universal browser support.
- No WordPress core changes are necessary.
- No security concerns with PNG.
Cons
- Multiple files must be created for normal, hover, and active states.
- Two sets of icons must be created in both 1x and 2x versions for retina displays (and more, when higher-than-2x displays appear).
- With colors being controlled by the plugin author, they won’t match any customizations the user has made (a high-contrast admin theme for vision-impaired users, for example). Plugin authors must be mindful to use the colors recommended in the MP6 style guide (and creative plugin authors could use any colors, gradients, or styles they want).
SVG Browser Support
Internet Explorer 8 and below have no native support for SVG files. Icons in the SVG format will not display in IE8 and below as a result.
- Modernizr’s .no-svg class could be used to specify PNG fallbacks.
- A number of polyfills attempt to add SVG support to these browsers (we haven’t tried them).
- We could adopt a Google Apps-style browser support policy for MP6, supporting the current and previous major release of each browser. This would drop IE8, but make room for the many new clients we’re supporting: mobile versions of Chrome, Safari, Firefox, and IE; and the Android and Blackberry browsers. We don’t know what IE8 usage is like among WP users, though.
Conclusions
Method A, inline SVG, is the best option from the designer’s viewpoint — plugin authors include a single icon and all styling is provided automatically. MP6 makes dashboard customizations like a high-contrast admin theme for visually impaired users much simpler than the current admin design — and method A makes styling plugin icons as easy as the core set of dashicons. However, the technical hurdles and possible security concerns could be significant and we need more input on whether this method is practical.
Method B would be the next-best option — it would provide the primary benefit of using SVG icons (infinite scalability) without requiring changes to core. It would be significantly more difficult (though not impossible) for plugin icons to reflect user customizations, but would still require less manual work than creating separate sets of 1x and 2x PNG (method C).
We’re interested in any thoughts that you may have, especially if you’ve worked with SVG before and can offer insight on how we could implement method A successfully. If you know of any reason why any of these absolutely won’t work, feel free to rain on our parade.
Mel Choyce 8:17 pm on August 8, 2013 Permalink | Log in to Reply
Some initial concepts I’ve explored: http://melchoyce.com/wpadmin-ui/content-editing.html
Mel Choyce 8:33 pm on August 8, 2013 Permalink | Log in to Reply
Some issues with these concepts: They are heavily based on a document model, which is probably not the best solution for our users.
ntl0820 8:39 pm on August 8, 2013 Permalink | Log in to Reply
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 Permalink | Log in to Reply
What would be an alternative to a document model? What would the current model be, if not a document model?
Mel Choyce 10:00 pm on August 8, 2013 Permalink | Log in to Reply
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.
sara cannon 1:02 am on August 9, 2013 Permalink
If you want to reference a great builder, check out the new mailchimp drag and drop email customizer. great UX and very intuitive.
Mel Choyce 2:01 am on August 9, 2013 Permalink
@saracannon That was awesome.
If anyone wants to check it out, here’s a gallery I threw together of their post-signup, new user flow: http://imgur.com/a/L67xU
krogsgard 3:08 pm on August 9, 2013 Permalink
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 Permalink | Log in to Reply
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?
Mel Choyce 8:40 pm on August 8, 2013 Permalink | Log in to Reply
Discussing ideas on the p2s is a great place to start!
I’d love to find a solution that allows us to eliminate the need for an html view entirely.
I think the concept of post formats is something we’ll need to think about and explore moving forward, because I don’t think there’s a clear answer currently.
ntl0820 8:48 pm on August 8, 2013 Permalink | Log in to Reply
I love the idea of that, but I feel like the work done to achieve that is overwhelming to think about. I can’t count how many times I’ve had to go to that tab for one reason or another.
Avryl 8:55 pm on August 8, 2013 Permalink
Exactly. I think it should still be there, maybe tucked away.
Travis Northcutt 2:40 am on August 9, 2013 Permalink
Yeah, even if you somewhat hide the html tab, I think retaining it for “power users” could be pretty important.
portfola 4:25 pm on August 9, 2013 Permalink
Agree this needs to be available
Evan Herman 2:07 pm on August 13, 2013 Permalink
I agree. The ‘html’ tab should remain, but hide it if possible. I know many of the clients I work with regularly click that tab when they certainly do not need to.
Kim Parsell 10:26 pm on August 8, 2013 Permalink | Log in to Reply
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.
Justin Tadlock 11:55 pm on August 8, 2013 Permalink
Same here.
Ipstenu (Mika Epstein) 1:45 am on August 9, 2013 Permalink
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
krogsgard 5:14 pm on August 9, 2013 Permalink
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.
@mercime 8:25 pm on August 9, 2013 Permalink
I second the plea to retain the HTML view.
Brendyn Montgomery 9:39 pm on August 11, 2013 Permalink
Ditto – Really useful for cleaning up clients work who paste from word without using the “paste as plain text” option
.
I’d be OK with it in the screen options and off by default
lettergrade 1:57 pm on August 12, 2013 Permalink
Agreed. It also leaves options open that allow me to customize special client pages in a way they can be trained to edit, when custom templates are too far out of their comfort/safety range to touch!
TCBarrett 8:55 am on August 13, 2013 Permalink
How many support posts in the WordPress forums make use of the text view to help fix visual issues?
Taylor Dewey 9:17 pm on August 13, 2013 Permalink
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:
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.
Joen Asmussen 7:25 am on August 9, 2013 Permalink | Log in to Reply
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.
Ivan D. 9:10 am on August 9, 2013 Permalink
It’s a very good job. I like this “write flow”. The way that
can be moved and styled one by one is very interesting (even if i think that the button for style is not very visible).
Erlend Sogge Heggen 9:53 am on August 9, 2013 Permalink
I love the idea of non-strict post formats. If a video is the only media element, it’s a video post. If there’s a video and a chatlog, it’s a mix.
krogsgard 5:16 pm on August 9, 2013 Permalink
Joen,
I think this is a great start.
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.
krogsgard 5:19 pm on August 9, 2013 Permalink
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.
For columns, I think a semantic structure similar to Kovshenin’s plugin works well: http://kovshenin.com/2013/columns-for-wordpress/
DavidHickox 5:40 pm on August 9, 2013 Permalink
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.
Joen Asmussen 7:15 pm on August 9, 2013 Permalink
Krogsgard,
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.
jeffr0 4:37 pm on August 12, 2013 Permalink
When clicking the link to see your mockups, all I see is a page that says Mocco says hi. Where did the mockup images go?
shaunandrews 8:28 pm on August 12, 2013 Permalink
Beautiful! I love every bit of it!
Joen Asmussen 7:20 am on August 13, 2013 Permalink
Jeffr0: Sorry, was messing with the .htaccess, it’s up again.
Matt McLaughlin 3:35 pm on August 9, 2013 Permalink | Log in to Reply
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.
jeffr0 4:46 pm on August 12, 2013 Permalink
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.
binarymoon 1:30 pm on August 12, 2013 Permalink | Log in to Reply
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.
Ivan D. 8:36 pm on August 8, 2013 Permalink | Log in to Reply
I like a lot the first screen. Very intuitive. Just the tags and categories at the bottom seems too far from to be seen fast.
Grant Palin 10:08 pm on August 8, 2013 Permalink | Log in to Reply
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.
binarymoon 1:30 pm on August 12, 2013 Permalink | Log in to Reply
Not sure if this is of interest but I put together my own thoughts on the wordpress post editor earlier this year.
http://www.binarymoon.co.uk/2013/05/redesigning-the-wordpress-post-editor/
This was for 3.6 – and not so relevant with what you’re proposing but maybe it will have something helpful in there.
Helen Hou-Sandi 8:21 pm on August 8, 2013 Permalink | Log in to Reply
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?
George Stephanis 8:27 pm on August 8, 2013 Permalink | Log in to Reply
In the same vein of giving the editor screen some love, here’s something:
Mockup: http://cloud.stephanis.info/image/1d463B2l3k3p
Implementation thus far (much work to do yet, but a start): https://github.com/georgestephanis/publish-ux
If anyone wants to be added to the github repo, just ping me.
It should work well in concert with your alternate mockup on the above link, I think?
Mel Choyce 8:30 pm on August 8, 2013 Permalink | Log in to Reply
From a high-level point of view, what problem is your publish UX looking to solve?
George Stephanis 8:32 pm on August 8, 2013 Permalink | Log in to Reply
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.
ntl0820 8:36 pm on August 8, 2013 Permalink | Log in to Reply
I definitely like the idea of the publish button being more emphasized somehow
Mel Choyce 8:37 pm on August 8, 2013 Permalink | Log in to Reply
I’ve seen this problem crop up pretty frequently in user tests, and absolutely agree it’s something we need to fix.
Amy Hendrix (sabreuse) 9:33 pm on August 8, 2013 Permalink | Log in to Reply
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.
George Stephanis 11:22 pm on August 8, 2013 Permalink
At the very least, we could make one big publish button up above, even if it’s not a split button.
Kailey (trepmal) 12:04 am on August 9, 2013 Permalink | Log in to Reply
I’m all for the Publish button getting a permanent location (or two). Too important to be so easily lost by accidentally moving or collapsing the box.
portfola 4:28 pm on August 9, 2013 Permalink | Log in to Reply
+1
Ivan D. 8:28 pm on August 8, 2013 Permalink | Log in to Reply
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.
Dalton Rooney 8:49 pm on August 8, 2013 Permalink | Log in to Reply
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.
Helen Hou-Sandi 9:04 pm on August 8, 2013 Permalink | Log in to Reply
Note that it’s not really an end-user feature as it is, though, as it still requires editing the theme to display anything.
Ivan D. 9:29 pm on August 8, 2013 Permalink | Log in to Reply
Yes but they can be “usual” blocks. Like post and page type. They are built in but we can create our own post type.
Grant Palin 10:11 pm on August 8, 2013 Permalink | Log in to Reply
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!
Mel Choyce 10:33 pm on August 8, 2013 Permalink
I *think* this is the direction we were going with in Post Formats UI last cycle, before it got terminated.
Grant Palin 10:12 pm on August 8, 2013 Permalink | Log in to Reply
This. I was thinking that ACF flexible fields could be used to define reusable block types within single pages or posts, instead of having everything in one textarea.
ntl0820 8:35 pm on August 8, 2013 Permalink | Log in to Reply
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.
Mel Choyce 8:46 pm on August 8, 2013 Permalink | Log in to Reply
+1 to columns! Would make it even easier for users to work with any theme they want, instead of having to rely on themes with lots of extra features baked in.
Erlend Sogge Heggen 11:29 pm on August 8, 2013 Permalink | Log in to Reply
Definitely want to see columns becoming standardized. It’s an essential part of responsive design and should be handled in a unified, standardized manner.
erikdana 8:36 pm on August 8, 2013 Permalink | Log in to Reply
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.
Helen Hou-Sandi 8:47 pm on August 8, 2013 Permalink | Log in to Reply
Markdown is technical-friendly, not end-user friendly. That’s not to say that a Markdown mode shouldn’t be available, e.g. by plugin, but I would shy away from it being the default.
When it comes to embed code, we actually support oEmbed for many services. The work on #15490 was a really cool start.
idealien 2:06 am on August 9, 2013 Permalink | Log in to Reply
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 Permalink | Log in to Reply
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.
Dalton Rooney 8:58 pm on August 8, 2013 Permalink | Log in to Reply
I agree, the first option makes a lot more sense to me.
Mel Choyce 10:05 pm on August 8, 2013 Permalink | Log in to Reply
Markdown feels more appropriate as a plugin, IMO
Weston Ruter 8:36 pm on August 8, 2013 Permalink | Log in to Reply
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.
Weston Ruter 8:38 pm on August 8, 2013 Permalink | Log in to Reply
The aforementioned tweets:
https://twitter.com/westonruter/status/361403096682868736
https://twitter.com/westonruter/status/361402672844247042
Terry Sutton 8:54 pm on August 8, 2013 Permalink | Log in to Reply
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!
@Dalton’s implementation using ACF looks interesting too.
Dalton 9:05 pm on August 8, 2013 Permalink | Log in to Reply
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.
Ivan D. 9:31 pm on August 8, 2013 Permalink | Log in to Reply
I totally agree !
Mel Choyce 10:02 pm on August 8, 2013 Permalink | Log in to Reply
+1
Terry Sutton 1:09 am on August 9, 2013 Permalink | Log in to Reply
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 Permalink | Log in to Reply
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 Permalink | Log in to Reply
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).
Mel Choyce 10:04 pm on August 8, 2013 Permalink | Log in to Reply
Hah! I totally did not know it updates itself when you save or publish! I’ve always just changed it manually.
The more you know~
So yeah, seeing that change live would be great.
s3w47m88 9:45 pm on August 8, 2013 Permalink | Log in to Reply
I started this conversation two years ago and had nearly 300 votes to implement it and notable suggestions: http://wordpress.org/ideas/topic/improved-visual-editor
s3w47m88 9:45 pm on August 8, 2013 Permalink | Log in to Reply
Frankly, adopting something like ACE Editor as Google did would be ideal so we avoid markup challenges.
Helen Hou-Sandi 3:23 am on August 9, 2013 Permalink | Log in to Reply
Isn’t ACE a code editor?
DavidHickox 10:24 pm on August 8, 2013 Permalink | Log in to Reply
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.
Mel Choyce 10:45 pm on August 8, 2013 Permalink | Log in to Reply
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.
+1. Content is king.
sara cannon 1:07 am on August 9, 2013 Permalink | Log in to Reply
good to see you on here David – Please feel free to post sketches of your minimalistic ideas! love to see em
krogsgard 5:26 pm on August 9, 2013 Permalink | Log in to Reply
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).
Debra S 10:35 pm on August 8, 2013 Permalink | Log in to Reply
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).
Glad to see this process is going on!
Mel Choyce 10:40 pm on August 8, 2013 Permalink | Log in to Reply
In this case a content block would be any chunk of you can add to a post: images, audio, video, tweets, forms, quotes, etc. See these mockups for a rough visual idea: http://melchoyce.com/wpadmin-ui/content-editing.html
Terry Sutton 1:12 am on August 9, 2013 Permalink | Log in to Reply
Kudos on that first screen, Mel. It feels very well thought out. I came back to it tonight and it immediately feels ‘right’.
JakePT 12:47 am on August 9, 2013 Permalink | Log in to Reply
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:
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.
sara cannon 1:11 am on August 9, 2013 Permalink | Log in to Reply
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.
Mel Choyce 1:27 am on August 9, 2013 Permalink | Log in to Reply
Front-end editing would make me swoon.
DavidHickox 2:07 am on August 9, 2013 Permalink | Log in to Reply
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.
mtourtellott 1:44 am on August 9, 2013 Permalink | Log in to Reply
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.
Erlend Sogge Heggen 9:33 am on August 9, 2013 Permalink | Log in to Reply
I love the mockups!
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:
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:
http://i.imgur.com/RA02ic4.png
The two paragraphs and the image have now been joined into a 2 column layout. The 3/5 and 2/5 ratio was determined by some global default, but I can quickly change it by dragging the middle separator.
(I’m not sure what I had planned for the horizontal separator. Probably slipped into the table mindset there).
Re. Tables, I think this is a niche functionality that is better covered by some already outrageously popular plugins:
http://wordpress.org/plugins/tablepress/
http://wordpress.org/plugins/easy-table/
Ipstenu (Mika Epstein) 1:02 pm on August 9, 2013 Permalink | Log in to Reply
In both Mel and Joen’s mock ups, would we still have a place for the custom crafted excerpt? The more tag is good, but there’s a use case for both
Matt McLaughlin 2:41 pm on August 9, 2013 Permalink | Log in to Reply
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.
Matt McLaughlin 11:12 pm on August 12, 2013 Permalink | Log in to Reply
Not that anyone reads this far down in the comment train, but here’s a mockup.
http://mattnamclaughlin.wordpress.com/wpmusings/
Matt McLaughlin 3:45 pm on August 9, 2013 Permalink | Log in to Reply
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.
DavidHickox 5:25 pm on August 9, 2013 Permalink | Log in to Reply
This is an important concern, and one that I think would help break content out of the WYSIWYG document framework. Having preview tools in the editor would be fantastic.
Erlend Sogge Heggen 11:13 pm on August 9, 2013 Permalink | Log in to Reply
That’s an excellent idea.
wycks 6:30 pm on August 9, 2013 Permalink | Log in to Reply
+1 for Mel Choyces mock-ups, they look amazing. The biggest client frustration (for me) is when they wrestle with the editor, asking people to use shortcodes is not a good solution for formatting.
binarymoon 1:36 pm on August 12, 2013 Permalink | Log in to Reply
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 Permalink | Log in to Reply
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.
Matthew Muro 7:26 pm on August 12, 2013 Permalink | Log in to Reply
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.
Nick Halsey 8:22 pm on August 13, 2013 Permalink | Log in to Reply
What if we did something like MS Word does, where there are persistent controls (maybe that can be hidden via screen options), but selecting text also brings up a more convenient contextual toolbar?
Or, such a toolbar could always be shown when the cursor is active in the content area, although that could get annoying.
Dave Clements 1:26 pm on August 13, 2013 Permalink | Log in to Reply
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.
Mel Choyce 2:43 pm on August 13, 2013 Permalink | Log in to Reply
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.