Minimum Maximum slider - Usability best practice

Question

I'm developing an iOS mobile app for slowing down/speeding up videos. After some research and intuition I've decided to choose a Slider as the responsible UI component for the video speed change. The video speed range is between 16x slower to 16x fast than original speed.

Naturally, the left-most side of the Slider should be the slowest, and the right-most side should be the fastest.

I've noticed something interesting when using the standard Slider of iOS: When the thumb starts from the left-most side (minimum value), and the maximum value is on the far right, it gives a "bad" connotation to the left side, and a positive connotation to the right side. Plus, it was a bit confusing whether I'm on the slowed-down part or the sped up part.

Example:

Then I decided to change things a bit, and place the origin of the Slider at the center. The center stands for "original speed". Dragging left will focus only on slowing down, where dragging right focus on speeding up. Same example above with the new version:

I feel like it's still lacking in usability. Maybe adding indicators next to the center origin? Would love to hear your thoughts and ideas. Thank you for reading!

Answer 1

I think your UI is quite clear, and will not cause any misunderstanding with the user. You may make it more aesthetic, by lowering the number of elements in the UI. This UI may be cleaner and clear enough.With this UI, the number will be seen only when pressing the button or draging the button.

Answer 2

EDIT: Scrap the input box, @vinay is right. It would just make the whole thing more complex. So it will end up looking like this:

OK, before I share what I think you should do, I think it's best I remind you that there are two types of users you'll run into when you create a tool like this: those who will want to input an exact value and those who just want to slow/speed-up the video as quickly as possible. You need to remember to try and cater to the demands of these two types of users.

To cater to the former, you'd do what you did (i.e. a slider, but with a slight tweak: you add an input box. DON'T USE THE INPUT BOX): (I know, the input says 0.0x when it's actually 7.24x slower). Personally, I don't vouch for this method because of the methods explained below.

Now, for the latter (those who want to just speed up or slow down the video as quickly as possible) you can add action buttons that jump the slider to the corresponding position:

Here are some examples of tools/software that use this method:

• First being VLC (v2.2.4):

• And the other being YouTube (PC). YouTube, actually, doesn't have any sort of method for a user to input the value they want. It just places a bunch of defaults and that works

And one other thing, please make the tortoise face to the right (check the image above of buttons+slider+input example). Since the video is still moving forward, I think the tortoise should face the right to (hopefully) subconsciously communicate to the user that you are slowing down the video and not rewinding. I know it sounds small, but I feel it should be this way. Of course this is up to you.

Also I removed the "7.24x Slower", since a user will be able to understand that if a video is moving below 1.0x speed then it is moving at a speed slower. But then again, that reasoning is challenged by the YouTube example above (it uses the word "Normal" instead of 1.0x/1x which could suggest that users didn't get it during testing). At the end of the day, again, it's all up to you.

Answer 3

Maybe you insist on using those two icons to much (i like them btw.)

The iOS UI is using the far left as the original point and the more you move to the right the more you increase whatever value.

Since most users know the layout from the top they might get confused when using your version since you use the middle as the origin.

I think if you add "Original speed" to the middle on the same height as the other two labels it will get more clear from where the users is modifying.

Also consider adding an option which let the user reset the value to "Original speed" because i think it can be quiet hard to hit the middle on the first try.

Answer 4

FYR, here are some of the best ux practices related to video as provided by yhe Neilsen Norman group.

https://www.nngroup.com/articles/video-usability/

And imho and from my observations, the youtube selections for speed has been confusing for the users. Users generally think that the values above the NORMAL level increases the speed and values below the NORMAL level decreases. This as you observe from the image provided, needs a little more attention from the user to realise that it works the other way round. So I would suggest you go ahead with the slider having the values to which the user can fix the speed easily. Also, you can use the click/tap on NORMAL value to allow the user to reset the speed back to normal.

Here is how I would design it:

And I would not give a input box here, it would just be an extra effort for the user to understand the range within which the value is to be input, that would just complicate it.

Answer 5

I think the main issue is using a scrub bar in a touch interface.

Scrub bars and are great inputs for the mouse but terrible for touch. The horizontal line may be the most awkward common thumb movement possible when holding a phone. Try drawing a horizontal line with your thumb on your phone. To do horizontal lines, most users have to physically change their grip on the device. Plus you can’t see what you’re touching.

(Edit - I forgot to include this point) Scrub bars and sliders have very little precision in touch. If the input is only a few points per inch, a slider is easy to use. The range for this application is at least 32 and the question is showing decimal precision. Tapping and holding are much easier to do than control a slider. (End of edit)

You should use buttons. They should be designed and positioned to be easily recognizable and use. User’s can tap or hold the buttons - tap to step - hold to scrub.

When a user is touching a screen to interact, the user covers the screen. So the buttons have to be below or to the side of anything the user needs to see while using the buttons. Users should be able to scroll the card into a reachable position (move the card up and down). If the buttons are static in position, put them at the bottom for easy reach with thumbs.

(Edit - updated the design) As mc01 pointed out, it would take too much time and effort for the user to tap or hold through large changes. I've added buttons to make it faster and easier to change the number.

(End of edit)

(Edit - updated the design) Updated the design to show a video player display added to the card.

(End of edit)

Answer 6

I think you're correct when you place the origin at the center. Basically, you're setting a baseline value from which you can go up and/or down.

However, the baseline is merely symbolic, since you can say it is 1 (and ... 1 what?), 0 or normal, as other answers say. Therefore, this is not a real measure, but a reference for relative magnitudes.

On this basis, the important thing is the audience you're targeting. For example, for a common user (as I would be), knowing that the video will be 3 times faster or slower will surely be enough.

However, for more sophisticated users, it's going to be confusing. What is the baseline? 24FPS? 30 FPS? any FPS that the video player identifies? And on top of that we have to add fractional magnitudes:

7.8x * (x FPS) = ????? .

The problem is clear: the user will surely know what speed she needs, because she's used to that. But doing it this way means adding a great level of friction.

Then, again: if your application is for ordinary users, the use of magnitudes relative to a symbolic baseline may not be a problem (however, you must test it). For specialized users, it is not a good idea, because it will be very imprecise and the user will have to take out accounts.

For all this, I think my recommendation would be that you first define who your user base is (I suppose you already did it, of course!) And then apply the best option, that of common users or more sophisticated users.

Regarding the choice of common users, you should also consider how to represent the direction. If 0 does not make sense as a baseline and you use 1, it will bring other considerations to the table, see below:

IN the first case, baseline is 1. So, 2x should be... half of the time? Quick math tells me that

1*-2x= -1 .

Also... how do you translate -2x to 0.5 in users mind? It's really counterintuitive (let alone something as -7.8x. I'd spend hours trying to figure what speed is that!)

So you can see second case: it start from 1 on load, in the middle of the screen. But the line starts at 0, then 0.1, 0.2, 0.3 and so on. This is a very clear method: 0 is no speed, 0.1 is 1/10 a, 0.2 is 2/10 and so on. But well, having 1/16 would make it really confusing, not to mention 0.5 is not the negative value of 2x which would be its counterpart in a number line. However, if you're OK with going from 0 to 1 and then to 2, this would be perfect.... but I guess you need to go to 16x rather than 2x. You could use a logarithmic scale for faster than baseline measures, but again: you'll need to test this out.

Getting to a solution

In summary, most representations are inaccurate or confusing. Then, a proposal that could solve all these conflicts of visualization of the information for both common and specialized users would be the use of absolute scales of frame rate per second (FPS).

This way, your app could read the FPS of the video source and define the baseline from there, then it could offer different FPS values. In my opinion, better than using a slider is to use a series of preset values, but if you want to use a slider, no problem, it would work too. Of course, this is in the case that users can upload videos, otherwise you can add the base line artificially with the frame rate that your app uses. See examples below:

Foundry:

Photoshop:

Blender:

Premiere:

Protools + Video

Answer 7

As I said in my comments, I'm not sure if this slider has only positive values (or bigger values) that you interpret as "slow" and "fast" or it has negative values (7 times slower) and positive values (7 times faster).

Case 1 (the slider has only positive/ bigger values): In this case, I don't see any reason to have the label "slower" (7.24x Slower). This is actually the element that gives a negative connotation to the small values. Also, in this situation, only the selected range on the track should be filled and the default value should be 0.

Case 2 (the slider has negative and positive values (or smaller and biggest values) - 7.24x slower and 7.24x faster): In this case, the track should be filled from the center, showing that the default value is located in the middle.