The Future of WordPress

Originally posted 16 August 2013

A new approach to developing WordPress has begun.

As major changes are developed for WordPress these changes are going to happen initially through developing plugins.
Since plugins can be created without having to incorporate them initially into Core.

These plugins similar to new admin style of  mp6 plugin will be developed by WordPress Core developers and other developers and designers. Mp6 is a plugin style has already been incorporated into the admin style of One can download and use the plugin for ones own hosted WordPress sites.

Right now new groups are being formed to focus on different aspects of WordPress:
(I will update this post on occasion.)

Features as Plugins Tracking


MP6 is a plugin under development to follow along what is going on:
Location of plugin is here:


Omnisearch makes it easy to search for anything, both locally on your site, and from select providers on the web!

Using Omnisearch

Using Omnisearch is remarkably easy. Just search! If you’re in your WordPress Admin Panel, you can use the search bar in the WordPress Admin Bar (top right, just beyond your User Menu), or go to Jetpack » Omnisearch and start from there. Please note that the Search field on the WordPress Admin Bar will only Omnisearch from the back-end of your site, as the front-end already has a search field there to perform a site search natively, and we didn’t want to change that for you.

…. continue the reading here:

Featured Content


Area: A location in a theme where featured content displays. Areas are defined by and stored in the theme. Areas may appear in multiple locations.
Post: This includes Posts and Pages. Support for custom post types may be provided by filter. Posts may appear in multiple areas simultaneously.
Collection: A group of posts. Ideally defined implicitly by dropping posts in an area.


We will need to create a UI that gives publishers the following abilities:

  • Add/Remove posts to/from area.
  • Move a post from one area to another.
  • Define a custom title, excerpt, and featured image for a post.
  • Manage collections.
  • Move a collection from one area to another.

We possibly need to create a metabox in the edit post/page screen so that publishers can:

  • Add the post to an area(s).
  • Remove the posts from an area(s).
  • Define a custom title, excerpt, and featured image for a post.

And of course an API ????

  • Register an area or areas
  • Get featured posts for an area

General requirements:

  • Collections and their assigned posts have to be portable between themes, and ex-/importable.

Features for a v2:

  • Scheduling collections
  • Area-agnostic custom title, excerpt. and featured image
  • Hierarchical areas

Widgets UI Refresh

Widgets, Widgets, Widgets

We’ll be holding weekly IRC chats every Monday at Friday, August 16, 2013 22:00 UTC+2 in #wordpress-ui.

Go to my embeded IRC Web Chat.

What problem are you trying to solve?

This group will be focused on improving the process of adding and editing widgets in the WordPress admin. There’s a few problems with the way things work now, including:

  • Widgets, sidebars, and their connection to themes is pretty confusing. There’s no connection between the sidebar in wp-admin, and the area in your theme.
  • The current focus of the page is on available widgets. Sidebars only take up a small portion of the page.
  • Having more then 2 or 3 sidebars makes it terrible hard to drag-and-drop widgets around the screen.
  • Its not at all obvious how you install a new widget.
  • Its not possible (without code) to display widgets, or groups of widgets, based on certain conditions like, “only show on home” or, “don’t show on single”.

What proposal solutions are you interested in exploring?

Additonal Site:

Admin Help Improvements

Here’s a draft of the proposed project scope:
As part of the move towards developing features in plugins, we’re looking at making improvements to the WordPress admin help. On Monday at 3:30 UTC we discussed the issue in #wordpress-dev

The Problem: The current Admin Help is hard to find unless you know it’s there. The content lacks any focus; it’s simply a description of what’s on a particular screen and doesn’t add any particular value. It’s possible that we’re failing WordPress users by a) not providing useful help in the Admin, and b) not providing adequate basic resources in the Codex.

Work was carried out by @chexee in ticket 21583 on making Help and Screen options more discoverable.

In the State of the Word, Matt talked about the 96% attrition rate on, and how it was probably higher on WordPress due to the extra steps. If users are getting frustrated and walking away from WP, how can we prevent that frustration?

Goal: to alleviate frustration in people who find the admin too difficult to use.

(Note: changing the Admin is outside of the scope of this project. We are creating help for the admin as it is. However, testing and research will inevitably show up issues which we should record and make available for others to work on should they wish to).

Some questions to keep in mind:

  • how can we best provide admin help to users?
  • what help do users need?
  • how can we ensure that help is unobtrusive for people who don’t need it?
  • what tools are available to us?
  • should we de-couple screen options and help?
  • how can we ensure that the help is accessible to all WordPress users?

The process:

1. Research & Identifying the Problem
Before fixing the problem, we need to discover what problem users are facing. @trishasalas has startedwriting some questions for user testing so we can identify at what stage the pain points are appearing. For example, are they baffled when they first log in to WordPress, or are they having problems when they are in the middle of work?

@jazz3quence has started researching how other platforms are implementing admin help, and the tools available. Once we have identified the problem we can match a tool to it.

We should also draw up a list of WordPress plugins that are providing admin help (WP-Help, for example).

2. Mockups
Mockups and sketches will be created for the following:

  • the user interface
  • the user’s journey and interaction with the functionality

3. Design & Development
A UI designer will put together the interface (to match MP6) and developers will be needed to create the plugin. After the first version we go on to the next phase.

4. Test and iterate
Testing and iterating for fun and profit.

5. Finish!
Time for tea, beer, or scotch.

Who’s needed:

It would be desirable to get the following skills involved:

  • developers
  • UI designers
  • technical writers
  • WordPress users (for testing)
  • people who run WordPress training (to provide feedback)

To see comments and make a comment:

Pages & Menus Merge

The relationship between pages and menus is not immediately obvious for new users. How to sort menus, how to remove menu items when you’ve deleted a page, these are questions that might cause confusion for users when they are handled in two different sections.

Merge the two sections, so the relationship becomes clear.


This group will be focused around streamlining and improving the overall content editing experience in WordPress. We’ll be exploring better methods for curating and formatting content within the post and page editors. We have a preliminary set of mockups that we’ll be expanding and iterating on as we start. Here are some more mockups:

Our first CEUX meeting will be taking place on Tuesday, August 20, 2013 19:00 UTC+2 in #wordpress-ui. Providing this works for most people, we’ll continue meeting at this time each week.

Go to my embeded IRC Web Chat.

Rethinking Content Editing in WordPress: v2

How can we improve and update the posting experience in WordPress? This alternate concept explores adding content blocks inline.

Combined Front/Back End UI

THX38 (Theme Experience)

We’ll be meeting in #wordpress-core-plugins on 8:00 pm on August 19, 2013. If this works out we’ll keep this time going forward. Go to my embeded IRC Web Chat.

What problem(s) are you trying to solve?

  • Significantly improve and re-imagine the theme browsing screens for a better user experience.
  • More beautiful, visually focused, fast, and up to date with the current times of mobile ubiquitousness, flexible resolutions and retina devices.
  • Make it easier and enjoyable for people to find the best and most suitable themes for their needs and tastes.

What proposal solution(s) are you interested in exploring?

  • Possibly implement a Backbone.js based plugin to handle the display of themes, that takes over themes.php.
  • Puts the focus on screenshots (retina and larger if we can balance it with backwards compat), removes unnecessary visual burdens from the main browsing experience.
  • Make it fast, instant searches within your collection. Rethink how we deal with filters.

Some concepts:

This work will also transition into revamping the .org directory with the goal that searching for and installing a theme is equally rewarding and consistent no matter where you start.

Past experiences: look at lessons learned from the theme showcase.

More info here:

Media Library Grid View

Exploring Layouts for the WordPress Media Library

Posted on 

WordPress 3.5 brought us the great media modal, which makes it super easy to upload and add images while writing a post. The modal features a grid-based layout, with large images that make browsing your library a breeze. Meanwhile, the main media page hasn’t changed much. It still lists your media library using a standard WordPress table view. Its not bad, and sometimes the table view is useful — but a that grid-based layout from 3.5 would bring that easy, breezy browsing to the main media page.

I’ve worked up a few quick wireframes to run through the idea. I’m diggin’ it. There’s the standard table list view, a hybrid view, and a traditional grid view. Lots more ideas brewing in my head, but I wanted to get these “on paper.” What do you think?


JSON REST API: Version 0.4 

After a week’s hiatus thanks to WCSF and the midsemester review, I’m back with a new release of WP API!Version 0.4 is now available with the following changes:

  • Add Backbone-based models and collections – These are available to your code by declaring a dependency on wp-api (#270)
  • Check json_route before using it (#336)
  • Conditionally load classes (#337)
  • Add additional test helper plugin – Provides code coverage as needed to the API client tests. Currently unused. (#269)
  • Move json_url() and get_json_url() to plugin.php – This allows using both outside of the API itself (#343)
  • getPost(0) now returns an error rather than the latest post (#344)

As always, the full changes are available if you’re interested.

This release brings the first version of the Javascript API, based on Backbone models and collections. To use it, simply declare `wp-api` as a dependency to your script, then start using the `wp.api` classes. Here’s a quick example of how to use it:

…continue reading (check the comments as well) here:

Check out the WordPress handbook: 

In regards to creating wireframes/mockups: 


Leave a Reply

Your email address will not be published. Required fields are marked *