The idea of an “iterative process” is nothing new in software development. It’s present in a number of different methodologies and likely because it works well especially when getting customer feedback.

One of the places that I also find it useful is when building administration interfaces for WordPress plugins.

To be clear, I’m not a designer, so when it comes to front-end work, I always refer to the style guide and the mockups the designer provides to me from the outset of the project. (I only mention this because I think it’s a practice anyone who’s not a designer should follow, but I digress).

But when it comes to working on administration screens or back-end screens for WordPress, I tend to follow a strict rule: Make sure it looks as natural as possible.

How, then, do iterative development and the interface of WordPress administration screens have anything to do with each other?

WordPress Administration Screen Design

This particular article forgoes talking about things that are expected for saving information. That is, I’m assuming all:

  • sanitization,
  • validation,
  • nonce checks,
  • permission checks,

And the like are understood and handled.

For this post, I’m going to keep it simple. Let’s say that we want to have:

  • a couple of text fields,
  • a save button,
  • a reset button,
  • and maybe something extra at the end.

How might this play out through an iterative process when designing it?

1. Sketching It

Say you’re working on something and you’re planning what the administrative screen will look like. Given what we had above, perhaps an initial sketch might look like this:

WordPress Administration Screen Design

Easy enough, right? It represents what the project needs to maintain, and it displays everything we need for this particular administration screen.

2. Building It

Once put together, it should look as native as possible. Given the styles we have available in WordPress, it’s relatively easy to build this with the available APIs and markup:

WordPress Administration Screen Design

And what does each field and button do?

3. Refining It

This is where refining the functionality comes into play. For example:

  • I don’t think the Save button should be enabled until the required fields are populated,
  • I think the Reset button should clear what’s present,
  • There should be a degree of error messages all of which represent what it is we need to do when something fails, when something may not be right, or something is completely wrong.

Obviously, it much easier to talk about this when it’s not referring to a specific project but perhaps some of the ideas are applicable in whatever it is you have going on.

Asynchronous Improvements?

One of the things we’ve become accustomed to with devices like our phones and certain part of our operating systems is that when we toggle a switch or make a small change, the data is saved.

That is, no confirmation action (other than something destructive like deleting a file, of course) is required. The data is simply saved, and the option works.

Yet, we still see a lot of Save buttons in WordPress, don’t we? What about saving inputs via Ajax or another asynchronous method? This is something I’ve yet to implement it but I’ve certainly considered it.