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 A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins. because they are separate projects with separate goals.
I could use your help with:
- running usability tests
- putting out a survey
- design
- managing some of these projects
- development
- testing (including accessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) testing)
The process
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,
Potential projects
I did a bit of searching on Trac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. (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 An online implementation of WordPress code that lets you immediately access a new WordPress environment to publish your content. WordPress.com is a private company owned by Automattic that hosts the largest multisite in the world. This is arguably the best place to start blogging if you have never touched WordPress before. https://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.
Publishing UX UX is an acronym for User Experience - the way the user uses the UI. Think ‘what they are doing’ and less about how they do it.
@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
Shiny saving
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.
Related tickets:
Toolbar remix
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 When using the WYSIWYG (What You See Is What You Get) editor in WordPress, you can expand the capabilities to allow more options. This expanded area is called 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).
Metabox A post metabox is a draggable box shown on the post editing screen. Its purpose is to allow the user to select or enter information in addition to the main post content. This information should be related to the post in some way. physics
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 A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party authors.
Autosave
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 The WordPress revisions system stores a record of each saved draft or published update. The revision system allows you to see what changes were made in each revision by dragging a slider (or using the Next/Previous buttons). The display indicates what has changed in each revision., but I’ll talk about revisions in a second.
Revisions UI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing.
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 HTML is an acronym for Hyper Text Markup Language. It is a markup language that is used in the development of web pages and websites. elements to give them some idea why their preview is looking funky. I wouldn’t try to autoclose tags.
Live preview
Wouldn’t something like a live preview (even if it’s tiny or off screen) be pretty handy? I think so.
Proofreading mode
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 Core is the set of software required to run WordPress. The Core Development Team builds WordPress., but might just be. Even if it isn’t, it could be a pretty dang rad plugin (if there isn’t one already).
Content blocks?
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 Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. interface. The initial Shortcake implementation could be great first steps toward the block editor some of us dream about (or have nightmares about).
Thoughts?
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.
#editor, #post-new, #publishing