I made a tool for my students, so they can slowdown music and learn it in their own tempo.

In the tools there are some knobs, and specifically 3 of them interact to a "loop" functionality. The idea is to have 2 knobs delimiting the start and end of the loop, and the other one the player position that will reposition (go back) when the loop range is reached.

enter image description here

My question is: where in the shape of a knob should the "point of coordinate" be?

For example, in the image under I used the "center" of the knob as the point to measure distances, this makes the knobs go over each other and reduces touch area,

If the "point of coordinate" would be the inner side of each knob relative to each other, where should I position the playing knob?

enter image description here

  • Perhaps try a line or arrow where the selected "postion" is not based on the center of the knob but rather based on the Edge. Something like >| The line is thin and represents the exakt postion. The arrow is for better distringlishing start and end. ----->|----|<-- you can clearly see what part is selected – BlueWizard Dec 5 '16 at 10:25

In physical world we have caliper, which is a great example of Selection and Measure tool. You can use close approach, and it seems it solves your problem. Time indication increases usability, and the large controls are good as touch targets. While swiping, you need to display the numbers over the control to make these visible.

enter image description here


As Jonas Dralle suggested, we need no two bars. And Andrew Martin's suggestion on the alignment was accounted, too.

enter image description here

  • 2
    This could still result in an overlap - perhaps if one was below the line? Or maybe if the pointers were aligned with the right edge on the left slider and the left edge on the right slider? – Andrew Martin Dec 9 '16 at 16:27
  • 1
    Why even have two bars for this? – BlueWizard Dec 12 '16 at 13:53
  • @JonasDralle t's true, we need no two bars. Thank you. – Alexey Kolchenko Dec 16 '16 at 13:05

I implemented something similar a while ago. What worked best for me was to consider the inside edge of the knob as the coordinate for defining the range.

enter image description here

The problem with this approach was that I could no longer select the entire range.

enter image description here

I solved that by adding a fake visual padding to the sides of the tracking bar. those regions were colored the exact way as the bar, so you would not notice them.

enter image description here

The current time can then be shown between the two knobs with a vertical line.

enter image description here

This trick allowed me to define some generous interaction zones inside the bounds of the component. The entire knob is actually the dragging zone.


iMovie handles this very well. Instead of using two separate "thumbs" on the timeline, it uses a simple box where each end is draggable:

iMovie loop play UI

The box is an excellent choice because: 1. The left and right sides of the box are vertical lines that don't take up any horizontal space, so the "point of coordinate" is implicit. 2. The top and bottom sides of the box clearly show the extent of the loop.

The current position of the "playhead" is indicated with a separate vertical line with a draggable triangle at its top. Separate buttons are provided for Play/Pause and for moving the playhead to the start or end of the loop.

To move the start and end of the loop, the user simply drags the ends of the box:

enter image description here

A nice touch here is that you can actually drag the Start side of the box to the right of the End side of the box, whereupon it becomes the new End (or vice-versa). This is a great way for the user to advance through the piece, as they can always just drag the Start to the right (past the current End) and know that the new Start (the previous End) will start exactly where they left off before!

So the answer is:

Don't use a slider with "knobs" that overlap the timeline due to their horizontal width. Instead indicate positions with vertical lines that can be dragged, such as the sides of iMovie's selection box.


I will refer to the loop start and end controls "sliders", and since they perform similar but different functions:

  • Give the sliders similar but different shapes

Since time between them is more important than the time outside them (since the play time marker will be inside):

  • Prefer occluding parts of the timeline (if you must at all) that will not be played over parts that will be played.

...and since those asymmetric sliders stop covering the timeline in their inside edges:

  • The loop sliders' inside edges should be their time reference points.

Going a bit further...

For the play time marker, even without loop start and stop markers it would be best not to occlude the timeline (to allow for the marker indicating the start and end of the timeline, and just for precision), but because of your loop start and finish sliders it is even more worth the effort to do it, so:

  • Have a play time marker that is zero- or near-zero-width (line width) on the timeline...which leaves above or below

So that would leave something like this:


The point of coordinate should be in the center in the rectangular knob you are proposing. To select an specific point and see through the loop process (while playing) you need precision. And this is a good reason why those knobs are not working correctly for the looping function.

Some kind of knob that lets you do the same action but without interfering with the position they are indicating would be a good solution. Something similar to the way you can select text in Android:


Note in this example the knobs are disposed indicating where the selection starts and where it ends. But this is just an "extra" nice thing, the idea I mena is to keep the UI the user interacts with outside of the place where its getting the result.

If the knobs are meant to be over the player at least keep them minimal not to interfer with the player knob. Also in a shape that indicates easily the exact point (rather than a rectangle where the point could be interpreted to be in the center or in the sides.)

  • 1
    Thank you for your answer. You suggest "The point of coordinate should be in the center", but the image you suggest has the "point of coordinate" in the inner side, and not in the center of the knob right? – Sergio Dec 5 '16 at 9:29
  • 1
    "should be in the center, in the rectangular knob you are proposing". If the shape of the knob would have some kind of pointer then where it points is the "center" but in a rectangular shape it is in the center I believe. – Alvaro Dec 5 '16 at 9:36

Keep Your Coordinate Centered

Yes! You absolutely should make the center of the knob the coordinate. You actually want to change the path that knob can travel, not the knob itself!

Simply shift the path the knob travels by half a knob width to the right (persumably by adding to the x-pos), and subtract an entire knobs width from the lenth the knob would otherwise travel (perhaps subtracting from the knobs x axis length). What your doing here is shaving off half a knob's width from each end of the knob's travel path! This results in a path of travel that doesnt overlap, and uses the full amount of space:

enter image description here

This also applies to the dual knob scenario, where instead of each knob's path of travel intesecting, they instead stop short of the other:

enter image description here

In this example you can see much easier the path of travel end-to-end.

I hope this all makes sense, I just deleted my users directory earlier today, and as such previously answered in a way that could have lead you astray.

  • 2
    Thank you for your answer. In the last scenario, where you write "no gap = no loop", having the coordinate in the middle gives me the impression that there is a gap, between the green points (center of each knob). How would the "player knob" behave in such case? loop between the green points (the centers) in your image, or use the sides of the knob as coordinate point and so not move (be trapped inside a "no gap" scenario)? – Sergio Dec 5 '16 at 9:28
  • I see your point. In the second scenario, there are 2 knobs, the total redline (path of travel) would be the equivalent of the total track length. So where one leaves off, the other picks up. The gap then does not exist. However, I'm gaining the impression that this may be different than I expected in the end, and perhaps my former answer would work. Quick question: does this coordinate that you speak of, does it absolutely matter where it is on the slide bar? – Leviscus Tempris Dec 5 '16 at 9:41
  • And in a no-gap scenario, I would add a check for the gap, and if it's too small, just disable looping until it is brought back to a reasonable length of playback. – Leviscus Tempris Dec 5 '16 at 9:42
  • 2
    The "no gap" image shows the flaw in this suggestion: if the controls are centered, it's not possible to have no gap (other than by overlapping the controls themselves, which is obviously a bad idea.) Papering over this problem by changing the functionality (oh, if the loop is too short for this UI to represent it, just disable looping) gets it backwards: functionality should drive UI, not the other way around. – Daniel Beck Dec 5 '16 at 16:53
  • 1
    Your first edit(s) look just as self-contradictory as your current one, as far as I can tell. It looks like you initially suggested having the control point move within the slider as it moves along the bar -- if the knob is hard left, in the slider its control is at its left edge; hard right, at its right edge; centered when the knob is centered in the range. But that doesn't solve the two-slider issue at all, it just makes the math more complex. – Daniel Beck Dec 8 '16 at 19:38

Don't put the "reference point" in the middle of the virtual knob unless you make the knobs transparent with vertical lines, like slide-rule cursors:

enter image description here

...or treat them like brackets, as Ovidiu suggests.


enter image description here

See Audacity's intuitive example.

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.