I would like to stress the importance of using standard keyboard controls for the user interface. The whole Ctrl vs Cmd is already bad enough, I don’t like creative solutions to confuse even more. I’m pointing at using Space as a modifier. No one does it, and I think it’s a constraint everyone can and should live by.
I’m sure you’re aware of the principle of least astonishment? Space as modifier is a big surprise.
There are several standards for the use of modifiers, Adobe’s probably being the most common. I don’t mean that this is the exact standard to mimic, though. For example (something that would not surprise me much):
wheel scrolls horizontally
Ctrl+wheel zooms horizontally
Alt+wheel scrolls vertically
Ctrl+Alt+wheel zooms vertically
The logic is consequent: no modifier scrolls, Ctrl zooms, Alt means vertically.
Perhaps also:
wheel on the voltage scale zooms vertically. Ctrl+wheel too.
Agreed we need to get the exact controls for this dialed in. Other sources of inspiration include CAD applications.
SPACE is used for Panning in Adobe products and Sketch, and I think CAD too, that’s why I used it, but everyone is going to have a different opinion on this – I think we will need to offer a couple options and allow customization - ideally as part of a user - onboarding. It also needs to be super discoverable so something will need both onboarding and some sort of smart help for.
I’ve heard ‘principle of least surprise’ for API design - I love it as applied to UX!
That’s good to hear, I actually mentioned CAD programs before editing my original post, I’m not sure if you saw that. I was not aware of space being used for panning, so I guess my knowledge shows its limits.
The user customization seems like a great idea!
I have noticed two different main approaches when it comes to designing user interfaces:
What functions does the user need? What control do we assign to that function?
or
What could the user possibly try to do with the interface? What do we do when they try it, avoiding surprise? (and eventually, are all functions covered?).
I’m a fan of the second approach, which I’m sure you understand since I wrote them that way The first approach is however very common, because it’s the most natural from the point of view of the implementer. It often implies that the user has to learn the program’s way, which gives a worse experience.
Onboarding is nice, but the best is if it’s not needed.
So the user tries to ‘screw around’ with the display, trying to make it do what they want it to do and the question is what do we do about, so to speak.
I feel that modifier keys are probably not sufficiently discoverable for all users and so some sort of instruction will be necessary.
Our new designer will be taking a 2nd pass over this and we’ll get it sorted. He has super high standards for this sort of thing and I’m looking forward to what he comes up with.
Can you make the colors of the channels match the wire colors on the wires so humans can read it? Was there a contest for the minimal amount of pixels to represent colors? Naming the channels would be a plus. Do the three lines have a purpose? Also doubling a color would have been much better that doubling black.
Being able to save part of what you capture would be a plus. (Not export).
This thread started in 1.x land, but applies just as well to 2.x. @ [gauthier.ostervall]'s comments about “least surprise” and allusions to “discoverability” are right on the money. For example:
I’d rather the scroll wheel scrolled the trace
I’d rather use the Ctrl as a scroll wheel modifier to zoom in small steps and Ctrl+Shift to zoom large steps
I’d rather Shift + scroll wheel scrolled fast
Right click menus are great for context sensitive options and are easily discoverable
Those modifiers, in my view, are unsurprising and discoverable. I would never think of using space as a modifier so I wouldn’t discover it.
Right click on the time scale is a great way of navigating to a “set time scale” dialog - something I’d really love to see! Right click on an analogue channel is a great way to navigate to a “set display range” dialog.
The first approach is however very common, because it’s the most natural from the point of view of the implementer. It often implies that the user has to learn the program’s way, which gives a worse experience.