Can We Please Style the Select Control?!
October 10, 2019 When working in Product Management one important aspect to determine the importance of a bug or feature in the product is how the person responds to the question or task you have them do. People give off many emotions, even subtle ones, that help you determine relative priority of potential work items. In my previous post regarding the native browser Controls & Components, I saw frustration at forms and controls in general, but goodness the <select> control got the brunt of the hate. One specific item of feedback I got in this survey which points to this passion and also to the opportunity here is summed up in five words, “Don’t f@*k this up more.” (read more quotes here) Let’s start digging into the data, beginning with the breakdown of demographics of who answered the survey: In this survey, we asked a similar question regarding what type of projects that you normally work on; but we added a new section to understand the reach of your largest web project. More on why we asked this a bit later. From this data we can adequately derive that we have a decent sampling across experience (although fewer beginners than I’d hope), project type and project scale. This is important because we want to ensure that we’re taking everyone’s feedback into account. The person working directly with React/Vue/Ember/Angular to build out their own <select> replacement will have a completely different set of “wants” versus the users of those components or developers using the built-in <select>. <select>, oh, the lowly <select> Jumping into the deep end of this, we asked what you found MOST frustrating when working with the <select> control, and I’ll admit I was kind of surprised at the top one: Frustration % Count Not being able to create a good user experience for searching within the list 27.43% 186 Not being able to style the <option> element to the extent that you needed to 17.85% 121 Not being able to style the default state (dropdown arrow, etc.) 14.01% 95 Not being able to style the pop-up window on desktop (e.g. the border, drop shadows, etc.) 11.36% 77 Insertion of content beyond simple text in the <select> control or its <option>s 11.21% 76 Insertion of arbitrary HTML content in an <option> element 7.82% 53 Not being able to create distinctive unselected/placeholder style and behavior 3.39% 23 Being able to generate new options from a large dataset while the popup is open 3.10% 21 Not being able to style the currently selected <option>(s) to the extent you needed to 1.77% 12 Not being able to style the pop-up window on mobile 1.03% 7 Being able to have the options automatically repeat on scroll (i.e., if you have an list of options 1 – 100, as you reach 100 rather than having the user scroll back to the top, have 1 show up below 100) 1.03% 7 While it did surprise me that the top pain point was not “Being able to create a good user experience for searching within the list”; the rest of it aligned with what I would have expected. All of the questions above can fit into three different categories, by placing them into their buckets it can further help us understand the category that will provide the largest impact if solved. This is important for us to understand because each of these categories requires its own investigation as there are numerous ways in which we could go about solving each of these problems and their subsequent sub-problems. Take the top pain point for example of “Being able to create a good user experience for searching within a list.” There are many ways in which we can try and solve this…
Like to keep reading?
This article first appeared on gwhitworth.com. If you'd like to keep reading, follow the white rabbit.