With most of the placement challenges solved it was time to start piping things up and making it all work again.
An item on my punch list to think about when rebuilding this screen was to rethink what notifications looked like. In the (now legacy) screen I used a standard admin_notice where applicable, as most of the screen was operating on page reloads. Admin notices are easy to pop in, and as a WordPress user they’re definitely expected.
There are thousands of ways to display notices. Every web app has their own implementation and notification styles change among WordPress plugins too. I ran into this problem when I built SearchWP 2.9 (which redid the main settings screen) in the same way I’m rebuilding this Advanced settings screen. I thought it best to stick with the native style of WordPress’ admin notices, but integrate them in context as opposed to having them spread across the top of the screen.
I think it’s a nice solution, and continued down that path here as well.
Feeling like it was a good start, I continued linking the UI to actual functionality and was still on board after seeing it in action. As I continued working I recalled that I also needed to implement something better than the way I was asking for a double opt-in for certain actions like resetting the index.
Resetting the index is an action that primarily cannot be undone but secondarily (depending on the site at hand) can take some time to rebuild, so I want to make sure it can’t be reset unintentionally. As it stood the current process to confirm the action was to show a stock alert() which got the job done, but isn’t very elegant.
I borrowed a component/interaction implemented on the main settings screen that I think serves the purpose well:
Much better than a native alert dialog!
Resume the feedback loop
Now that I was getting on a roll I’m more consistent in getting feedback on smaller changes. I reached out to that same friend to chat a bit more about the notices and how everything was coming together. This friend agreed that the notices fit well and got the job done, but mentioned that with the way things sat it looked a bit “boxy” and I instantly agreed.
After thinking a bit about how to reduce the boxy-ness I realized that the Actions and Settings don’t need to be segmented, in fact they’re quite related to one another. The original intent was to divide them based on whether it was a button or checkbox, but that wasn’t anything integral to the overall design of the screen. Combining them would bring us down to three meta boxes (a meta box is a WordPress convention for the white box containers you’ve been seeing) instead of four which might be just what we need.
There were also a couple things nagging me about the notices too:
- Is the button really necessary?
- Because we’re waiting on AJAX requests behind the scenes, how can we accommodate the latency of each request?
The first item was quick to solve; I felt like having buttons in notices (especially the screencast above) was superfluous and just added to the clutter. From here on out notices would be informational only, the only button would be to dismiss the notice. This will help in the language used in the notices and also keep the UI clutter down.
I thought it may be difficult to get around the fact that there’s latency associated with clicking an Action but quickly realized that I had three notice states that could be utilized. I decided to use the ‘warning’ notice to describe any wait time that needs to happen:
While this workflow worked well for the Actions, they would be extremely overkill when it came to the settings (the checkboxes that can be toggled on or off) and while I liked the way the ‘Saved’ message appeared in the current settings screen, it didn’t solve the problem very well here. In the current settings screen if there was more than a second of latency you would question whether ticking the checkbox actually did anything. Further, the ‘Saved’ indicator appeared near the title of the meta box which in this case was too far out of context to be useful.
I liked the spinner during the waiting notification when resetting the index, so I applied that to the checkbox component here too:
At this point it feels like things are coming together really well! Most of the UI work is done (famous last words, right?) and it’s time to continue linking everything up, testing it all, and fine tuning a bunch of margins and padding prior to getting this update out to SearchWP customers!
︎ To be continued…
The post Reworking SearchWP’s Advanced Settings Screen – Part 5 appeared first on Jon Christopher.
