During this year’s State of the Word, the new design for the WordPress administration experience was discussed.
As described by Matias:
As WordPress turns twenty years old, the overall aim of this work is to improve upon this experience at a foundational design level, giving plugins and users more control over the navigation while ensuring each WordPress experience is recognizable, intuitive, accessible, and delightful.
The full posts lays out the high-level plans for how they plan to move forward and I find the Scope section one that’s most relevant for developers (and designers who write code, as well).
It’s too long – and redundant – to post here, so I recommend reading it via the aforementioned link.
The Upcoming WordPress Admin Redesign
As a developer who’s worked in this space since “The Kubrick Era” (is that even the way some people refer to it?) and has been involved through the years of Gutenberg development, I have some thoughts relevant to the announcement that I’m sharing for posterity to see how things pan out as this project begins.
- I was a fan of the UI refresh we received a few years ago and I’m excited about what’s planned for this one, as well. It feels like it’s going to be much bigger but it’s easier to say that when we’ve been working with the current UI for so long (and I remember the design before that – it was no small undertaking to update it, either).
- I’m looking forward to seeing how hooks are going to be updated (and if anything new will be introduced in terms of what we’re able to do within the admin). Will be using JavaScript to work with them more? How does PHP fit into this?
- I’m curious as to how other things have not been updated in some time (such as certain Settings screens) will be updated beyond revamping the UI. That is, part of the WordPress philosophy used to be decisions, not options but I’d say the software isn’t as decisive as it could (or should?) be. My guess is most of the options are going to stay the same, but the general look and feel is what will change.
- I hope to see clear documentation provided for each release for developers, designers, and users to help make it clear how to achieve certain tasks. That was a challenge within the Gutenberg-era – things that worked in one release didn’t worked in a new release and the cycle was happening to fast, it was difficult to keep up.
- I’m very interested to see how plugins will inherently interact with the new UI given many are built to perform, look, and feel native within the existing UI.
- Performance is something that’s always a concern and if you’ve done any profiling or network monitoring within the tools the Chromium-based browsers provide, it’s evident that there’s some things that could be refactored. Is now the time? (I’m genuinely asking – this isn’t a loaded question.)
- I’m curious to see how well the existing Block Editor will fit within the context of the new experience. Will anything need to be modified, adjusted, or tweaked to make it feel more natural or is the Block Editor, as we know it today, more-or-less standardized?
But that’s not all there is to say about it. A lot is going into the overall project especially given this is just the third phase of a larger roadmap.
Change Is Hard
As the cliché goes, change is hard. But working through change when there are so many opinions on how the change is going makes it ever harder. Further, all the training material that agencies and organizations have as well as the material they will produce are eventually going to need to be updated as the new administration area is released.
I know the ultimate goal is to have more modern administration experience that’s easier for all types of users and I’m excited to see it come to fruition.
There’s likely going to be some friction – as is the case to come with any major updates – but I’m optimistic that we’ve learned a lot from how Gutenberg was initially developed and rolled out and I hope to see others work even more closely with the administration experience to make the transition easier both for developers and users.
I Didn’t Want to Resist Gutenberg
Though I wouldn’t say I resisted Gutenberg, I definitely found plenty of times where wasn’t ready for how I wanted to use it. The learning curve was forever influx because of the how the underlying technologies were changing or how the implementation of those technologies were changing.
To put it succinctly, trying to adopt it into my day-to-day work was a challenge.
Thus, it made me slower to adopt it both as a user and as a developer until it reached a certain level. Now it’s stabilized to a point where I both enjoy writing with it and have learned enough of the APIs to build out custom blocks for my day-to-day work in a consistent way (yes, even as one of those old people who primary works with server-side technologies).
I Don’t Want to Resist the Admin Redesign
To that end, though I recognize there are going to be inevitable hurdles to cross for this update, I also think this is a time in which lessons learned over the past few years can be applied.
Even though it’s not a one-to-one comparison, overhauling a major component of an older piece of software once yields plenty of learning. And I hope to be more present at least in terms of making sure the things developers enjoy – such as certain actions, filters, and other things with regard to menus, settings pages, options, and so on – are easy to learn and make sense when it comes time to migrate our code.
