Category: How It Is

When I started my little experiment with showing icons on custom taxonomies, I began with a text field. This was because it was the easiest to edit and change right away. Next I changed it to a selection dropdown, based on the content of the folder where the I’d stored my images.

And for the most part, that’s pretty cool. Except for the part where drop-down select boxes can’t show images. This meant I had to show the image name. Generally that’s okay. I know the name of the image I wanted to use. The problem is that I know that because I know the images I uploaded. For someone else, that’s 800 images or so they have to guess at, based on names.

After playing around with selections and forms for a while, I determined there really isn’t a great way to show a list of images natively. No matter what I was going to have to mess with this the un-fun way because the easy way, CSS, failed. You can use background-image in Firefox but not Chrome or anything else that people use.

Good news! As of jQuery UI 1.11, the selectmenu widget exists. Bad news! It’s not actually simple to implement. In fact, I absolutely failed at implementation. Let’s talk about why I failed, because it’s not just a matter of how convoluted the code is.

A large part of my failure in this is due to the scale. If you only have one or two images, it’s less stupid. But when you get around to sets of 800 images, you start to understand why WordPress has a media uploader the way it does.

The biggest factor, though, is that searching ‘visually’ is a difficult system to maintain. Symbology, the art of getting a ‘thing’ to represent another ‘thing’ is incredibly hard to pin down. Look at your WordPress dashboard. Why does a pushpin represent posts when they’re not all that different than the ‘two sheet’ icon of pages in functionality? Why is users a single person icon and not multiple people?

Ask yourself this: if you’re adding in a new menu item, what do you make your icon? Do you make it your brand logo (a G in a circle for StudioPress’ Genesis theme)? Maybe you make it a cloud with a down arrow to indicate downloads (as does Easy Digital Downloads). We wanted to add in a new Custom Post Type for ‘Characters’ and ‘Shows’ for my database site and Tracy, who is amazing at this sort of thing, cheekily picked a video camera for ‘shows’ and a name tag for ‘characters.’

I had a related but slightly different issue when I wanted to use Mark Jaquith’s meta I Make Plugins plugin. I wanted to see my plugins on the sidebar with a more unique icon. I couldn’t use the most logical one, a plug, since we’re already using that for Plugins. I went with a little ‘awards’ icon.

In both cases, we studied the list of Dashicons and picked the ones that made the most sense, but it required a visual study of what we really needed and an understanding of how they all worked. Scrolling down a massive list of all of those is annoying, but necessary. You need to look at your options, think about them, and feel what they mean contextually.

I haven’t yet figured out a perfect solution, but I’ll let you know when I do.

In a nutshell, the paradox is this:

The more likely a person is to test Beta and RC, the less likely they are to have bad code.

When people wonder why problems like the recent jQuery flub manage to make it all the way into the wild, they tend to assume the issue is not testing enough. They’re incorrect. The issue is not testing enough.

Put the lead pipe down.

What do you think ‘enough’ is? I promise you, the majority of people who have a broken site will say “It needed more time being tested.” And in return, the majority of developers will say “It needed more people with more diverse setups testing.”

So which one is right? They both are. We need more of the right people testing. We need people who are on the edges of ‘normal’ for WordPress. The problem is that the ‘right’ people are the people who have the worst code.

Take a look at WordPress 4.5. Not a single beta tester was using a plugin or a theme that used jQuery improperly. Look at Jetpack 4.0. Not a single beta tester had a server config that broke, but within 12 hours they had over 300 tickets about an error 500 on many sites. In both cases, a significant amount of testing was performed. People banged on the code and outright tried to break it. Just not the right people. And the worst thing is we cannot know who is the right person until after something breaks.

This leads to the other part of the paradox.

Someone whose site breaks after an upgrade is less likely to want to beta test.

This is because we’ve broken the trust. They cannot accept that their site went down, or their computer crashed. Or maybe they can’t afford to be Janie on the Spot and jump every time their site needs a bit of an extra hand when an upgrade goes bibbeldy.

Of course, this is why the people who are testing are less likely to have a problem. They don’t want to waste time debugging stupid code problems, so they put the time in front to make sure they don’t introduce bad code to their environment.

We create a vicious circle, because the only way to get better results from beta is to get more people beta testing. But few people are willing to fully beta test on a live site, and say what you will, there’s nothing quite like live testing on a real, production site. You can’t stress test reality until you get your setup on your server on your design on your everything.