Building a plug-able system in a way that doesn't blow up in your face can be hard. Firefox got a lot of bad press for redesigning their plugin system.
Jenkins is one of my favorite examples for why plugin systems are evil. As users accumulate plugins, it all becomes a giant, unmaintanable monolith that ends up unable to perform even the most basic tasks due to some unrelated/uninteresting/forgotten plugin somewhere doing something weird.
Instead of stuffing everything into a monolith with plugins, split it out into individual composeable units with minimal features.
First of all, Photoshop isn't a toolbox. It's a tool, but with plugins. The real-world analogy would be a KitchenAid kitchen machine, where you can attach awkward tumors like a spaghetti machine or entire food processor to their power take off. The kind of accessories that, after purchase, make you look long and hard in the mirror, trying to figure out just when it happened that your life fell apart.
A toolbox, on the other hand, is just a vehicle for making tools easily available. That, and being a blunt weapon in emergencies.
If I were to imagine a universal image toolbox, I'd imagine it as system that can visualize a stack of buffers. Then, it would be able to launch other applications, providing access an API to access and manipulate the buffer stack. That's all.
These applications can provide your usual floating toolbox UI's just fine, and nothing should stop it from having the same UX as Photoshop, but plugin-less. Depending on things, these tools may use usable standalone, for bulk use, command-line use, from different toolboxes, whatever. You'd be able to swap out features that are otherwise Photoshop built-ins, as they're just another application here.
This distinction between plugins (i.e. extendable tool) vs. toolbox (isolated tools) is important: Instead of awkward tools designed entirely around their ability to attach awkwardly to a KitchenAid, you get a tool designed around doing its job right.
(That KitchenAid accessory metaphor works a lot better than I initially anticipated—the PTO is the annoyingly limited hooks you have to work around, and the results are as awkward as any plugin system.)
I agree that most of the time it's best to give users only one way of doing things, so that they don't get creative and go down a rabbit hole.
Nevertheless, if a product targets a specific type of user, which is expected to be knowledged about and follow certain best practices while using it, making the product more customizable can be a competitive advantage.
We can't always blame the product for being "too complex" if it's purposely designed that way so that well-read users can take the most out of it.
Often the opinions made when designing the software is part of what you're selling. Otherwise, I just ship you a box of 1s and 0s and you can put it together yourself =)
Doesn’t require much complexity from the TV though.
Jokes aside, sometimes simplicity is judged on different criteria. Everyone’s favorite example is Craigslist (ugly, but actually quite simple once you grok it), but I can name a few others where the actual criteria for simplicity can be hard to define.
Bash, for example. It takes a while before you really realize what the scripting can actually do and what Unix pipes can do. Once you see it, it makes a ton of sense, but until you grok the abstractions, it's just a pile of syntactic mush you can't remember. It's simple for what it does, but the problem itself has a lot of complexity.
I believe the same thing about Vim. It requires training because while its modes become simple after you start to get it, it's an irritatingly arduous road to get there. So from the perspective of a lay user... not simple at all. From the perspective of an expert, it's effective to the point of religion.
Say, once a user just wants to play games on a console and has to wait for a TV to boot and prompt you to install updates, when a user wants to use AppleTV instead of Android TV, or when they want to upgrade the smarts.
I think the man reason people think this is simpler is that manufacturers force it down consumers' throats as this setup sells more units due to planned obsolescence.
This feels like microservices-for-everything as a product.
Then you've designed a platform, with a reference combination. Which carries its own set of challenges and over-complications.
There's something to be said for a clean, batteries-included product... with a way to hack the hell out of it.
It's not about making each macro-service into 1000 micro-services. It's about making your macro-services smaller, instead of all-consuming monoliths.
The problem is that monoliths will never be hackable. A LEGO-kit is hackable. A monolith just have hooks and connectors, but the product itself will always be static.
You can get things shipped as pre-assembled LEGO kits (both metaphoric or not)?
In that regard, browsers aren't that bad.
Card carrying member of the disagree-club here (malleable clan), but I think it's a tall order to ask users to write procedural code.
Tools that are:
(1) declarative by nature (HTML, DSLs)
(2) based on direct manipulation (PSA: we're lucky to have Bret Viktor on this planet)
is what will win out in my opinion.
Or will we be writing procedural code 30, 50 years out? :)
--
[1] YMMV, founder of https://mintdata.com here, where we recently opened public access & are seeing the above come true.
In my experience, it just makes workflows more difficult since you now need to create custom editors, linters, formatters, testing frameworks, etc. You need a whole new ecosystem before you can truly become productive on top of learning an entirely new syntax.
We've been using our own "Visual SDK" to build large parts of MintData for the past few years.
It's 100% written in TypeScript/React, using decorators (cough: annotations!) and allows us to:
1) add new spreadsheet functions in TypeScript
2) wrap any React component
3) we get the auto-magic property panel UI "for free" & it instantly talks to/from the spreadsheet
For our cloud/backend imperative layer:
4) we use our own real-time stream processor (think: Apache Storm but minus the Clojure stacktraces)
5) the SDK lets us quickly write flow blocks in Java using annotations & connect to all sorts of enterprise-y systems (SQL/NoSQL stores, Queues, File Systems, etc)
@slifin -- in terms of engineers writing & selling those layers, we're open to it -- ping me if you have ideas & we can give you access to the docs & SDK.
--
[1] I'd put a link here, but the flamethrowers have come out on this thread :)
Before the others come with torches, I’ll point out we turned on public/free access recently, would be happy to hear your thoughts/feedback on the MintData approach.
The user should have the power. Also the interface should be as powerful as possible. One such browser that embraces this philosophy is Next https://github.com/atlas-engineer/next. Source: biased author
--
[1] team of https://mintdata.com, where we've been known to appreciate a fine keyboard shortcut or 12.
[2] partly an inside joke to our team who reads HN, since we recently shipped keyboard shortcuts for our top menu (Google Sheets, we borrowed what we could to ease the pain :D )
Those with nefarious purposes find them extremely useful too. It's a lot of work to secure those interfaces against abuse.
For sure. And if individuals are happy with trading some security for some functionality/flexibility in their software, I'll support their right to make that choice.
It gets more complex when the people affected by that choice aren't the people making the choice. Which is more likely in the case of network programs.
> Usually, the hard part is not security per se, but identifying user intent. You want to come up with a process that ensures that the user who enables potentially dangerous interfaces knows what they are doing.
Indeed. I'd add identifying developer intent to that as well. What functionality am I trying to enable v.s. what else am I actually enabling? Coming up with that process is the herculean task there.
Whilst I don't disagree with this point, it has all to often been used as an argument against open software, and ultimately leads to more closed and less secure software.
You don’t have to make them work for everyone. They don’t have to be safe in all possible scenarios. But they are there for Support to offer to users who are caught in a bind and need a solution.
The about: box is a bit like this. It’s there, if you really need it, but they aren’t going to flood their menus for all the 2% cases.