Skeumorphism anyone?

[Foxmeister]

I don't see you fighting for actual sliders to control the virtual sliders on Helix.

Again, an irrelevance - I can cope with physical knobs and virtual sliders.

Is that so hard to understand?

If they did, would that change your mind? So I guess you don't genuinely prefer sliders, do you?

No, it wouldn't change my mind.

I prefer sliders - again, is that so hard to understand?

 

[Orvillain]

Skeuomorph - Wikipedia

en.wikipedia.org

Other virtual skeuomorphs do not employ literal images of some physical object; but rather allude to ritual human heuristics or heuristic motifs, such as slider bars that emulate linear potentiometers[23] and visual tabs that behave like physical tabbed file folders. Another example is the swiping hand gesture for turning the "pages" or screens of a tablet display.[26][27]

Sliders ARE skeuomorphic, no matter if they're bright orange or whatever else.

 

[Orvillain]

Personally I don't really care whether something "looks" real or not. I think it's appropriate for some things. Take for instance our upcoming plugin, BFD Player:

Versus BFD3:

Both have elements of skeuomorphism, but I know which one I'd prefer to use, and based on 10 years of complaints about the way BFD3 looks, I think I know what the users would prefer too!


But like I was saying... I don't think it is always right for everything. But where I think both Helix and Fractal go wrong is by steadfastly refusing to draw a heirarchy of importance when it comes to various controls. The obvious music equipment example is that of a synth, and the filter cutoff being made to hold more importance than most other controls - because historically, it IS the most important performance control that most people care about.

It's up to the PO, UI, and UX teams, to do the research to find out exactly how people use these products and what they care about the most, and then - IMHO - put THAT right in front of them, and make it easy to use. Most of the time you'll come up with something that works very well for 90% of people, and the 10% will just post on Gearspace all the time about how they hate your guts. Fair trade off I think.

(stats pull out of my ass)

 

[Orvillain]

Oh another quick little thing - when we designed Geist at FXpansion (in short; MPC in a box, ironic that I ended up at inMusic!) we threw away the 1st design of it after we brought half a dozen people into the office for user testing. They couldn't figure out how to use it, even though to the staff who built it, it seemed obvious.

 

[TheTrueZoltan!]

Ah, the good old sliders vs. knobs argument.

Knobs look cool, but sliders make much more sense when using a mouse or touchpad as input device. BUT… I‘m happy as long as a guitar modeling software lets me use the keyboard and type numbers. Yes, numbers. Nothing bothers me more than twisting virtual knobs without having any visual feedback of the dialed value. Could be 5.6 or 6.15… grrr. Or twisting a virtual knob and not being able to hit an even number… I want 4, but no matter how hard I try it‘s always either 3.99 or 4.01… grrr. It just feels so satisfying to dial amp and FX settings in exact 0.5 steps. Who wants to be the first to tell me that „numbers don‘t matter, just use your ears“?

 

[Orvillain]

Who wants to be the first to tell me that „numbers don‘t matter, just use your ears“?

I won't say that, but what I would say is, the tool-tip or read out you see isn't always directly related to the underlying engine. You might be seeing a much different number than what the DSP is being fed. mwahahahahaahahaahahaaa!! Take that OCD man!

 

[TheTrueZoltan!]

I won't say that, but what I would say is, the tool-tip or read out you see isn't always directly related to the underlying engine. You might be seeing a much different number than what the DSP is being fed. mwahahahahaahahaahahaaa!! Take that OCD man!

I don‘t care as long as the software makes me think I hit an even number.

BTW, not having stepped controls is something I dislike about most analog gear. I would never buy an amp that hasn‘t even 1-10 markers around the pots. Yeah, I guess I‘m weird. My personal dream amp would have stepped potentiometers from 1 to 10 in 1/2 steps. That would be sooo cool!

 

[eggpl@nt]

Exactly this. I've posted this photoshop with circularly curved sliders "borrowed" from Boss a dozen times now (still not at @James Freeman level of obsession though )

View attachment 8255

I would enjoy Helix software much more with this interface.

 

[Digital Igloo]

Skeuomorph - Wikipedia

en.wikipedia.org

Sliders ARE skeuomorphic, no matter if they're bright orange or whatever else.

Skeuomorphs aren't necessarily skeuomorphic design. Look at Apple's own iOS Calculator app. No UI/UX designer would ever call the iOS 7 and iOS 12 examples below skeuomorphic design, even though what you're tapping on the screen is clearly an analog for the physical buttons represented by obvious skeuomorphic design in iOS 1 and iOS 3. Even though there are circles in iOS 12, just like the round buttons in iOS 1, the design itself is extremely flat.

Unlike some of my coworkers, I also like the floppy disk icon as an analog for [save], which in and of itself is a skeuomorph, but tapping/clicking a single-color floppy disk icon is still flat design.

And I have absolutely no problem with skeuomorphic design at all, as long as it's appropriate for the product and done well. (BFD3 is a good example.) But when a product like Helix has 260+ objects and up to 32 can be placed in any order—and you're trying to build sounds at the speed of thought—the context switching required to effectively relearn the quirks and design nuances of each and every amp and effect is the antithesis of good user experience. Even Apple doesn't perfectly nail the consistency thing, given that they have sooooo many disparate programs and apps, but they're clearly pushing toward that goal. Despite a din of customers whining and moaning about every little change they make (like how macOS Ventura's System Settings now behave much like the Settings app in iOS), their design wins far outweigh their design misses.

 

[Orvillain]

Skeuomorphs aren't necessarily skeuomorphic design. Look at Apple's own iOS Calculator app. No UI/UX designer would ever call the iOS 7 and iOS 12 examples below skeuomorphic design, even though what you're tapping on the screen is clearly an analog for the physical buttons represented by obvious skeuomorphic design in iOS 1 and iOS 3. Even though there are circles in iOS 12, just like the round buttons in iOS 1, the design itself is extremely flat.

Them being flat is not enough to separate them from their skueomorphic heritage; that of the analog push button. They most definitely are skueomorphic - even the very nature of tapping or clicking on one of those buttons, and an action occuring either on the down or the up stage of the button, alludes to that.

Flat design is not the antithesis of skeuomorphism. They often work hand in hand. That's why I posted a capture of Ableton Live earlier, to demonstrate the point.

If something apes or is a metaphor for a real world object - no matter how it looks - then it is necessarily skeuomorphic at some level. Helix is rife with skeumorphism, even if the overall look is flat, and even if you prefer sliders

My argument is take the design out of it, and look at the thing - it's purpose and it's heritage. Very little on a computer is actually entirely non-skeumorphic.

 

[Orvillain]

A better example of non-skeuomorphism would be UI pie menus... or at least the idea of a pie menu. They have no analog equivalent. However what goes inside each level of the pie menu, often does - buttons, sliders, numbers, radio buttons, etc.



But the pie itself... not something that really occurs in our analog world. It's an abstraction.

 

[Digital Igloo]

A better example of non-skeuomorphism would be UI pie menus... or at least the idea of a pie menu. They have no analog equivalent. However what goes inside each level of the pie menu, often does - buttons, sliders, numbers, radio buttons, etc.



But the pie itself... not something that really occurs in our analog world. It's an abstraction.

I mean... by your definition, a pie chart absolutely is a skeuomorph—it represents the pastry dessert, with various fillings depending on the slice. Even radio buttons—where only one selection can be active at a time—are skeuomorphs—they're taken from old car radios. Or every QWERTY keyboard is a skeuomorph from old typewriters. Or any on/off toggle is a skeuomorph from a light switch or whatever. But I digress.

The point is that there isn't a UI/UX/graphic designer on the planet that's going to look at a single colored circle, square, whatever, and say "that's skeuomorphic design because you tap it with your finger, just like a physical TAC switch." There are literally tens of thousands of articles on skeuomorphic vs. flat design, and my calculator example above is used often specifically to differentiate between skeuomorphic and flat design.

Personally not a fan of neumorphic design, which some were touting as the replacement for flat. Thankfully, it's pretty much dead already anyway. I'd argue Google's Material design is really just flat with more steps, although there's some really great-looking stuff out there.

 

[MirrorProfiles]

Personally not a fan of neumorphic design, which some were touting as the replacement for flat. Thankfully, it's pretty much dead already anyway.

reminds me of this plugin: https://www.polychromedsp.com/

which always struck me as the worst of both.

I think a large part of the discussion regarding Helix are unique to that platform because the design has to apply to both HW units and software. The software is also very wide ranging vs something like a more simple amp plugin, so it’s parameters are totally different. Given what it has to achieve I think it does a very solid job, but there are definitely compromises.

Hum and ripple having the same visual real estate and importance as master volume or resonance etc doesn’t really sit well with me. Sometimes controls are laid out in orders that don’t make sense to me, and when every parameter looks similar (no matter how important the control) sometimes to can be tedious to find what you need. Some of the delays and other FX really suffer from this, where more visual information would make things more intuitive and inspiring to use.

But it makes sense on the whole for Helix, it’s just not something that is ideal. I think Helix’s design on the whole is GREAT and is much better thought out than basically all of the competition.

 

[laxu]

Personally I don't really care whether something "looks" real or not. I think it's appropriate for some things. Take for instance our upcoming plugin, BFD Player:

View attachment 8259

Versus BFD3:
View attachment 8260


Both have elements of skeuomorphism, but I know which one I'd prefer to use, and based on 10 years of complaints about the way BFD3 looks, I think I know what the users would prefer too!


But like I was saying... I don't think it is always right for everything. But where I think both Helix and Fractal go wrong is by steadfastly refusing to draw a heirarchy of importance when it comes to various controls. The obvious music equipment example is that of a synth, and the filter cutoff being made to hold more importance than most other controls - because historically, it IS the most important performance control that most people care about.

It's up to the PO, UI, and UX teams, to do the research to find out exactly how people use these products and what they care about the most, and then - IMHO - put THAT right in front of them, and make it easy to use. Most of the time you'll come up with something that works very well for 90% of people, and the 10% will just post on Gearspace all the time about how they hate your guts. Fair trade off I think.

(stats pull out of my ass)

Not having used either product, I see the two as "beginner user" vs "power user" versions. I've personally never understood the "3D pic of real drums you can click with your mouse" format because it's not something that is handy to play for anything but testing samples and the more abstract top down view of BFD3 looks more usable to me, even if it could benefit from e.g color coding.

I can understand some complaints like throwing a lot of stuff at you but to me just based on the screenshot seems quite easy to understand.

 

[Orvillain]

Not having used either product, I see the two as "beginner user" vs "power user" versions. I've personally never understood the "3D pic of real drums you can click with your mouse" format because it's not something that is handy to play for anything but testing samples and the more abstract top down view of BFD3 looks more usable to me, even if it could benefit from e.g color coding.

I can understand some complaints like throwing a lot of stuff at you but to me just based on the screenshot seems quite easy to understand.

One of the big requests over the last decade has been for users to be able to move the drumkit around in a 3D space, to re-arrange it to match their e-kit, and to be able to make it look as close as possible. Player won't have that yet, but we've laid the ground work for the engine to support it.

Few people understand what the devs were trying to do with the blueprint view, and it's actually no more usable or feature rich than the 3D view. In some cases you can't even see the drums being played (another thing that users of drum software appreciate) and in some cases you can't even tell what drum is what class of drum, because there isn't enough detail. So on paper it may break down into beginner versus power user, but I think the majority of drum software users want something that looks closer to BFD Player (or EZDrummer, Superior Drummer, GGD, etc etc)

We didn't have a proper product owner back in 2013. Everything was developer led - no small wonder then that the plugin turned out to be an exercise in "how many pixels do we need to spaff all of the stuff on screen all at once?"

But all said and done - both drumkit views are skeuomorphic. It's just one is the flat design approach, and one is the "photorealistic" approach (well, as photorealistic as I could manage!)

Skeumorphism is not a design concept. Its been misappropriated and means that to a lot of people, but that isn't what it is actually about. Its about metaphoric connection between the real world and the digital world in terms of functionality, meaning, and symbolism. A button is a button. A slider is a slider. A knob is a knob. No matter what it looks like.

 

[laxu]

My issue with a realistic approach is that it a lot of times will sacrifice intelligibility. I prefer a minimalist approach where you borrow the familiarity of the real thing, and make it easy to read. While not copying something actually real, the Valhalla plugin design are pretty great IMO. Try to imagine the same but with the layout of your favorite amp - That would be my first choice.

View attachment 8253

About sliders. There are benefits, but I'm firmly against them. It comes down to semiotics. Guitar players have always used knobs for pretty much everything. For me to look to a bunch of sliders where I used to have knobs my whole life is just weird, just takes away from the experience. We like to pretend we are all logical, but that's just not the case. To take away any semblance of familiarity is not ideal IMO.

TL/DR Minimalism makes it easier to read; Knobs make it easier to understand. That's what I prefer.

Totally agree about that design. I would love to see more emphasis and grouping applied to controls. In that Valhalla plugin the Shift knob is put front and center with its size and color, communicating its importance. At the same time it serves as a visual divider, helping group the other controls.

Part of what I don't like about the Helix UI is the equal value of all sliders - meaning that e.g Gain/B/M/T is of same importance as Sag or Ripple. Just grouping them to "common" and "advanced" via group labels, spacing or just color coding would help.

Affordance is a term used to describe how a user could intuit the purpose of what they can operate - it's more about the relation between the object and user. For example the simple toggle slider any mobile user is familiar with instantly communicates that it's a two state thing you can toggle. But it can become bad if you cannot intuit which state is on and which is off, a common problem with e.g standby switch on many tube amps if there's no easily understandable labeling of their state like "play/standby" or in UI color coding for the states.

We have all had to learn some bad affordances like when the "hamburger" icon (three lines) became a staple of mobile websites to indicate "this opens a menu." I remember not understanding it when I first encountered it. I'm sure the floppy disk icon for "save" is equally baffling for Gen Z folks who have never seen the real thing.

Familiarity is weird in that way. Someone who has never worked a mixer is probably going to find the way DAWs are laid out pretty foreign. I don't think I have seen anyone try to challenge that design either by doing something that makes sense for the computer screen instead of replicating concepts like mixer channels.

---

Sliders are pure and simply superior to knobs for any touchscreen usage but become good or bad based on their size where they pretty much have to occupy a certain amount of screen space to work well, but not too much or they become hard to read and operate.

Try turning one of the knobs on the touchscreen on the Quad Cortex and you will quickly see why the device has dedicated knob/switch hardware instead. Your finger obscures the virtual knob so you can't see anything as you adjust it.

Fracpad, the unofficial mobile editor for Fractal, has a very novel approach. It shows knobs for values, but adjusting them pops up a slider on screen which makes it more intuitive to move your finger and see the value adjustment. It's not perfect, but it's a good idea to get around the issue of virtual knob adjustment on touchscreen while still providing a similar UI that Fractal users are used to in Axe-Edit.

 

[laxu]

One of the big requests over the last decade has been for users to be able to move the drumkit around in a 3D space, to re-arrange it to match their e-kit, and to be able to make it look as close as possible. Player won't have that yet, but we've laid the ground work for the engine to support it.

Few people understand what the devs were trying to do with the blueprint view, and it's actually no more usable or feature rich than the 3D view. In some cases you can't even see the drums being played (another thing that users of drum software appreciate) and in some cases you can't even tell what drum is what class of drum, because there isn't enough detail. So on paper it may break down into beginner versus power user, but I think the majority of drum software users want something that looks closer to BFD Player (or EZDrummer, Superior Drummer, GGD, etc etc)

We didn't have a proper product owner back in 2013. Everything was developer led - no small wonder then that the plugin turned out to be an exercise in "how many pixels do we need to spaff all of the stuff on screen all at once?"

But all said and done - both drumkit views are skeuomorphic. It's just one is the flat design approach, and one is the "photorealistic" approach (well, as photorealistic as I could manage!)

Skeumorphism is not a design concept. Its been misappropriated and means that to a lot of people, but that isn't what it is actually about. Its about metaphoric connection between the real world and the digital world in terms of functionality, meaning, and symbolism. A button is a button. A slider is a slider. A knob is a knob. No matter what it looks like.

Ok, totally understandable from that background. Seeing that blueprint view I totally thought it would be like a "arrange it like your real kit" view and being able to see the drums bounce or highlight a bit when played.

Totally agree on the description of skeumorphic, even though I also often equate it to "fancy graphics representing the real device."

The "devs just crammed everything on screen at once" design is a pretty common occurrance when the feature set makes sense to them and they want to make it all as visible and fast to access as possible, which is why I called it a "power user" view. To me the ideal is the halfway point between these where the user is not overwhelmed with options but it's still pretty quick to access.

Some time ago Leon Todd made a great video about the Roland GP-100, the first digital modeler ever. Someone has made a 3rd party editor for this and I genuinely love it in its sheer simplicity and the way it shows you more of what you need than Axe-Edit, HX Edit etc manage to do.
Amp, cab controls always available and then whatever effect you have selected.

Sure, it's as old fashioned as it gets, but it has a certain clarity and simplicity to it that modern UI designs often miss. I think it's also a good example of how to make sliders work well - not too big, not too small, with easily visible (and typable) numeric value too.

 

[Orvillain]

I mean, that looks awful and is almost the best example of developer graphics and developer UX that you could've conjured up!! I'll post more later. Day of meetings now.

 

[laxu]

I mean, that looks awful and is almost the best example of developer graphics and developer UX that you could've conjured up!! I'll post more later. Day of meetings now.

If you look beyond the "Windows 95 forms UI" visuals and ignore that left side preset/signal flow list, you have a lot of things going:

• The most commonly used things, amp and cab sim controls are always visible.
• Parameters are grouped in an easy to understand way.
• There seems to be shortcuts to common setup/utility items.
• Adjusting a single effect is fairly straightforward, even if the 2-3 letter names are obscure unless you are familiar with what they represent in the GP-100.
• It has a lot of controls, but doesn't look too crowded.

Remember that this is a 3rd party tool for a modeler from I think 1995 so in that context those param/number value inc/dec stuff also makes a lot more sense.

To me the "developer graphics and UX" problem is all about "we put these controls where they would fit with no care for how usable they are." Often it's a question of "what was easiest to program" instead of "how do we make it easy to use." I don't think that applies here.

 

[Foxmeister]

I mean, that looks awful and is almost the best example of developer graphics and developer UX that you could've conjured up!!

To be fair, it isn't really any different to almost any other application from the same period.

Back then, what we call now call "UX design" was very much in its infancy, and what was in the forefront of most developers minds was functionality, not usability per se.

At least that's my recollection anyway!