11

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: Slowerd

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:

enter image description here

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!

  • 1
    +1 for tortoise & hare! I like Tal's addition of center line. Kitanga makes a good point about some users wanting precise control. If your users are video editors who need to speed/slow a video with frame-level precision, then an input box is easy & a slider is a pain. Can they use 7.24x exactly w/o dropping frames? Or must they choose from a set of fractional options (0.25, 0.5, 1, 2, etc) for technical reasons? If users are merely speeding/slowing cute/funny videos to share, the numbers are less relevant & tortoise/hare is fine because they only care generally what the end result looks like. – mc01 Nov 29 '17 at 23:58
  • 1
    Just wondering why I would want to slow up or down, and came to the conclusion that I might need to fit the video into a certain time duration. In this case, I am not interested in the speed-up factor, but the total duration (and the speed-up should be calculated). So - is there a "final duration" entry somewhere as well? – virtualnobi Nov 30 '17 at 6:37
  • "7.4x" seems a pretty precise value. This makes me wonder if a slider is the best solution you can use on mobile. Please read this: nngroup.com/articles/gui-slider-controls. – Madalina Taina Dec 2 '17 at 10:52
  • @roi-mulia I'm not sure I understand. The slider has only positive values that you interpret as "slow" and "fast" or it has negative values (7 times slower) and positive values (7 times faster)? – Madalina Taina Dec 2 '17 at 13:40
  • @MadalinaTaina So basically I didn't want to use negative values. As negative doesn't necessary translates to slow. So as a compromise I've used a prefix "slower"/"faster" and keeping the values positive, so if he drags left or right from the center baseline, it'll change to "faster"/"slower" but will keep the values positive. What do you think? – Roi Mulia Dec 2 '17 at 14:59
14
+100

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. enter image description here

  • 1
    This is good because it makes the midpoint as the scale's "neutral" point explicit. – Luke Smith Nov 27 '17 at 1:52
  • Hey Tal (Shalom :) . I really like the middle point, as it's give clearer understanding about the slower/faster phase. One question, isn't the current speed label should be consistently available? Or in your opinion the end result is more important, so the speed information shouldn't be visible at all time? – Roi Mulia Nov 28 '17 at 10:32
  • 1
    Hi Roi, It depends on what the aim of your app. In my opinion, If your aim is to give exact speed indication, then the speed label should be constantly available. But it the aim of the app is just to help the user set the speed up or down, then it will be best to hide the speed indicator because leaving the speed indicator open reduces the esthetic of the slider. – Tal Yaron Nov 29 '17 at 16:03
  • Agreed. You posted what I was going to suggest. It needs a baseline default. – Jim Ryan Nov 30 '17 at 16:31
  • Hey Tal. I think you are correct, actual I need to check what would my user base prefer, it's a bit tricky. Small question. I've checked on slider labels location best practices, and I've seen in numerous places that it's when designing for mobile, it's better to place the labels above the slider, so when dragging the thumb, the finger won't hide them. You can it could work in our case as well? Or it's more appropriate to place them down? Would love to hear your thoughts – Roi Mulia Dec 2 '17 at 13:40
7

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: Corrected UI slider

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): detailed user slider (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:

slider two, improved for those who want to quickly set the speed

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

  • First being VLC (v2.2.4):

vlc video speed slider

  • 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

Youtube video speed selector buttons

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.

  • 2
    Good point about different potential users/use-cases. Depends on who his users are & what the point of the app is. If I'm trying to use the app for a professional production, the slider is frustrating & imprecise. If I'm a kid recording silly faces to share w/friends, I don't care about the numbers at all. – mc01 Nov 30 '17 at 0:01
  • @mc01 yep that's it. But quite curious though. Vinay's answer brought up an interesting point, the YouTube speed selection tool has the numbers decreasing going down, which is confusing. But there are no complaints that I could find. But it makes sense that someone would find that weird or confusing – Kitanga Nday Nov 30 '17 at 17:11
  • 1
    Hey Kitanga, thank you for responding! Great point about the tortoise direction! The user base doesn't need an exact value, it's more about dragging the slider and looking at the output directly, but you had some great points, Thank you! – Roi Mulia Dec 2 '17 at 14:53
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.

  • Hey Pectoralis, thank you for replying! I do agree that it's different from the iOS UI guidelines, altho if you think about it, there is small yet pretty big different with the behavior if what I'm trying to achieve and what iOS does. When, for example, setting the Brightness level on iPhone. There is a different in the connotation between low brightness and high brightness, on purpose (on my opinion). Yet, when choosing fast/slow speed, I have no interest with showing one of them in more positive light than the other. I like your ideas, can you attach a UI Sketch? so I can see what you meant? – Roi Mulia Nov 23 '17 at 17:20
3

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: enter image description here

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.

  • 1
    Hey Vinay, thank you for responding! I wonder if for the "slow" values, (the values to the left), should be used with fractions or with the same values of the right, and some how make it clearer that right is fast and left is slow. so for example, instead of using 0.5 on the left side, we'll use 1.5 (slower) or something else. People will react better to complete values rather than fractions, because there is no 0 value, and if you'll look at the slider it'll look like it's going from 0 to 2 (it's -16x slower to +16x faster basically) – Roi Mulia Nov 28 '17 at 9:46
  • That part about the YouTube video speed selectors not being liked, can you please reference any source that confirms that. I searched for it, but found nothing. Actually what I found was the opposite: there were more posts about it coming to mobile (which sounds to me like people are excited about it) – Kitanga Nday Nov 29 '17 at 21:23
  • I do agree with the input box being a little too much. I guess that's more of a preference on my end. – Kitanga Nday Nov 29 '17 at 21:27
  • Roi, I agree.. decimal numbers may not be the preferred once, but since they have been used on websites like youtube, there might be a few people who would know it, but none the less, its better we have whole numbers with a good range from negative to positive side. Cheers. – Vinay Dec 1 '17 at 4:49
3

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.

enter image description here

(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.

enter image description here

(End of edit)

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

enter image description here

(End of edit)

  • 2
    I think this problem can be solved if (1) the design shows all relevant information ABOVE the slider line (because the fingers obscure everything below their point of touch) and (2) once the current position is touched, only the horizontal component of the finger movement is taken into account (so the user may slide down a little to make the entire control visible). – virtualnobi Nov 30 '17 at 6:35
  • I like this, but would maybe consider having both a functional slider and the buttons, just to allow users to get "in the ballpark" of their desired speed, and/or then fine-tune with the buttons if they choose. If I have to start at midline "1x" and hold a button for a long time to get to 16x I'll be frustrated that I couldn't just swipe all the way over to start with. Aside from that quibble, great solution! – mc01 Dec 1 '17 at 2:29
  • Yeah I agree mc01. I was thinking about combining buttons with a slider too. I think adding buttons makes the controls much better and may solve that issue. I posted an update. Let me know what you think. Thanks! – moot Dec 1 '17 at 6:41
  • Hey moot, Thank you for responding! The only issue I have with your great designs is that the video is not visible during the process, and I think it's super critical to show an immediate feedback to the user of the speed changes. I agree about the slider issue, but unfortunately when most the the vertical space is being used to show the video, we left with very small space to place the UI manipulation component. So we kind of left out with a slider to supply all our needs. If the app wasn't focused on speed editing, I think your solution works best. – Roi Mulia Dec 2 '17 at 12:02
  • 1
    Thanks Roi. Yeah I didn't know how you were going to use the control. I posted an example of the control with a video player display on the card. I know this may not be a fit with your project at all though. No worries at all. This stuff is fun. – moot Dec 2 '17 at 12:51
1

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:

enter image description here

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.

enter image description here

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: enter image description here

Photoshop: enter image description here

Blender: enter image description here

Premiere: enter image description here

Protools + Video enter image description here

  • Hey Devin! Thank you for the detailed answer. One of the most detailed answers, I highly appreciate this. I think your solution is great, but as you said, the solution should match the user base. In this case the user base is usually elder people that understand how to use their iPhone, but has no idea about video editing, and all they want is to speed down/up the video. Unfortunately we can assume they have no clue about FPS or how it's effect the final outcome. The way the test the result is by actually looking at the video and see if it fits them. For more advanced users your solution – Roi Mulia Dec 2 '17 at 11:54
  • will work seamlessly! thank you for your respond :) – Roi Mulia Dec 2 '17 at 11:54
  • @RoiMulia, then you should use my first example. The key for the slider is NOT to offer variable amounts, but to use stops with fixed values like -16x....-4x,-3x,-2x,-1x,0,1,2,3,4........16x This way users will know exactly what will happen when they slide. Maybe 16 would be too much, but you'll need to test that out – Devin Dec 2 '17 at 17:41
1

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.

  • So basically I didn't want to use negative values. As negative doesn't necessary translates to slow. So as a compromise I've used a prefix "slower"/"faster" and keeping the values positive, so if he drags left or right from the center baseline, it'll change to "faster"/"slower" but will keep the values positive. What do you think? – Roi Mulia Dec 2 '17 at 15:00
  • So, mathematically speaking, you have a default value and this can be transformed into a new one that will be smaller or bigger (slower or faster), isn't it? This is true, slower is not a negative value. In this case, the track should be filled from the center, showing that the default value is located in the middle. – Madalina Taina Dec 2 '17 at 15:14
  • Exactly, that's was my initial assumption. Now I am wondering if the labels (Slow/Normal/Fast) should be located below the slider or above it. What are your thoughts? – Roi Mulia Dec 2 '17 at 16:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.