Re: [LAU] ZynAddSubFX Usability Survey

On 04-28, david wrote:
> 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.
This point has been pointed out in the past and it is a pretty typical
trade-off of single window designs.
In my opinion most of this is mitigated by the vastly reduced navigation
overhead.
With the existing UI, the distance between different views might involve
transitioning between 8-10 different windows.
From my own experience this typically means that you're digging through
a bunch of windows piled on top of each other in order to navigate and
as such you *want* to have some arrangement which doesn't change because
changing it is painful.
With the mockups related views are normally 1-2 clicks away with the
maximum distance being around 5-6 clicks.

That navigation difference may end up converting a few people to the new
paradigm, but for the remaining ones, it's possible to exploit the
technology powering the UI.
So, the UI is an out-of-process one which connects to the zyn core and
the zyn core is designed to behave correctly with *multiple*
*simultaneous* interfaces.
It might be buggy in implementation currently, but the design permits
running multiple copies of the user interface.
So, if you really wanted to it should eventually be possible to a
different instance of the GUI running on multiple screens or multiple
portions of the screen.

> Upgrade your laptop. Most laptops these days come with touchscreens. And
> Linux supports them pretty well. ;)
I had expected some of the data to show that, but most of the
touchscreen size responses were 7 or 10 inch displays.
While not idea I could see a UI this expansive working in the context of
a 10 inch display though a normal laptop/desktop sized monitor would
definitely offer some noteworthy advantages.

> >>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".
So there is essentially no chance that I'm doing this for one key
reason: Maintenance.
The current UI provides a 'Simple' and 'Advanced' UI.
I know that some bugs have sat unfixed in the simple UI for ages because
it doesn't receive enough testing from users which would typically
report bugs and none of the devs have *any* reason for using that
interface.

This breakdown has historically meant that you have one view which is
confusing, user unfriendly, and the only reasonable way to use the
program and another view which is overly restrictive, doesn't provide a
model for the data that it's manipulating, underdocumented, and buggy.
With a large very active team with a lot of QA this could be mitigated,
but even then I don't think it would be a good idea.

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

So for audio applications, I'd argue that Hugin's simple UI corresponds
to the case of no UI within a plugin host.
From there the user can get an instance of an application, load basic
patches, and manipulate the output in their own familiar environment.
Advanced->Expert on the other hand are more of a spectrum and a learning
curve for the real UI.
Starting out I'd expect a user to want to explore patches, perhaps
play with an oscillator, expand to a LFO, then an envelope, etc.
Ideally it's an experience which let's the user slowly grow their
comfort zone.
The current mockups might do a poor job at that, but I don't think it's
practical at this time to come up with something between the plugin
host's builtin controls and the full UI.

> 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?
Heck, you want to code your own window/view, then I (eventually) won't
have a problem with that.
I'm not (currently) going to provide the tools within the UI to do so,
but if you have a text editor the code to generate the UI isn't that
horrifying (though the layout code takes a good bit of getting used to).
For example the Add Synth global parameter window is mostly defined by:
http://fundamental-code.com/tmp/ZynCenter.txt

I'm not going to recommend breaking out the editors quite yet, but the
dynamic nature of the UI might eventually make sense for a reduced view
relevant to a *single* user.
This side of things is mostly beyond the scope of the 3.0.0 release though.

--Mark

_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user