If you tap the button it shows the progress bar, and you can drag the knob to wherever you want. But the next time you open the panel, the knob will always coincide with the current value in the progress bar, meaning that if you're at 0% brightness, you can only go to the right.

It may seem strange at first because we're not used to this type of behavior, but if you simply focus on your intent to slide the button to the left or right to get decreased or increased brightness, I think it feels natural.

I also created the whole keyboard and MacBook Pro in Framer. This was because I wanted to train drawing things using code and to get a bit more acquainted with classes, so it was the perfect situation.

7 Comments

Jordan Robert Dobson

Mind if I post this on #FramerCode ?

Sam Pattnaik

This looks great!!

Saurabh Kumar Suman

This is cool!

Brian Williams

Limits the position of the sliders somewhat but otherwise good ux

Koen Bok

Ha, I was waiting for the first Touch Bar prototype. Well done!

Trevor Coleman

That's interesting. I wonder if you're throwing the baby out with the bathwater a bit. Human memory is spatial, so when the slider moves, you're sort of altering the metaphorical reality of the slider, which is why you need to 'get used to it' and think about the gesture rather than simply completing the task.

Maybe think about replacing the slider with a dial (like the ones that open and close vents in cars) because they abstract the position of the control and focus on movement left/right.

You would keep the efficiency of the movement (which is a big plus if the touchbar) and you'd still be able to take advantage of the user's spatial memory.

It's a really slick prototype, and raises a bunch of interesting questions and possibilities.

Marc Krenn

From what I've seen, these buttons DO work like this when being held + dragged – which makes total sense – but instead of moving the slider around, Apple decided to always keep the slider in the same position and to use some weird offset-scrubbing instead.