Hey Paul… sure, I feel like I made a pretty extensive and precise argument with good examples.
Regardless, I’m not here to misbehave and I want us to get along.
I apologize for my part in the comments section and for calling you a name, I could have handled that a lot better and I do mean that sincerely.
If it’s alright with you, shall we try again? I’m on your side mate, all I want is a good pro audio product for Linux and Ardour/MB is honestly the best I’ve ever seen.
Ok, hear goes…
As I said previously, with respect, that is intentionally bad design and contradictory logic. Hear me out.
You’re asking user’s to subscribe to an advanced (and better) workflow they might not know about, but obscuring usability for less advanced users. This could be less advanced audio users in the general, it could be new users to your program. Whatever the case, it only makes Ardour/MB look half-baked to the uninitiated.
I agree with you for the most part. The restricted and prescribed workflow/method, plus analog emu, is precisely why I purchased Mixbus 32C not 5 mins after opening my second session (more on that below). However despite my adherence to that ideology, forcing a particular method onto the user is not the way to convince them of that method. Ironically, that is the other half of my point.
These things slowed me down when they didn’t need to and introduced steps that don’t need to exist, until I make certain commitments with my session. Even then, there is always that set of disparate tracks that don’t really fit anywhere as a group or where I don’t want to group/VCA them. Especially now that you’ve introduced sampling capabilities, that is only going to become more obvious.
That aside…
I’ll use the example I gave in that YT comment: Reaper. The default scrolling functionality, what a confusing mess. Zoom by default and a Ctrl+scroll for common scrolling behaviour. Which would have been fine (it’s actually quite clever) but it took several hours to find it and also that it’s not documented or mentioned anywhere in their videos. Also there is no obvious way to change that default.
Even after finding that control, it frustrated me so much for basic usability that I simply came back to Ardour/MB where I was previously able to get a great mix in an afternoon without even thinking too much. That is of course where it became a personal preference rather than a universal truth but Reaper just got in my way without first proving the benefits of their method.
The only issues I had in Ardour/MB were the drag and drop and the multi-select + general lack of synchronicity with controls. All in all though, hassle-free.
But I digress…
It doesn’t really matter whether or not the workflow will be improved by the presence or absence of this feature. That is unfortunately not for the designers of a program to decide. What we are there to decide is how to increase the likelihood of that flow (which is your point), not put hurdles in the user’s way to achieve something very simple in the name of enforcing that workflow (which is my point). It’s an approach that only works for those in the know and leaves very little for those getting to know.
Aside from that, introducing these types of concepts and methods is something that people need to discover for themselves after understanding why they exist via their own experience. An experience which, and this is the crux of the problem, doesn’t happen without first having common and familiar functionality to breed the tendency for expansion.
As a really simple example of common convention in UX: this window I’m typing in isn’t Microsoft Word but ctrl+b still works to make the words bolded. (not sure if they started that but doesn’t really matter, everyone expects ctrl+b to bolden characters in a basic word editor)
What I assume you think you’re doing is coaxing the user towards a better way (VCAs and groups), which I understand and agree with as a principle. However, the way you’re doing it is deciding that is the way before they have had the chance to discover that themselves and then cutting off the path towards that conclusion. You’re expecting them to go from step 2 to 3 without allowing them to have step 1 first.
Having said all of that, I happen to agree with you. Absolutely, I would be better off putting things into groups and VCAs, which I do.
From a usability and logical pov, multi-select should truly mean multi-select. Anything that I do on a single channel in that selection should affect all channels selected. Even if we both agree that there is a better way, we also need to consider the basic tenets of good and consistent UX design. There should be a logical outcome to a feature i.e. if I multi-select something, I expect that to have an obvious and usable reasoning. If that reasoning means something gets in my way, then it shouldn’t exist.
In this way we can say that grouping is more of a permanent multi-select, it certainly shares the same visual feedback. Yet that same visual feedback doesn’t reflect the same functionality when used a little differently. That is fundamentally fractured UX design right there.
I try to live by the ideas of single-click design. Natural and intuitive user controls and most things should be one-click away. My team actually spends a lot of time designing interfaces and working with clients towards that goal. If the user has to ask us about basic usability or how to do things that are perhaps associated through some kind of convention, we redesign the interface to more closely reflect that convention whilst retaining the advantages that our interface provides. This is somewhat of an art form.
Like good stage lighting or good live audio: if we do our job correctly then no-one should notice.
Even if we disagree on everything I have just said, this functionality already exists as a keystroke. Muting/Soloing toggle exists in the menu. For multi-select. I therefore don’t understand why it’s disturbing the workflow to extend that same functionality to a mouse, which when we break it down is all I’m really asking for.
Re the DnD, yeh I absolutely hear you. It can be hard and maintainability + stability comes first. Still, it would be super great if eventually it existed in the codebase. From memory GTK+ has dnd via Motif and Xdnd and isn’t difficult if you lay out the signals logically. Obviously not critical.