# Logarithmic and/or linear scale sliders when to use them

I've been having a discussion with someone at work regarding the usage of Logarithmic and linear scale sliders. Here is an example in a jsfiddle*.

## Background of the problem

We are currently building something that allows consumers to compare sim only plans. In Holland you have data plans that can range from 250 MB to an unlimited data plan.

I've made a quick example on how the slider is used, the user can slide to select a minimum amount of data/min. The largest option before 'Unlimited' (in the example 'Onbeperkt') is 20.000 MB.

## Discussion

The discussion revolves around what scale we should use. I say a Logarithmic scale else user needs to drag a lot before the 'average' data plan can be selected (the amount between each step increases, so first it is a step of 250 MB -> 500 MB and later it turns to 1000 MB and 5000 MB).

The developer believes using a linear scale is better, with a step of 500 MB. His reasoning is that a logarithmic scale defeats the whole purpose of a slider. I do understand his reasoning, I however find a logarithmic scale to work better as it reduces the amount of steps.

### My question

Is there a rule of thumb or a general principle regarding the use of linear/logarithmic scaled sliders.

### Extra information

As asked in the comment of John, it in our live version it is indeed not possible to select 3452. We are using 'steps' already, for lack of a better word I used linear and logarithmic. I mean that at the linear slider the steps remain 500 and at the 'logarithmic' slider the step size increases as the value gets higher (initial 250 and later it becomes steps of 500, 1000 and 5000).

### Translation to English

• Belbundel = Amount of minutes
• Databundel = Dataplan
• Onbeperkt = Unlimited

*The fiddle works on my computer, but that can be because of cookies. So if the fiddle does not work, I use the bootstrap slider of seiyria. Examples 1 and 15 show linear and logarithmic respectively.

• Can the user select any value? For example, 3452 MB? I don't think packages allow this. They rather come in specific values. So, neither neither logarithmic nor linear. You need a slider that allows steps Commented Oct 10, 2018 at 0:32
• It is impossible to select 3452, the steps increase in size when the selected value gets higher. That is why I called it a logarithmic scale, the jsfiddle does not reflect this indeed. I will edit my question. Commented Oct 10, 2018 at 7:44
• Not familiar with jsfiddle. You need something that allows predefined values. So, I don't think log/lin scales is what you are looking for unless jsfiddle allows you to load predefined values Commented Oct 10, 2018 at 16:13

That's a very intriguing challenge you are facing. I must say I had a similar issue to solve recently which I did the way described below.

To answer your question - it depends on the nature of data you are selecting and the users' needs - as presented in https://ux.stackexchange.com/a/121406/98561

Whether you should use linear or logarithmic scale for your data I'd say neither of those. And this is why:

You are not presenting any actual data with the sliders but you are simply giving the user some choices. Those happen to be ordered (smallest to largest, left to right) and the exact value is presented above.
Hence, it is not needed to show that 2000MB is twice as much as 1000MB, or that 250MB is only a quarter of 1000MB

I believe the most convenient for you will be using fixed values for the stops, like

[0; 100; 250; 500; 1000; 2000; 5000; 10000; 20000; ∞]

If you'd like to have a linear slider, there would be a lot of stops placed dense in the beginning and only a few stops further on. Following your developer's point of view would results in selected values of eg. 6500MB and making 100 and 250 unreachable (should those be requested).

Now, using a logarithmic slider with fixed stops would space the stops more evenly although not quite even.

The best solution, in my opinion, would be to follow the KISS rule and simply make a slider with {number of items in fixed values array} stops spread evenly and label them accordingly.
And if higher granularity is required simply add more stops with respective values.

I can think of a specific use case when a logarithmic scale is essential.

I worked on a timer scale for a system and our research uncovered that although the times needed ranged from 10 seconds to 10 minutes the users tended to place most accuracy for the timer in the 10 sec to 2 min region but not much accuracy outside that.

In other words, if they were to set the timer over two minutes it would be 2:30 or 3 mins or 5 mins or 7 mins, but if they were to set the timer under two mins they wanted more accuracy e.g. 1:10 1:20 1:30 etc

We made the scale logarithmic so most of it covered the 10 secs to 2 min region and the rest up to 10 mins region.

Summary: research will tell you how users interact with a scale and when they need accuracy vs expediency to 'a value'

## Consistency first

When it comes to data-visualization, there are two reasons to use a logarithmic scale:

Respond to skewness towards large values, eg: cases in which one or a few points are much larger than the bulk of the data.

Show percent change or multiplicative factors.

These principles apply mainly to information restitution components such as charts, speedometter in certain cases, etc.

For components that require user interaction such as a slider, think about consistency first. Your reasoning on the use of a logarithmic scale makes a lot of sense in terms of restitution but I don't think users are used to this logic of incrementing a value. Consistent design is intuitive design ; usability and learnability improve when similar elements have consistent look and function in similar way.

If you really do want to implement a logarithmic scale, I strongly recommand you to display explicitly all steps.

Source