[LAU] ZynAddSubFX Usability Survey

[Mark D. McCurry]

On 04-29, Louigi Verona wrote:
> I did submit the survey, but I would like to add a note here too.
Thanks for taking the time to fill out the survey and going above and
beyond.

> The most important thing to understand before any UI project is what the
> goal is. And although it sounds really obvious, in reality it is much
> harder than one thinks.
Agreed.
You should have heard me tripping over my own words when trying to nail
down the ideas of workflow and a user friendly experience when
describing the whole project to a collogue...

> Things I believe need a little more analysis:
> 
> - mockups seem to differ (apart from colors) by the type of controls - in
> one cases it is a Knob Universe, in the other it is the Slider Universe. I
> think there is a good case to be made for the use of both. Look at what the
> control is doing and see if you can save space by introducing a slider
> instead of a knob and vice versa. Also, sliders that are backwards are
> generally more confusing than those that are vertical, especially for
> things like envelopes, simply due to the fact that most known synths have
> them this way
Agreed, I'm generally a resident of the Knob Universe and now I have the
data to show that people who like to reply to the survey tend towards
that side as well.

> - how do envelopes work? I see a graph, but I also see knobs over it. Does
> it make sense to save space by making envelopes in tabs, like it is done in
> Sytrus
So, this is something which is poorly communicated by the existing still
mockup images and what I'm about to describe might not have been what
the designer intended at all, but let me try to elaborate on this
component.

So, the region where the graph exists in can serve a few purposes in my opinion.
It is a:
1. Detailed view of the data for the corresponding set of parameters
2. An interactive and graphical means of manipulating the parameters
3. A graphical view into how the currently running notes are affected by
   the parameters

Point 2 might not make much sense, but consider the regions shown in
http://fundamental-code.com/tmp/template-regions.png
Effectively each orange, green, or purple region can change what the
graphical representation in the red section is viewing.
This means that you can view the current filter response, quickly see a
LFO shape, or look at an envelope without changing to an entirely
different view or tab.
I think that's a pretty big improvement over the current solution which
tends to involve growing new windows to see further into the data.
Providing an interactive graphical view does also help with some of the
musician's use cases IMO, but that impression may be ill founded.

Point 3 for envelopes would look something similar to the sample
position tracker that renoise has (basically a yellow bar which shows
the phase/time position)..
This might be overkill for a lot of these views, but hopefully with
enough views into running notes it becomes more obvious what parameters
are affecting that subtle element of a patch.

> - have you considered other layouts?

A few mockups have been passed around the community in the past, though
generally they tended to solve the problem with a greatly reduced number
of parameters.
That certainly helps when someone is in a musician mindset as you have
pointed out, however it would be pretty off-putting to those who have
access to their favorite parameters removed.
(that's not to say that all parameters are useful, I just don't know
which ones can be safely canned without notably breaking the app for
existing users).
At some stage I might analyse existing patches to find which parameters
are essentially always at default levels and perhaps integrate some
optional analytics into the 3.0.0 UI's demo to figure out what gets the
most attention.

> Why do you find this layout most efficient and how does it work for the
> use cases?

So, other layouts are an option, but this one is the best one presented
so far and it was generally well received for this facet when it was
originally published.
Once again it's the most efficient for the combined
musician/sound-designer so far and it doesn't (relatively)
have too much clutter or too much empty space.
I'm not sure about the case of touch screens though.
Based upon the responses so far it looks like at some point within
development I'll end up purchasing a small touch screen so I can
experience the same frustrations of users in that context.

> Will the layout fit into the screen?
Yep, there is a *lot* under the hood to make everything resize nicely.
Some of it is a little unconventional, but it seems to work well in the
existing prototype.

> Is it intended for live work (a possible other use case)
To a lesser degree, yes.
This is where I see the simplified navigation, single window UI, easy
MIDI learn, and realtime param automation combine to make some live work
practical.
In those cases the job of the UI would be make setup easy, let the
musician bind parameters to their (likely) physical interface, and get
out of the way.

> This is a lot of work, but it might be worth it. And I love the fact that
> you have a survey here, I think this is a great idea and your user-centric
> approach might very well pay off! But I would encourage you to look at big
> synths out there, because each of them embodies many-many surveys done by
> those companies and there is no reason not to use that knowledge ;)
It's going to be a ton of work, but this is something that I've wanted
to finish for quite some time.
Judging by the response so far there's at least a few users who find
this very valuable.
I'll end up with another survey once a demo of the application is
complete, so hopefully the combined feedback will result in a polished
UI.

As per other big name synths I've been trying to sort out that
information, though mapping one teams decisions onto a different piece
of software is pretty tricky.
Each option out there provides a slightly different solution all of them
slightly incompatible with their own trade-offs.
At the end of the day the best way to make sense of the options is to
watch almost any youtube video of someone using zyn to spot the "why in
the world did they need to do ABC to accomplish X".

> Anyway, hope my notes were useful and maybe someone else will add the many
> things I missed.

Yep, thanks again for the feedback :)
--Mark
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-user/attachments/20160428/25fa34c0/attachment.pgp>