Before I get into it, I’m going to need help to get some of these projects going. If you see something you’re interested in working on, let me know in the comments. The following project proposals are not intended to be a single feature plugin because they are separate projects with separate goals.
I could use your help with:
- running usability tests
- putting out a survey
- managing some of these projects
- testing (including accessibility testing)
Before we get into designing, we need to do discovery (research) and a clear idea of which specific problems we’re going to solve. All of these will require research, some usability tests, maybe a survey or two,
I did a bit of searching on Trac (and am still doing so) specifically looking for anything related to posting or content creation. I have started some initial researching on anything related to creating content. I looked as past usability tests. I looked at some feedback around WordPress.com’s editors as well. We can learn from some of the ideas tried there.
The following are a list of project ideas. If some get interest and traction, we will do a kickoff post for it (depending on scale) and I’ll add any resources/related information I’m aware of. Ideally, I’d like one of you to step up and lead a few of these if you have the time and are interested. If you have something you’d like to add as a potential project idea, please let me know in a comment.
@helen brought this up as a project idea and it’s a good one. Here’s the proposal:
When running user tests for post formats during the 3.6 release cycle, one of the most striking observations was that a majority of users had a hard time locating the Publish button at all. Because it’s typically in the top right, it’s possible it’s not on the screen, and is very disconnected from the general content workflow of writing and then publishing. The most common idea is to put the buttons in the bottom bar of the editor, since it pins and makes sense within a writing flow. There are, as always, other considerations to make, such as post types without an editor or various post statuses (another problem in the current box – you can’t actually have a private draft, because it’s the same field in the database). This project would likely involve multiple approaches, storyboards, mock ups, and lots of user testing through all stages.
Related ticket: #17028
Currently, when saving or updating a post the whole page reloads. The page reload makes it easy to lose your place when saving or updating. Because of the page reload, saving feels slow.
My proposal is to introduce Ajax saving to prevent the page reload. This will introduce new problems to solve. We’ll need a way to provide feedback to the user about the status of a save. It will need to be accessible. I believe those are both doable.
I’d like to see what we can do to improve the editor’s toolbar. This will likely include a bit of button shuffling and some style changes. For example, I think the drop down to select the type of text (heading 1, paragraph, preformatted) should be in the primary toolbar rather than in the kitchen sink.
Related ticket: #27159
Post New UX
I’d like us to take a look at the Post New UX as a whole. This might result in some mini projects/experiments rather than being a single feature plugin. I suspect the space could be utilized more efficiently. We can probably also make Post New feel a bit less overwhelming for newer users (I don’t want to remove functionality at all).
Metaboxes are helpful. That’s why we have so many of them, right? Let’s see what we can do to make them part of the posting flow rather than a bunch boxes of settings that we have to battle before publishing anything. This project will need a good amount of love and research and will need to consider how plugins/themes use or hijack them. This might be a good place to provide some patterns or suggested design practices as a resource for plugin authors.
I think if we implement Shiny Saving, we can definitely have autosave functionality. When digging through WordPress.com editor feedback, autosave was almost universally loved. It does have some awkward issues with revisions, but I’ll talk about revisions in a second.
This is a bigger less-urgent project (unless we get Autosave in), but I think the revisions interface could use a bit of a rethink. It is currently a bit difficult to use and understand. I know @melchoyce had come up with some promising ideas during the community summit when we were discussing it with @adamsilverstein. This project will likely include some way to move between revisions quickly as well as potentially showing a different interface for viewing changes.
Don’t break my divs
It’s really easy to break just about any theme by forgetting to close a `div` or a `span` (and some other elements). I’m wondering if we can do something to warn users about unclosed html elements to give them some idea why their preview is looking funky. I wouldn’t try to autoclose tags.
Wouldn’t something like a live preview (even if it’s tiny or off screen) be pretty handy? I think so.
I’ve had quite a few people request some sort of proofreading mode that allows them to comment/highlight/interact with post content. This is in the realm of projects I’m not sure are right for WordPress core, but might just be. Even if it isn’t, it could be a pretty dang rad plugin (if there isn’t one already).
I was hesitant to add this as it’s been attempt a few times in the last few years (RIP CEUX). The idea of content blocks has come up again in conversation a few times over the last few weeks so I think we should revisit it with vigor. I know the Shortcake group is looking at an interface that might go hand in hand with a content block interface. The initial Shortcake implementation could be great first steps toward the block editor some of us dream about (or have nightmares about).
If you are interested in tackling any of these, have a proposal in addition to these, or are have concerns/thoughts about a project, let me know in a comment.