The entire history of computers and software betrays this argument.
Every time we transitioned from a blank, text-command driven UI, to a visual one, we dramatically increased the percentage of the general population able to use something.
Think the transition from MS-DOS to Windows, UNIX to OSX, etc. By representing concepts visually, humans find them easier to understand.
In fact, I’d argue, most software innovation today is just making visual UI’s better. Think the single doc mode (photoshop) to artboard mode (sketch, figma). Single purpose (excel, word) to multipurpose (notion). Etc.
Notion is blowing up with 13 year old kids on Tiktok because it’s an easier UI to do spreadsheets and create documents and websites with. Which are fundamentally valuable things. In software, what is valuable, will be made easier over time.
Most B2B Saas tools are just crud apps. Not only is there no reason coding these apps has to stay complicated, but there’s economic incentive in making it easier.
Unfortunately, many people have a vested interest in keeping things complicated. Like people who get paid to create CRUD apps.
As the saying goes, it is difficult to get a man to understand something when his salary depends on his not understanding it.
One thing that your examples tend to have in common is that they deal with describing states (documents), not modelling processes. Maybe that has something to do with it. Describing actions ends up effectively requiring flowcharts, which is what visual programming typically ends up being, and that gets painful and slow tremendously quickly. That's why visual programming tools do not endure: because once you get skilled enough, you will find them annoyingly constrained.
I can just point out that my niche (accounting) is arguably one of the oldest in computing. Visual programming to address accounting challenges has been tried over, and over, and over, and it failed. every. single. time. It's a massive target that everyone hopes to hit, because the jackpot is massive, but I would argue that it will never happen. Excel keeps winning because it doesn't even try to play that game: if you want to do anything beyond instant calculation, it gives you VBA and off you go. That's what people really want: if they are smart enough to want advanced process modelling, they are smart enough to learn how to write an "if" block.
> it is difficult to get a man to understand something when his salary depends on his not understanding it.
Believe me, there is also a large industry of programmers invested in visual paradigms; and their salary depends directly on not understanding the lessons of the past.
Just because your particular niche has certain complexities that make it more resistant to visual representation with current methods, doesn’t mean we throw out the whole no code movement.
After 20+ years of various companies trying to create a good no-code tool for html/css (eg dreamweaver, frontpage, etc), Webflow finally solved it IMO. So it can take a long time.
But I see no reason why this won’t travel further down the software stack eventually. And we shouldn’t be afraid of it like it’s a threat to us.
Some tasks are inherently complex. Take data modelling as an example. Properly designing a database requires formal training. There's no way around it, and when you mask database design with a UI, you get the worst of both worlds. The complexity is there, unskilled users won't be able to tackle it, and the UI gets in the way of professionals with formal training.
Naturally, there is a continuum of tasks to be done, some can be solved with a poorly designed solution. If a user is empowered to generate a subpar solution, it is still better than no solution at all. That's the secret for Excel being the second best tool for any data manipulation task (for each task there is a better tool, but excel gets the job done in all of them).
The error here is selling visual programming tools as the next evolution step, which will phase out text UIs. It's not. It's a different tool, for a different use case, to be used by a different cohort of users.
My point isn’t that no code tools remove complexity. My point is that they make complexity easier to learn and deal with.
For example, Webflow, which is a no code tool for front end development of static sites, doesn’t eliminate any of the complexity of HTML and CSS.
It’s not easy or dumbed down at all. Most users need to watch tons of video tutorials to get started (if they don’t already know html/css).
But what the UI does do, is make it easier to learn those complexities.
It’s not offering a simplified set of dumbed down options. It’s offering a visual way to deal with all the complexities of HTML/CSS.
Personally, I’ve transitioned to building all marketing sites on webflow, not because it removes complexity (I want complexity!) but because dealing with the complexity is faster and easier with the tool.
Uhm, a visual HTML designer, a field where we've not had any tool before (/sarcasm). But this is different! And you're totally not going to drop it once you've learnt the complexity and discovered all limitations. But hold on...
> to building all marketing sites
Ah yes. So the really complex stuff you'll still do with text. Got it.
There’s other no code tools for things like mobile apps and CRUD.
Ultimately, I think there’s a lot of fear in these comment threads when no code is mentioned, and it’s misplaced.
A rising tide raises all boats. The more we can empower people to create things and solve problems for people, the better off we’ll all be.
You're joking, right? There are loads. They all suck to various degrees, which is why they are not popular.
> Ultimately, I think there’s a lot of fear
Mine is not fear as much as frustration for having to waste cycles on stuff that will not endure.
Take Power Automation (aka MSFlow): it's very powerful, but not because it's a graphical environment; it's because we have an environment with a lot of APIs available without having to do anything. If MS gave me a blank editor with all those APIs preloaded, I would be 1000000x more productive than I am fighting with this goddamn half-broken flowcharty thingie. Meanwhile, nobody else in my team (all non-devs) want to even consider look at it. They'd rather brush up on VBA if they really need to do complex stuff. And it's a shame, because the API wiring is amazing and when things eventually run it's magical.
Repl.it with all those APIs preloaded would be so much more popular than PA, which I fully expect will eventually die a slow death like Yahoo! Pipes and friends.
Visual tools don't inherently mask complexity. They can do, and many do, which is useful for some use cases. And they can also make things visible that CLI or text based tools generally don't. In that regard, they can support developers to complete higher complexity tasks.
Both projects followed the exact same trajectory: users ultimately rejected the no-code platforms and sent all of the programming work back to professional developers. Now the professional developers were hamstrung by layers of abstraction designed for non-developers and both parties were miserable.
Excel is the shining example of no-code enabling non-professionals to create powerful tools on their own, but it may be the exception and not the rule. Ultimately the challenges of programming are not the code, but thinking abstractly about data, and that's a real skill that developers have trained and non-developers have not, and I don't think it is solvable with tooling.
So one might say the issues were more largely organizational. But these weren't lazy people, they were always looking at new tools and techniques. And they were struggling to get any payoff with the tools we had. Sadly the focus of the project was not visual programming, so we were not focusing on the users issues.
The incentives might line up better for departments that can't get tech's attention.
Is there an upper bound to the benefits of visual information in comparison to textual information when handling complex tasks so that when a task reaches a certain level of complexity it becomes easier to represent it in text as opposed to visually? The history of human communication would strongly suggest that there is.
The photo-based system would no doubt work great if the town had only a dozen people (all of whom know each other by sight), and probably work acceptably well for up to a few dozen. It's going to suck for a town with a thousand people, though, and be utterly unusable for a city of a hundred thousand.
Textual information reaches its upper bound far before visual information.
Think reading a recipe from a cookbook vs following along with a well done YouTube recipe.
The density of information delivered via video (visually) in addition to the word messaging (via audio) is roughly 10-100X that of an all text recipe.
...and with zero added effort from the human receiving the information, because our brain natively does the visual processing.
Sure, it’s faster to follow a recipe if you’ve spent ten years learning everything about cooking and food science.
Just as it’s easier to just code something if you’ve spent years learning how to code!
The point is to lower the barrier of entry, and deliver people a higher density of information faster and easier.
For example, you can't write most useful programs without knowing what a pointer/reference is. Doesn't matter if you use visual programming or textual code.
I think you need to show your work on that calculation - because I'm worried it's going to be one of those 'a video has so many bytes of information per frame etc. etc.' claims at which point I would have to wonder why I care what color Julia Child's blouse is when preparing an omelet.
What are the numbers considered when making these assessments? With visual software, we got way more adoption, but this doesn't mean the amount of software necessary increased. I'm pretty sure the majority of the software out there is made of command line tools. The amount of software a developer uses is very large and entirely made of small command line tools, there are entire O. S. made purely for command line usage (any server distribution really).
Finally, there is another giant elephant being overlooked. Software is written in text because in the hands of a skilled professional, text can be VERY visual. I don't have to prove this, there is extensive amount of poetry written to confirm this. Effectively a piece of software written by a skilled professional will greatly benefit every reader, and readers of software are way more than writers of software even in the software development world.
Your example about HTML and CSS is also a very special example. Effectively HTML and CSS are tools to build UIs, not "generic software". There is a lot of software out there that doesn't involves humans at all. I mean, cron is on the majority of the servers out there, it has no UI.
@murukesh_s post wrote the retourt to that. Pointers and Windows had a substantial impact on shaping the reality we live in now. Putting all the responsibillity on the users shoulders and their "intelligence in math" is way to ego focused IMO.
murukesh_s is obviously invested in this, so he's hardly an impartial observer, whereas I don't really care one way or the other and am just relying the experience of somebody helping users with these tools.
That's because the unskilled stays unskilled for a reason: they can't or won't dedicate the amount of focus necessary to learn a technology to any meaningful degree. They will do the minimum they are (very explicitly) trained to do, and that's it. Basic scripting is not hard; if you cannot (or will not) do it, chances are you cannot (or will not) formalize even slightly-complex tasks in a visual environment either.
And of course, visual environments are a productivity killer for the skilled, who then feel frustrated and eventually drop back into textual modes. This is self-evident.
Sadly, it's a marketing dream, so it keeps popping up in all companies in my niche. "If only we build a no-code graphical UI, accountants will become programmers!" - no they will not. If they were really interested in automating tasks and modelling problems, they would have already learnt VBA, which is very simple - smart accountants do it already. People capable of doing advanced math are capable of programming if they really want. Accountants who won't learn VBA will not meaningfully engage with visual paradigms either, because they are simply not interested in these activities. What really needs to happen is to empower smart accountants to be productive without involving IT. That doesn't need visual programming, it just needs a powerful set of VBA apis unshackled from "enterprise" permission systems.