State of the current plugin UI/UX

[James]

@Klaustrophil

The most of the current plugins are pretty wasteful regarding the space they require. If you look at the example below, you see that the magenta tinted area isn’t really serving any purpose

I completely agree. I went into a lot of detail about this in the Plugin Artwork topic in terms of the amount of unused space

@James

Here’s a bit of a guideline as to what I believe would be a good direction to go down. Nothing is official yet, this is still a discussion and we are learning together as we go.

I know that this goes against our current SDK. I think we need to update the SDK and create new asset packages but that is a big project that we can’t take on right now. So I would encourage you guys to keep making your own stuff and avoid the SDK if you have the time to make everything custom

Consider this a nudge in direction

@James

Maybe something we could put in the style guide is an overall information/control density percentage to aim for. Like say 60% as an example. So there should be no more than 40% unused space. Just an idea, no idea what number would be appropriate yet

@Klaustrophil

There has been already a minimal mode suggested which is even more reduced to just the name and IO harnesses. I consider this too extreme because of several reasons:

• It’s hard to see what exactly is going on in a patch.
• Each adjustment will require at least two clicks, one on the node and another one on the actual parameter. This makes editing harder.
• It might encourage overly complex effects with too much parameters since there’s no visual boundary

I get it but if you show all the parameters, it will start to get back to the same size as actual GUI (after GUIs are optimised) Though I do see an advantage of listing the parameters like on “Resolume Wire” in that it would make cv routing really easy

@Klaustrophil

developers (or maybe just those who porting stuff)
have to bother less with UI design if they don’t want to while users don’t have to deal with those ugly tins anymore.

I think the answer to that is to just replace the tin with something less ugly. Perhaps a nice solution would be to have a kind of node view underlying all plugins and if a GUI has been added to a plugin it will appear that way. If not, it appears like a simple node where the IO and parameters are automatically populated in a very simplified way like the “resolume wire” example. Then the user could have the option to toggle off all GUIs so that every plugin appears that way if they want

@Klaustrophil

First of all, this is actually already a problem with the current UI. In many cases, there are hidden parameters only accessible via a separate menu. Second, my aim would be providing a UI which is just more functional by neither hiding nor bloating anything.

No denying it is more functional. A Tesla model S is more functional than a Mustang, but people still like mustangs. We can’t exclude those people, or more so, excluding them would be shooting ourselves in the foot. For many people, the skeumorphic GUI is what brought them to MOD. I would always aim for this to be an option.

@Klaustrophil

In my opinion, most of the current plugins would need a redesign because it’s already out of hand. I consider visual resemblance important as well. But have you actually done any UX surveys backing the claim that each plugin has to look like an actual piece of hardware?

I agree that most of them could use a redesign! You raise a good point here that I have been thinking about since the discussion in the Plugin Artwork Topic. We don’t have recent data on the user’s design preferences. I have been thinking about running a survey specifcally on that. I tend to lean more on the functional side too so I am intersted to know where the majority of the user’s sit on this now
I even mentioned it here

@James

This discussion has been going of a lot of assumptions until now which I think is okay because we are just spitballing ideas. I think that soon we should start to do some polling/surveying of users to find out what they value most in the plugin GUI designs

@rogeriocouto

I like a lot the grid idea.

Yes that’s another good point. We had some internal discussions about a snappable grid to simplify placement and routing. There are a lot of questions when you go down that rabit hole though

@dreamer

I think if UIs get too generic it would be very hard to read a patch, especially since many plugins have way more than just a couple knobs (some have many dozens, even hundreds are possible).

That’s true, this is the reason why guitar pedals use bright colours so you can quickly see where everything is at a glance

@dreamer

While I see the use in being able to switch between a “fancy” and “generic” patch UI, having just generics like this would not make patching a very enjoyable experience.

Maybe not but it could make it faster. I would suggest that the nodes could be coloured. When we conceptualised “Blocks” we had an idea to make them coloured too for that reason. Easy to group and easy to identify

@dreamer

Also for any vendors/brands that want to sell or promote their specific plugins it would not be favorable to not be able to stand out with their own design identity.

True, we can’t overlook branding

@spunktsch

Its tough to balance between user who like to dive deep into stuff (me) and users who just want to get stuff done.

Yeah this is why I lean more towards having the option