Published on | Prototyping: From UX to Front End — Medium Peter Adam

A few weeks ago I came across Zoltan Kollin’s excellent article, Dropdown alternatives for better (mobile) forms. As someone who’s quite new to web design, it was eye opening and I realised that my site had three unsightly dropdown menus which were impeding user access to information. A combination of techniques was required to replace them, and although I had the inspiration I needed from the above article, implementing them was not as straight foward.

Below is a recount of how I went from this:

to this:

and removed my dependence on dropdown menus forever!

All the code is available in full on my Github.

Segmented Controls

I found a CSS only example here, which was exactly what I needed, but unfortunately written in SCSS, which I wasn’t really familiar enough with to get working easily. Instead I checked out the page source, and found the implemented CSS file (which you can find here), which with some trial and error I managed to adapt into something I could use.

Before we dive into discussing the CSS, we need to write some HTML. All segmented controls look something like this:

<div class="segmented-control" id="sc1">
    <input type="radio" name="sc-1" id="sc-5-1-1" checked>
    <input type="radio" name="sc-1" id="sc-5-1-2">
    <input type="radio" name="sc-1" id="sc-5-1-3">
    <input type="radio" name="sc-1" id="sc-5-1-4">
    <input type="radio" name="sc-1" id="sc-5-1-5">

    <label for="sc-5-1-1" data-value="Map">Map</label>
    <label for="sc-5-1-2" data-value="Radius">Radius</label>
    <label for="sc-5-1-3" data-value="County">County</label>
    <label for="sc-5-1-4" data-value="Region">Region</label>
    <label for="sc-5-1-5" data-value="Country">Country</label>
</div>

And that’s it! So the underlying input elements are radio buttons, the name must be unique for each segmented control on the page. Additionally, the first number in the id must be the number of options (in this case 5), the second number can be anything, but for clarity should generally match the name, and the final number must be unique for each input in the control.

For the labels, the data value is what is displayed when the input is selected, so capitalisation is necessary, and the ‘for’ value should match the id of the corresponding input. This will give us something that looks like this:

If we had a second control on the page, this time with 2 options, we would create it as such:

<div class="segmented-control" id="sc2">
    <input type="radio" name="sc-2" id="sc-2-2-1">
    <input type="radio" name="sc-2" id="sc-2-2-2" checked>

    <label for="sc-2-2-1" data-value="On">On</label>
    <label for="sc-2-2-2" data-value="Off">Off</label>
</div>

And get something like:

Ok, so now back to the CSS. The file itself is fairly generic, but a few lines are important to change.

The code on line 4 controls the styling of non-selected elements:

.segmented-control {
    /*Controls the color of the non-selected elements*/
background-color: white;
    ...

The code on lines 189 and 190 controls the styling of non-selected text:

.segmented-control > label {
margin-bottom: 0;
color: rgb(5, 8, 78);

The code on line 224 controls the styling of selected element text:

.segmented-control > label:after {
color: white;

And the code on line 256 controls the styling of selected elements:

.segmented-control > label:before {
    /*Controls the color of the current selection*/
color: rgb(179, 38, 80);

There are two more changes to make, which are slightly trickier, but thankfully unnecessary unless you’re using segmented controls with more than 5 options (at which point it’s worth exploring other choices).

Lines 52 to 186 control movement between options. You can see that lines 61 to 94 control how the slider moves between the 1st element, itself, and all others (and vice versa, from each element back to the 1st). Then lines 103 to 126 control the movement from the 2nd element to itself, the 3rd, 4th and 5th (not the 1st as this is already accounted for), and so on until the 5th element which only controlling its movement to itself. Adding more options requires adding information for each existing element to each new element, and each new element to itself and other new elements.

This is really just a copy paste job, but can become a bit fiddly when replacing numbers. You can see why people use SCSS!

Lines 270 to 279 have information for segments 1 through 5, and if you’re using additional elements, you’ll need to replicate these for 6 onwards. This is a matter of copying lines 278 and 279, pasting them at line 280, changing the 5’s to 6’s, and the 20% to 16.66% (1/6). Then repeat this until all your options are accounted for.

And that’s it! Link the CSS to your HTML file, and you’ll have segmented controls doing this in no time!

Beautiful! Now, onto Javascript, how do we get the current value, or the value when clicked?

This is a little more complicated, as there’s a difference between Chrome/Safari and Firefox, and click events in jQuery register twice.

First, if your users change the control, then click a different element to change some information based on the control, getting the value of the control in Chrome and Safari is a matter of:

$("#sc1 input[type='radio']:checked")[0].labels[0].innerHTML

This will return the value of the control with id sc1 . However, Firefox doesn’t like this, so to distinguish between the two, you can test with the following if statement:

if ($("#sc1 input[type='radio']:checked")[0].labels == null){
    // Firefox

} else {
    // Chrome - Safari
    val = $("#sc1 input[type='radio']:checked")[0].labels[0].innerHTML;
}

Note that testing for $(“#sc1 input[type=’radio’]:checked”)[0].labels[0] or $(“#sc1 input[type=’radio’]:checked”)[0].labels[0].innerHTML will not work, as Firefox will throw an error instead of null.

So when the browser is confirmed as Firefox, the following code will extract the id of the selected input:

if ($("#sc1 input[type='radio']:checked")[0].labels == null){
    // Firefox
    var selector = document.getElementsByName('sc-1');
    for (var i = 0; i < selector.length; i++) {
        //Check if button is checked
        var button = selector[i];
        if(button.checked) {
            //Return value
            id = button.id;
        }
    }
    if (id.slice(id.length - 1) == 1){
        val = 'Map'
    else if (id.slice(id.length - 1) == 1){
        val = 'Radius'
    else if ...

} else {
    // Chrome - Safari
    ...
}

So the segmented control is selected by the name of the inputs ( sc-1 in this case), which are then looped over and the id of the current selected is returned. The last number in this id (the unique identifier) can then tell you which element is selected. This is pretty annoying, but after a lot of searching I couldn’t find a better way to get things to work on Firefox… Thanks Firefox ¯\_(ツ)_/¯

So if we add a button, we can now do cool stuff like this:

Sweet!

Now that’s all well and good if there’s an external button, but what if you want an event to happen when the segmented control is changed. Unfortunately, if we just add a click listener to get the current selection when the segmented control is clicked, it responds twice. First time getting the current value, then the value that was clicked. This is an issue especially when making AJAX calls, as things can get messy quickly.

So if we do something like this (the function getval() is the if statement above to ensure the control works with Firefox, see the whole thing here):

$('#sc1')
    .click(function(){
        val = getval('sc1');
        console.log(val);
        $('#result').html(val);
});

We get the result we want on the page, but watching the console we see something strange:

We’re getting the value twice per click. This is an AJAX nightmare!

The way to get around this is to add event listeners to each input individually, which can be simplified using a for loop :

$('#sc1')
    .click(function(){
        val = getval('sc1');
        console.log(val);
        $('#result').html(val)
});

That way, when we click on any part of the control, the value has already updated when we retrieve it, so we see something like this on the page:

And this in the console:

Perfect!

One final word, the transitions don’t work perfectly in Safari, and tend to be a lot jumpier than smooth. I haven’t explored a solution to this yet, but will update the post when I find one.

Start Typing Dropdowns

Now, as mentioned above, Segmented Controls aren’t a one size fits all solution. I’d avoid using them when there are over 5 choices, and never go for more than 8 (I’ve used 8, but only when the feature in question has no mobile application).

The alternative mentioned in Zoltan’s article is to use dropdowns where the user can start typing, and have suggestions presented to them. Fortunately, HTML5 introduces the datalist, which means it’s super easy to get these up and running. The HTML is as follows:

<datalist id="counties">
    <option value="Carlow">Carlow</option>
    <option value="Cavan">Cavan</option>
    <option value="Clare">Clare</option>
    <option value="Cork">Cork</option>
    <option value="Donegal">Donegal</option>
    <option value="Dublin">Dublin</option>
    <option value="Galway">Galway</option>
    <option value="Kerry">Kerry</option>
    <option value="Kildare">Kildare</option>
    <option value="Kilkenny">Kilkenny</option>
    <option value="Laois">Laois</option>
    <option value="Leitrim">Leitrim</option>
    <option value="Limerick">Limerick</option>
    <option value="Longford">Longford</option>
    <option value="Louth">Louth</option>
    <option value="Mayo">Mayo</option>
    <option value="Meath">Meath</option>
    <option value="Monaghan">Monaghan</option>
    <option value="Offaly">Offaly</option>
    <option value="Roscommon">Roscommon</option>
    <option value="Sligo">Sligo</option>
    <option value="Tipperary">Tipperary</option>
    <option value="Waterford">Waterford</option>
    <option value="Westmeath">Westmeath</option>
    <option value="Wexford">Wexford</option>
    <option value="Wicklow">Wicklow</option>
</datalist>
<input type="text" list="counties" title="county-selector" id="county-selector" placeholder="Start Typing">

A little bit cumbersome to type out, but when implemented, it presents a much improved interface for the user to find the option they’re looking for:

Beautiful! Now, because nothing is ever easy, Safari doesn’t support datalists, and falling back to a traditional dropdown isn’t simple or really an acceptable solution. Thankfully, there’s a great solution from Alexis Deveria, which simulates pretty similar functionality in Safari. Get the polyfill.css and datalist.polyfill.min.js from the Github Project Page, import the CSS above the HTML, and import the Javascript as the last possible tag in your HTML. This is really important, and should look something like this:

<!DOCTYPE html>
    <html lang="en">
    <head>
        ...
    </head>
    <body>
        ...
    </body>
    <script src="js/datalist.polyfill.min.js"></script>
</html>

And that’s it! It’s not identical, and doesn’t have a button to see all options like Chrome does (or clicking twice, like in Firefox), but it’s still pretty great:

And there we have it, some pretty straightforward HTML, CSS and Javascript to implement the amazing dropdown alternatives outlined in Zoltan’s article! Never again will you invoke your users wrath when they’re forced to scroll through 184 countries to find United Kingdom, or overshoot Australia and end up clicking on Belgium!

If you liked this post, please click the ❤ button to let your followers know, or let me know your thoughts below or on Twitter @padams02.

<a href="https://medium.com/media/b85dfbb5286d8a25cf2e754b9462cf45/href">https://medium.com/media/b85dfbb5286d8a25cf2e754b9462cf45/href</a>

Implementing Dropdown Alternatives was originally published in prototypr on Medium, where people are continuing the conversation by highlighting and responding to this story.

Implementing Dropdown Alternatives

Cool stuff, every week

More Articles