I use audio software a lot, and it is amazing how something which seems quite simple in concept, such as a circular volume button, can be so differently implemented via UX.
Every time I see a knob style button on any of my audio plugins UI, I have to think:
* Will the point at which I touch/click on the knob set the knob value to that position, or will it simply be the starting anchor at which I start moving the knob?
* Does this knob work by sliding up/down or in a circular fashion? Or accept both ways?
* How far away, or close to the centre, is the active 'hot spot' that allow me to control this knob?
* Does the knob dynamically display the value as I spin it? If so, where does it show that value and am I inadvertently blocking the display with my finger/cursor?
* Does the knob have the concept of velocity, whereby I can quickly spin it to the approximate value I want, then make tiny incremental adjustments to get the sound 'just right'?
All these tend to break the "don't think, just do" concept of a skeuomorphic interface.
Don't forget, is it linear or logarithmic? It baffles me that it's 2017 and people who implement volume sliders never even consider that the obvious choice might not be the best...
Well logarithmic doesn't make sense, because it never gets to zero. However something like p^0.42 (sound pressure with an exponent<1) works well because it is similar to the perceived sound level. An interesting connection is that the power function "becomes" a logarithm as the exponent goes to zero.
Log/lin depends on your target market a lot I think. I don't know, but I imagine, audio engineers and the like would be expecting a logarithmic scale for their volume knobs.
I make guitar pedals sometimes, I've never seen a volume knob not be a logarithmic potentiometer.
I don't know if it's a bug with Windows or my headset, but my headset actually does make sound at 0 on windows. I get an extra button press on my headset volume controls or my keyboard volume controls to actually mute it.
Volume is a percentage, and a very analog control. The idea that you would have to have a round knob to twist on a computer screen is ridiculous, almost like some imaginary need for a specific shutter button to press to take a photo on a phone (just touch the screen!).
It's a one-dimensional value, make it a one-dimensional control. Slider. Done.
> almost like some imaginary need for a specific shutter button to press to take a photo on a phone (just touch the screen!).
I've always wanted a shutter button on my phone, because of what it would imply: the ability to take a picture instantaneously, as the first action that wakes the phone from sleep. I often miss shots because of the six seconds required to get from my phone being in my pocket to having the Camera app open.
Certainly a better way, but my gripe above is not just with volume buttons but with other things such as EQ, panning, time delays and a million other things that audio software can control.
I am guessing that screen UX designers wrestle with the same constraints that physical audio hardware manufacturers to - that of space restriction, and cramming as much as they can into a given space.
Hence I guess why things like recording consoles have a slider for the critical volume adjustments, but rotating knobs for other things like panning, EQ etc. above that.
Volume is one thing I don't mind seeing as a vertical slider, but then would panning be a horizontal slider? I actually prefer a round knob for that because the knob position is a better resemblance of the 360deg sensory perception around my head when setting the stereo space.
Albeit a true 2D control surface works much better. (A control rectangle which is a cross product of two sliders.) Pan cannot give you 2D positioning, even when combined with loudness or approximation thereof.
Especially since screen tapping could be registering a "refocus to this point" action. Also since camera phones have no viewfinder, I use the screen to compose my shot. So to avoid obscuring what I am going to take a picture of, I keep my hand clear of the screen most of the time. That makes the act of triggering the shutter a more visible and deliberate act than just pushing a button that my finger is already touching. These probably don't matter to most people but are fairly frustrating to me. (the fact that I almost always shoot landscape, not portrait, may be the cause of the discomfort for me, since it changes my hold on my phone to something more like the hold on a camera.)
With most sensors having a 4:3 aspect ratio and smartphone displays having a 16:9 (or wider) AR, there is no need to block the image being composed with any fingers. The blank areas are filled with all relevant controls and a virtual shutter release button.
I don't believe the parent meant a physical shutter button, but a specific area on screen designated as the shutter button instead of the much easier, "anywhere".
In landscape orientation, stock Android "helpfully" keeps the shutter button on the right side of the screen at all times even if you rotate it. Because left-handed people never take photos. -_-
On many (most?) phones, the volume buttons act as a physical shutter button. I don't recall the last phone I saw which doesn't have this feature. iPhone, various android phones...
Or a UI control mimicking an old-style rotary dial in a phone app. (Although to be fair, the rotary dial in old phones was terrible UX brought about by a purely technical design decision - on the other hand a physical volume dial in a real amplifier is a pretty intuitive control.)
A thought: have you ever seen a knob that actually turns by doing a two-fingered rotation gesture on a trackpad while hovered over it? I think that's the only skeuomorphic knob I'd actually be happy with.
That is another UX quandary. A lot of the problems I mentioned in my OP would go away if everyone used the standard two finger twist gesture on the screen to 'turn' it up or down.
However, if I try and use thumb and forefinger as normal, I cannot get my thumb especially to stay in skin contact with the screen easily - the nail comes into play, losing the double touch on the screen.
Using forefinger and middle finger together works better, but makes twisting past a 180 degree turn very difficult.
By far, the better solution is the car audio control I posted elsewhere in this thread, which uses multiple finger PLUS slide gestures - but that UI can take up the whole screen just to manipulate a single parameter.
Skeuomorphic interfaces should just be banned forever. What is so wrong about simple numerical input? Not cool enough? Want a darn analog VU meter to go with it?
If you are working with audio a lot, then most of the time, the numbers are meaningless, and you are going by 'feel' and using your ears as the sensory feedback mechanism.
Can you tell me how many dB's you need to set your volume at in your office environment in order to be able to hear above the background hubbub? At home? In the car? That sort of thing changes from day to day and situation to situation.
Very often when I plug in my guitar into my amp, I will twiddle the knobs without even looking at the respective numbers. I just know that I have to adjust the bass, middle or treble EQ to suit the room, and will do so without looking. Often if I get a setting that sounds really sweet, I will look at, and write down the settings for future reference, but it is all done after the fact.
The same goes for if I am using a software amp modelling sim on my PC or iPad etc. Twiddle while listening, then save the snapshot later if I am happy with it. I don't want a finicky interface to get in the way of my experimenting and twiddling.
And yes, VU meters are also extremely useful when recording etc. in order to get a real time view of peaks and spikes in an audio track. Ask anybody who uses a DAW regularly.
My personal favorite design, and I can't remember where I saw it used, was a scroll wheel centric version where you hover and scroll to adjust volume, with a bubble appearing above with current setting
I think it was on a UI portfolio. Not a production effort
Not sure how well it would work with a trackpad though. Worked great on a mouse with an obvious "tick" feedback in the scroll wheel though!
The funniest thing to me is that this was started by the very first gif in the article, which looked like a real thing and result of a simple coding error... and the top comment for that was "prepare yourself for a week of volume sliders", referring to that past Bad Phone Number Input fad.
That third "make a noise as loud as you want the volume to be" one would actually be a good idea, if it was a continuous feedback loop: I'd love if there was something I could enable that would make my headphone volume "track" the loudness of the room, the way that phone display backlights "track" the brightness of the room. Instead of setting a target carrier wattage (regular volume) or a target SPL (SoundCheck volume), you'd be setting a target SNR, and then the OS would maintain it by lowering the master gain in quiet places and raising it in noisy places.
Or, to put that another way: I'd like to be able to hear my music, but I don't want the people around me on the bus to be forced to listen to my music. Electric vehicles (like my local bus system) only make noise when they're moving; they're dead silent when they stop. So right now, I actually have to turn my music up several notches when the bus is moving, and then turn it back down several notches whenever it stops. Why is the phone not doing this for me?
(Heck, while it's at it, why not recognize nearby human speech specifically, and pause and/or duck the playing sound temporarily to let me hear it?)
In research environments we often have to use software with UIs designed by, and subsequently abandoned by engineers. Typically some expensive piece of highly complex equipment that only runs on some older version of Windows that every PhD student is expected to use. They're often buggy, resulting in Skinner pigeon troubleshooting workflows to get anything done.
First guilty party to mind is FLIR. Their software is truely awful and since they monopolise the market by buying out everyone else no two cameras behave the same.
Various CAD packages too are a design mess. PTC could learn an lot from Adobe about UI design. Heck, Blender's UI is miles ahead of anything from the big CAD companies for pure productivity, nevermind install size.
Fortunately my primary overpriced USB dongled bit of research equipment is pretty easy to hack. All the data types under the hood are simple text files that I've got python scripts for handling.
The worst offenders by far have to be National Instruments, entirely because they loosed LabView upon the world. LabView essentially makes it impossible to make UIs that aren't terrible. Most of the volume controls in these posts are more usable than the best that can be done with LabView.
I've managed to completely block NI from my mind. When I have to use their hardware (which is mostly good) I use pyVISA or the session based interface in Matlab.
Industry-specific software is also really bad for this. So is university software. Basically anything where the purchasers never use the software, so there's no real incentive to improve.
I've been hoping for a while now that digital assistants like Alexa and Google Assistant would implement that feature and respond in a volume similar to the one you asked your question in. That way you wouldn't have to be constantly messing with the volume to make sure you can hear the assistant without it being too loud.
On the other hand, if you're further from the device, it will hear you less loudly, while it should respond more loudly. Maybe it could distinguish speaking softly from speaking far away somehow.
I'd love to see the antithesis of this collection - whereby smart UI designers try and improve the current audio controls to move away from the old style knobs/sliders, to something far better represented by todays interfaces, such as this concept for a car audio control: https://www.youtube.com/watch?v=XVbuk3jizGM
I quite like the one with 100 hundred buttons. Often in slider style situations I know exactly what I want the value to be and just want to hit something with a mouse click. This can be faster sometimes.
One of those is basically the same as tilt to scroll, something that actually exists. Why anybody in the history of ever thought it was a good idea I'll likely never understand, though.
Argh, please don't. The source is linked in the post, but trying to pick them out of that Reddit thread is painful. I appreciate what you're saying, but the post serves as curated collection.
I'd prefer it if the author had attributed each one, but it's better than just dropping people into that thread.
I use audio software a lot, and it is amazing how something which seems quite simple in concept, such as a circular volume button, can be so differently implemented via UX.
Every time I see a knob style button on any of my audio plugins UI, I have to think:
* Will the point at which I touch/click on the knob set the knob value to that position, or will it simply be the starting anchor at which I start moving the knob?
* Does this knob work by sliding up/down or in a circular fashion? Or accept both ways?
* How far away, or close to the centre, is the active 'hot spot' that allow me to control this knob?
* Does the knob dynamically display the value as I spin it? If so, where does it show that value and am I inadvertently blocking the display with my finger/cursor?
* Does the knob have the concept of velocity, whereby I can quickly spin it to the approximate value I want, then make tiny incremental adjustments to get the sound 'just right'?
All these tend to break the "don't think, just do" concept of a skeuomorphic interface.