Standard modifiers for UI control

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.
  • drag on the voltage scale moves vertically

Great feedback, thank you Gauthier!

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!

I’ve made an Issue for this. Will address.

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:

  1. What functions does the user need? What control do we assign to that function?
  2. 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 :wink: 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.

I like this 2nd approach.

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.

That’s good to hear.

As an example, since I fired up the released version for the sake of another thread:

I tried scrolling in the Simulation measurement. It irritated me that:

  • Ctrl+wheel did the same thing as the wheel alone.
  • Alt+wheel did nothing at all
  • Shift+wheel did nothing either
  • scrolling on the time axis did nothing at all
  • dragging on the name of a signal did nothing (you have to reach for the dotted handle)
1 Like

Adding to the list after using the actual 1.2.39 alpha:

  • no way to pan other than grab and drag, and grab and throw. I find it very unergonomic. Scroll wheels were designed for this.

You would expect the scroll wheel to pan horizontally?

Yes. I see that it’s not consistent with the usual use of the scroll wheel in e.g. editors, but it is what I would expect.

Fair enough. Easy customization will need to be a first-class part of the interface here.

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:

  1. I’d rather the scroll wheel scrolled the trace
  2. I’d rather use the Ctrl as a scroll wheel modifier to zoom in small steps and Ctrl+Shift to zoom large steps
  3. I’d rather Shift + scroll wheel scrolled fast
  4. 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.