Deliberate Design Choices. A solution or a problem?

Due to the heated discussion and the language of choice in this thread Usefull redesign without hardware limitations in skeumorphism? I resolved and ended it.

I’m still interested in your opinion about limitations in design choice:

  • why it has been done
  • how it has been done
  • and most likely derived from that the what have been done

I’d like to discuss in a positive formulated language what are the pros and the cons of the approaches and give the opportunity to give feedback. I invite interested users and developers to get insights.

They can be as pragmatic as “Because it’s easier to develop to I just don’t know otherwise.”

Or for users: I always wanted to have X? Why don’t we see this yet?

1 Like

Here is a post from the other thread asking some questions

Can you morph hardware into something else? Hardly

That’s what the limitation implies. Things you do in the real world, which just stop being possible or extremely expensive to apply because of matter.

I did give some examples already so here a general extract/recipe:

  • Why am I limited to 1 rack height?
  • How can I expand/unfold a panel into fullscreen?
  • How can I implement sliding panels, that reveal/hide parts of the module for better details/overview?

For example (just an idea, would actually have to play arround with a prototype): Have ports at the sides in panels. On key combination aka shortcut or toolbar button reveal/hide them. when patching you need them, when tweaking and playing you don’t!

I prefer sequencers where I can see the complete sequence, also the patterns (a good example for this is the KORG Gadget sequencer with it’s LIVE cloned interface). A couple more features on the sequencer would be nice. But it;s doing a great job. Event a step sequencer would benefit from having all notes in the sequence displayed. Overview vs. details.

Andrew has some good pointers in the module design section regarding spacing and how to design, which some developers disregard (for whatever reason). Has nothing to do with skeumorphism but good design practices.

Grouping modules and showing//hiding or folding/unfolding them or just for subsections of one module.

As for a feature request if would be nice to create a custom interface for a group of modules. AKA a in Rack module designer where I can map knobs, buttons, sliders, ports to the underlying and hidden subpatch. This is out of scope, but would be a nice feature.

This have been the topics about screen real estate and how to navigate it. Ben has some good modules dealing with some things mentioned here in packone and packtau.

Have a module be extendable wihtout patching. There are already the expanders. But you can’t fold them.

Are you really limited to 1 rack height? No.

What’s the way to expand a module to fullscreen? Just zoom in!

And panels are resizable, for example:

And here’s what I want to know: What kind of modules do you plan to code?