UI inconsistencies (request / bug report ?)

spending lots of time on the ER-301 the past days since i have it, i’m loving it more and more. there are how ever a very few “luxury problems” that i would enjoy to see enhanced in later versions.

i don’t know if there’s reasons for this (something i don’t yet unterstand or that will be implemented later on), but i’m observing quite some essential inconsistencies in the way the user interface (or better the interaction with it) works. i’m sure lots will be fixed – anyways, wondering about the way selecting / toggling / confirming things works. here are a few examples:


example a) when trying to add a new device, it is necessary to confirm this action with the enter key – clicking below the top display has no effect


example b) when trying to select the input in the top display, the enter key again has no effect


example c) then, for some actions, both keys work.


totally don’t want to be to pedantic, but – not being super firm with the device yet, it’s unintuitive having to try multiple buttons to see which one works. i’d love to use the jog wheel to navigate and the bottom (enter etc) buttons to confirm and select stuff – especially because it does happen every once in a while that when i clumsily try to press a top button, i rotate the jog wheel :smile_cat:

any thoughts on this issue? any reason the enter key can’t always work?

2 Likes

Example a)

You press the soft key under “insert” which is S3. Single button press.

thanks neil, that does help for this one particular situation. it how ever doesn’t as soon as you’ve then entered the units-menu.

Under most circumstances, the M keys below the big screen are used to select a corresponding item or parameter.

As this isn’t finalizing an operation, that’s most likely why it was decided that the enter button would be reserved for confirmation-type situations such as selecting a file etc.

It’s really quick and easy once you get the hang of it.

The most important GUI concept to grasp (imho) is that the selection cursor/arrow controlled by the encoder and the soft keys are independent. The arrow/cursor does not have to be over an item for you to select it, as the appropriate softkey will highlight it.

If you haven’t watched Brian’s video or the getting Started vids I’ve posted, I think they would you help get a better feel for it - especially vid #1.

1 Like

Great post and the pictures are very much appreciated @benniii.

Neil hit the point on the head. You are NOT meant to place the cursor over an item with the encoder and then press ENTER to select it. That is too slow and does not take advantage of the 9 (=6+3) soft keys below the displays. Use the encoder to get your selection into view (if necessary) and then hit the soft key below the desired option/selection/whatever to perform your action. The few places where the ENTER key actually works like you want it to are actually slated to be removed because otherwise users will tend to fall into the rut of hunting-and-pecking with the arrow cursor and the ENTER key like they were using a mouse.

Please digest this alternative way of thinking about the UI, give it a try for a few days, and then if you still find something anti-intuitive, by all means report back. I want to hear about it. :smile_cat:

1 Like

thanks a ton for taking the time guys!

now it makes a lot more sense! :slight_smile: and yes, i guess what confused me was that it worked one way sometimes – and other times it didn’t. knowing now, how the UI is meant to be handled, i can learn to get used to it ( / unlearn how i tried to use it and start seizing its benefits).

back to fiddling with it – cool!:balloon:

1 Like

Just from watching the videos, I find the cursor arrow a bit confusing. I totally understand what you guys are saying about the arrow not working like a selection cursor, but it does look like it should be one. We are so used to “pointing” to things with a graphical arrow and “clicking” to “make it so”. Maybe a different graphical representation that’s more appropriate for its actual function might be clearer? Like for example it acts like an insertion cursor in text, sometimes, so maybe a more vertical-bar type display in that context?

It’s also a bit odd that both the “viewport” and the cursor position are controlled by the same knob, but they are somewhat disconnected (sometimes turning the knob moves the viewport, sometimes just the arrow) It might make sense to have a mode where the knob always and only moves the viewport, with no cursor visible at all, and a mode where you move the cursor first and viewport only when the cursor goes off the edge (basically like now). This might require an extra “insert” press to turn on “insert mode” with the cursor visible, for example. Nobody likes more button presses but I thought I’d throw it out there… a hard connection of knob to viewport would make it easier to move through a chain in a controllable/predictable way.

Just random thoughts from someone who doesn’t have their ER-301 yet