Reworking SearchWP’s Advanced Settings Screen – Part 4

In the last update, progress was made by moving both a UI component and an Action from the Advanced settings screen to the Stats screen. This was a double-win because not only did the UI make more sense on the Stats screen, it freed up some space on the Advanced settings screen too.

Because enough had changed recently I decided to go back to pen and paper to start sketching out an updated version of this Advanced settings screen.

There were a few attempts here, primarily at structuring things given the new items at hand and also experimenting with how to best utilize the available space without providing way too much to look at simultaneously. Despite this being an Advanced settings screen, I didn’t want it to feel overwhelming. Unfortunately this round of sketching wasn’t super fruitful, but it did spark an idea.

One thing I was hung up on was presenting management of stopwords and synonyms in a way that didn’t compete with each other. Stopwords (in most cases) will have a default set of terms to work with, but unless someone has already been using Term Synonyms that list will be empty. Further, managing synonyms can grow to be a very long list. With synonyms alone I’m trying to implement a UI component that can be anywhere from zero to hundreds of pixels tall.

The “Toggle Misstep”

I thought that maybe implementing some sort of toggle between the initial view of stopwords (that will have data from the start) and synonyms (that likely will not have any data but that data will grow over time) might alleviate the imbalance. I tried it out.

At first glance I thought it was a clever solution; it presented the default list of Stopwords effectively, and swapping over to Synonyms was graceful and even if the list of Synonyms were empty it wouldn’t be jarring to look at.

Because it’s a departure from what you typically see in a WordPress settings screen I wanted to bounce the idea off someone else, so I reached out for feedback from another product person I trust.

A note on getting feedback

As someone who works on products by himself I strongly encourage finding a person or two (or three) to bounce ideas off consistently. I don’t mean every hour, but at somewhat consistent intervals as you’re building something out. This person may be hard to find, but knowing someone will give you an opinion about something is a wonderful thing.

A great place for this is a mastermind, but I don’t happen to be a part of one right now, so I rely on a couple of people I’ve been friends with for years to give me feedback I know will be more than surface level. These friends aren’t invested in my products nor am I invested in theirs, but we talk about what we’re doing consistently. That gives us grounds to ask the right questions as potential customers and fellow product builders that can jump start ideas in just the right way. It helps that we have similar approaches to what we do, which makes the conversation much more valuable than running a screenshot by someone who isn’t familiar with the context of what you’re trying to do.

Back to problem solving

I was reviewing both the problem and proposed solution with someone and a simple question came up:

That little toggle switch might be confusing to some users

I could totally see some user thinking “I can have one or the other, but why not both?”

As much as it completely derailed my toggle idea, it was 100% on point. I realized that I got so far into the weeds by trying to re-work the architecture of this screen I neglected to take a step back and ask myself “just because you can, does it mean you should?”

I fell into what I see as a classic trap when building something: implementing a novel idea vs. sticking with something that is a known and established convention.

This same friend in our short back-and-forth about the problem at hand suggested a more elegant solution: tried and tested tabs. I skipped the sketching and came up with something that I thought did the job quite well.

My thought here was in response to the first round of feedback that I got, that a toggle communicates “one or the other” so I thought it fitting as a solution to the Export/Import component. Because the toggle was still a departure from “the WordPress way” I sought out additional feedback which came back as:

I like the synonyms tab, that makes sense to me

The export/import should probably work the same way. that toggle is a little hard to understand

Strike two! 😆 This feedback confirmed without a doubt that the toggle (despite me thinking was a neat solution) just wasn’t fitting here, and I was trying to force it. Tabs are much more applicable. A quick adjustment resolved that problem and I think we’re back on the right track!

There is still a lot of work to be done. These UI components are in place, but they’re not doing anything yet. There are missing action buttons, and the concept of notifications is something that deserves some focused thought as well.

▶︎ To be continued…