Percussa Home / Shop / Contact /

Use of blank screen real-estate to clarify meaning of abbreviations

SSP Features and Ideas
#1

Description of feature (short and simple):

For menu pages that don’t (ie. 2nd, 3rd and 4th page of Global Presets, or the network editor when a blank slot is selected) display anything on the right 3rd of the screen, list the abbreviations used in the interface below along with the words they represent and a very short description where applicable.

How will this feature improve the workflow or experience for all SSP users (keep it short and focused):

Allows understanding and recall of parameters in circumstances where the manual isn’t handy. A good example of this is RtMM.

It’s something I remember now because it was the first global setting I had to change, but ask me in a year what it does (or which abbreviation it is if I recall the functionality), and I’ll likely draw a blank.

3 Likes
#2

It will be better to do this with a popup message similar to the one you see when saving a preset.

The current open screen real estate here and there might be used for additional visualisations at some point and then we would have to remove them again or move elsewhere.

1 Like
#3

the only negative I can see for a popup is button functions. I’m assuming you’d have to press the button you’re unsure of to even see a pop-up stating what an abbreviated button functions means?

#4

no, i’m thinking of a shortcut you press, and a bubble popup comes up that explains the shortcuts for that particular module. it automatically disappears after a few seconds, like maybe 10 or so unless you press some other button, then it disappears faster.

2 Likes
#5

As a new user, minimizing the negative impact of abbreviated values would be a very welcome addition to the OS. Roundtrip delay would be minimized— which is extremely important in creative contexts where we are attempting to achieve flow state.

Abbreviations can lead to a great deal of confusion in areas as simple as module selection— and as extreme as Input/Output selection.

Here’s the thing— hardware module manufacturers only get so much space to print values near their interface elements. Largely, they manage to convey an appropriate level of detail in a very small space. Abbreviations should be a last resort as they represent a barrier to cognition.

The module selector is a good example of this. A classic alphabetical list would be a significant improvement over where the OS is today. If the interface can’t outdo an alphabetical list for speed and interpretabity— stick to a list.

1 Like
#6

I like the current module selector, being in two dimensions/table format means it quicker to get to specfic modules faster - esp. as the number of plugins grows.

I do agree with the the abbreviations being cryptic
though honestly, using the SSP regularly means I know at a glance what they all are, so not that tricky - however, as plugin list grows I can see that getting harder

perhaps a compromise would be to have a one line ‘status bar’ at the bottom of the browser - this could display an expanded name/description (VSTs have a description field that could be used)
therefore as you move around, you would see this at the bottom of the window.

abbreviations on encoders/buttons I think (personally) is more confusing…
however, Im not really sure I have a solution…

I’ve first hand experience of building UIs for the SSP, and the issue I had was for context, you need the label to be above the encoder and in a context layout for buttons, doing this at a reasonable font size, and you soon find your limited to very few characters.

then add to this the idea of two values per encoder (something on a few modules)
this is useful on modules, since a user can see it without having to switch pages.
BUT it again reduces the label size.

so its a challenge on the SSP because we do not want tiny fonts either.

I used to have help pages on the module (I still do on SWAT) , but ran out of buttons which made it awkward, also I didn’t really find I had enough space to be useful… (and its load of dev effort to do it).

though I wonder if perhaps like the browser, a full name could be display when the encoder is turned?
on my modules often parameters ‘pop up’ when you turn the encoder - so I could display a ‘full name’ at that point - however, that wont work in all situations.

#7

the same goes for the current table format, which is also almost fully used, certainly at the speed you release modules, it will be camped by the end of the year
-not to speak the (meaningful - ?) 3 letter combinations will also be exhausted

there’s also no logic in the current order of the modules in the table
-although in the beginning, there used to be an order/logic