[tomxor]

It is possible to simplify the interface by reducing the number of tools without necessarily removing functionality.

The idea is to identify large sets of tools that can be replaced with a handful of powerful combinable tools to perform the same tasks - this is not always easy but if done well can end up not only simplifying UI but providing more powerful, intuitive tools and reducing unnecessary learning.

I think Modo has done this fairly well in this regard for 3D modelling and animation (programs which tend to be notoriously full of thousands of discrete tools).

This is not limited to DAWs. 3D animation packages, photo editing and video editing packages all historically have this problem... They grow these discrete tools to a large number, it increases the UI complexity, inevitably resulting in tons of stuff hidden under context menus and usually heavily resorting to mode based interfaces.

I had hoped this concept would become popular so that things like Photoshop and Illustrator could be simplified.

[Applejinx]

The trick is how much state you have to keep in your head. Something like Blender requires enormous state about even things like what key combinations mean in different contexts: it's a poster child for impossibly demanding state requirements.

Something like the Flash pen tool is much simpler, but still absolutely requires you to maintain some state: clicking versus click-dragging, remembering not to close a shape by simply clicking on a control point without also dragging out Bezier points. There are expectations before you can begin to flow with the thing.

I've been working hard on this concept using a Minecraft mod (Snowball Madness: http://www.airwindows.com/snowball-madness/ ) that suffered the same problem. I'd made countless 'effects' so it was nearly impossible to remember what did what.

After a drastic functionality-culling process, I began rebuilding things in line with a concept: generalizing. If you can place a block above a snowball and it places the block where the snowball hits, that's what it does, no exceptions. TNT used to spawn explosions just for silly fun, but it became 'place TNT block' altering the type of silliness. Pickaxes used to dig large holes in rock (in some cases, leaving ores hanging) so all the other tools got similar treatments: axes vanishing wood logs, shovels vanishing dirt, hoes turning grass/dirt into tilled farmland. Always trying to incorporate 'cheaty' ways of doing things but predictably so.

It's like the old Apple UI guidelines. The default expectation is that you can grope blindly towards a result and things do what you think they would do, allowing you to not think about the process.

[BaronSamedi]

How about coding a song instead? With the right language or DSL it should be possible. Substitute a Music IDE for the DAW, maybe keep some visualizations (synced to the code of course).

I suppose musicians are more comfortable with a visual metaphor. Still the over-the-top skeuomorphism doesn't seem that efficient to me compared to just coding it.

[kennywinker]

There are numerous examples of music programming languages. I imagine some people have some success with them, but I think they are not widely adopted because it lacks the immediacy and tight feedback loops available in DAW.

In a DAW, as you're playing the track, you crank the reverb knob until you hit the sweet spot.

In a music programming language you fiddle with values and re-compile repeatedly until you find the sweet spot, but even then it's hard to find because you can't remember if it's better this time you compiled or last time.

For musical coding to work, I think it needs a Bret Victor / Swift Playgrounds / Lighttable style IDE, and then... it starts to look a lot like a DAW, just with algorithms instead of a note grid or timeline.

[ssharp]

Some skeuomophic design makes more sends in DAWs, especially the mixer where you might be controlling it with an external controller.

That said, a lot of plugins and virtual instruments never left that world of design after most others moved on.

[bartread]

I think this is an interesting idea, and sounds cool in principle, but the problem is that many users wouldn't know how to combine components together to get the tools/effects/instruments they want, or wouldn't want to bother to learn. The point being that all you might achieve with this approach is to substitute one type of complexity for another, and so you'd still alienate potential users. Maybe different potential users.

Depending on the market segment you're after that might be OK though.

[jlarocco]

> It is possible to simplify the interface by reducing the number of tools without necessarily removing functionality.

Could you explain with an example?

I think what you're saying may be technically true, but not necessarily what most users want.

I'm most familiar with photo editing and retouching, and while the software can appear daunting, it all makes sense looking at it as a photographer and using it for a little while. I use both Capture One and DxO Optics for RAW processing and retouching, and I often read the forums forums for both, and I don't recall ever seeing complaints that there are too many options and tools.

[seltzered_]

FWIW, for the 2D graphics packages I'd argue Acorn has tried to do this in generating shapes where it has an interface letting one chain-together and re-arrange actions.

(shameless plug) I've tried taking the approach of making a plugin for existing tools (Sketch, Sketchup, Photoshop, etc.) to make accessing the large set of tools easier via touch gestures at https://thimblemac.com . It also tracks most-recently-used tools.

[sowbug]

You're describing the Unix philosophy. It's popular, but not in these domains.