This is neither urgent nor critical but to be considered by the time you are working on routing improvements…
Problem statement
Currently sound routing is defined using 4 different config flags:
Loop playback routing
Main input routing
Aux In routing
Click routing
As it refers to the same setting, it could be easy to provide a more concise and easier to visualize (currently you need to scroll to visualize all of them and can’t see them at once…).
Proposal
Provide a clearer routing UI in the form of a matrix as in the following example:
I know there is an on-going action about routing, and while you are on it, it could worth providing an easier to read UI and you could consider such a representation (as a matrix).
Please update the mock-up to use checkboxes as appropriate.
If a setting (row) allows more than one choice at a time, that should use checkboxes (a square in a mock-up). For a setting that only allows one choice at a time, use radio buttons (circles).
Yep, I fully agree with you, UX guidelines clearly say “checkboxes” for this use-case, the mock-up was just there, as an example, to give the idea of a matrix representation (and I think it was clear enough, as you got it).
It does not presume of the eventual look’n feel.
Today this is a separated flag called “recording source” in the Aeros.
This topic is about the four flags related to what is called “routing” in the Aeros (maybe we should say “output routing”, but this is how it is currently labelled in the Aeros). As such the flag you mention should be kept out of this matrix because it relates to a totally different concept: input routing…
But this concept of “array” or “matrix” for a group of flags is probably the takeaway to keep from this topic. I mean as long as you have a group of config flags dealing with the same idea it’s just a shorter and clearer way to display and edit information… To be applied probably everywhere it is possible to.
After that nothing prevents representing the whole signal chain a bit a-la Helix or BiasFx with a chain and blocks… But I honestly don’t think it is necessary, it would maybe even become less practical.
I tend to change both the input and output routing at the same time. That’s just me. Would be easy to add to the above table or at least locate the Input routing" right about the output routing.
I understood what you said, but I still disagree.
You are representing in this table two different types of information, and that’s why you end up with one column containing only two checkboxes because the other options have actually no meaning…
I think that you are trying there to mimic a signal chain like you would define it in an Helix or BiasFx.
To be semantically correct, such a signal chain would have probably to be represented like this:
We are used to this way of representing this type of information because of the aforementioned devices which introduced it years ago. Yet I think it would be an overkill for the actual routing capabilities of the Aeros.
On top of this, the fact the Aeros has a resistive screen instead of the capacitive screen present in most of our mobile devices, makes it generally difficult to reliably drag’n drop (which is the way to “draw” the links between boxes with such a paradigm). As such I don’t think we should really go in that direction… But I obviously never tried a drag’n drop with the Aeros screen, and if it works well, it would be an interesting way to represent this information…
In the end, we have to be simple, and you probably already gave the correct answer. The “input routing” setting (currently known as “recording source”) should be right before the “output routing” setting (currently known as “routing”), because they are complementary (sibling) information (and the input routing represented as it is today as “recording source” is clear and efficient), but I disagree mixing the two types of information within the same table, as they are not of the same nature.
I don’t think we will agree here, as we are pursuing two different goals, even if both of them are perfectly legit:
You are trying to represent the routing information in its most compact form (and in this case I think the signal chain is the right answer).
I am just trying to provide a clearer mechanism to represent config flags of the same nature as an array.
