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
Attachment:
pgpl_DEPxsOQ3.pgp
Description: PGP signature
_______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
