[LAU] ZynAddSubFX Usability Survey

[david]

On 04/28/2016 05:04 PM, Mark D. McCurry wrote:
> 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.

For some reason, I find sliders easier to operate, physically and 
onscreen, but I like knobs for some functions. I find onscreen knobs 
less easy to operate. Guess I'm weird.

>> - 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

Yes, point 2 makes perfect sense to me. I'm used to manipulating tone 
curves in photography programs that way. Also manipulating physical 
equalizers. Seems very intuitive to me.

> 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.

Well, I like multiple windows. I can arrange them on the screen in a way 
that makes sense to me, then leave them there for additional manipulation.

> 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.

Upgrade your laptop. Most laptops these days come with touchscreens. And 
Linux supports them pretty well. ;)

>> 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.

A thought: Give users an option to specify their desired UI. Call one 
"Musician" or "Performer" or something like that. Call the other "Sound 
Designer".

I use a panorama program called Hugin. They offer 3 UI choices: Simple, 
Advanced, Expert. I have my choice set at Expert, because that's what I 
do with the program. But if I was doing realtime image work with it, I 
might switch it to simple.

Or get really ambitious and give users the ability to customize the UI 
as desired. For instance, maybe for BANKS I only want to see Organ and 
Piano. But for individual patches, I want to see and tweak everything 
about them. So I can tell Zyn: List these banks on the Banks screen, and 
Show expert settings for individual patches?

-- 
David W. Jones
gnome at hawaii.rr.com
authenticity, honesty, community
http://dancingtreefrog.com