How UI developers can adapt, not die
triplebyte.com
triplebyte.com
However I find the premise that low-code is taking over highly questionable. It may be for some use cases, but they will likely remain just a small slice of the pie in the big picture.
Judging by the amount of job offers alone, React is also taking over - to the chagrin of some, and the delight of others -, yet React is anything but low-code.
We all know the limitations of low-code solutions too: they're good up until a certain point, they make you feel like an utter genius for the speed at which you are shipping, causing nods of approval and high fives all-around.
That is, until you want to stray out of the trodden path: then you wish you hadn't adopted them in the first place, and that behemoth of a React or Angular app you shipped last year suddenly elicits the nostalgia of a long-lost lover with all its shortcomings and misgivings.
So it is hard to believe that the next 10 years will see the decline of custom UI 2D development, or anything close to it. I'd wager if anything low-code will be another tool in the developer's toolbox, and shipping great products at speed will mean carefully architecting them to mix and match the best of both worlds. On the other hand, I predict that those going all-guns-blazing on no-code will encounter some unpleasant surprises at best, and in the worst cases will see spectacular project implosions.
Such has been the history of radical cost-cutting and time-saving measures in software engineering in the last 30 years (outsourcing, low-code itself, etc.). And so it goes...
Conceptually, no and low code tools allow you tred along the _trodden_ path.
Sooner or later you're going to want to go somewhere new, and when you do want to provide something custom where do you go?
Dreamweaver tried to do this in the 90s and failed, personally I still think we're a long way off from a generalised solution.
A concrete example of this is Google Tag Manager, which was made so online marketeers could implement tracking without having to involve software engineers. In the end, the actual implementation of anything non-trivial is pushed to a software engineer, who has to spend time fighting the system to implement basic things without proper version control that could have been implemented on the actual site in a fraction of the time.
As I write this, I realize that the thing that irks me the most about this is that it is a complete departure from the 'normal' agreed upon way to do proper software engineering, with all the tools that go along with that. Working in a 'low-code' system almost always means changing your entire process (which often goes against everything we've learned over the last decades of software development).
"Wouldn't it be great if changes could be made instantly without being told we need to deprioritise our sprint goal and wait for a release on Monday."
"Wouldn't it be great if we didn't need to pay ££££ for a contract developer to meet our deadline."
"Wouldn't it be great if we could stop the tide from coming in this evening ..."
Oh, this always works! Why must we attempt to be so efficient? This curse of specialisation must be lifted, it has held us back for too long!
/s obviously, but in seriousness:
> [author] is a software engineer who has conducted over 1,400 technical interviews for ...etc etc
I find it almost beyond belief that someone with a [supposedly] large amount of experience in software development would to think that allowing clients to implement UI themselves is a good idea.
It's not at all strange as there are many different types of UIs that have to be built.
I think what the author is thinking about is the typical CRUD applications that many businesses need and that are only built in-house, where the UI matters less than in consumer software, and the UX is still important but as long as it's changable, could be done by the users themselves.
I feel like the UI you're thinking about is the one for consumer software, where you're innovating on some solution for a particular problem, and the UI/UX of the tool is probably the most important thing, otherwise people won't pick up the tool in the first place.
If you look at the output of many software agencies, most of what they are producing is simple CRUD applications (and some startups do this too, I guess) which probably could be built by the users themselves, if it's basic enough. While the output of the ones building B2C software is slightly more complex and requires more thoughts behind it to even work out.
It's this statement that goes a long way to showing why we need UX professionals and UI designers.
A good UI directly affects the bottom line of a company.
A badly designed UI costs money. It's as simple as that.
Sometimes the cost for making the UI better costs more than the value you get from having that UI better. It's not a black-and-white "Better UI is always better", it simply depends on too many variables to have that frame of mind.
The UI directly affects usability.
If a problem is so straightforward it doesn't require designing, sure .. then go ahead and let anyone build it. If not, find someone who has spent time solving similar problems successfully.
Ok?
The thing is, software is rarely created in a vacuum, if it was, we'd all be working towards perfection and never really reach it, nor complete or release any software.
You have to balance constraints, and sometimes one of those constraints is money, or energy, or head count. Whatever. There is always balances to be made, and sometimes it's not worth to spend 20% of time increasing the usability by 2%. Sometimes it is, sometimes it's not.
The apps I build for myself, that will never be published, has about 5% of my time thinking about the UI, because it simply doesn't matter and thinking more about it, won't make my life better in any way. Sometimes internal apps have to be treated the same way, if the constraints force you to treat them that way.
I'm sorry, I still think my point stands.
Even in-house software requires a good user experience, and the UI directly affects that UX. Designing a UI that works is a non trivial task; leaving it to people who don't have experience can effectively lead to a business losing a lot of money.
By using a UI library like Angular Material, a UI framework like Material Design and some simple UI design principles, it's possible to build a more than decent UI experience, without having UI specialists on the team.
> If you look at the output of many software agencies, most of what they are producing is simple CRUD applications (and some startups do this too, I guess) which probably could be built by the users themselves, if it's basic enough.
...said every business manager ever. It's simple! Let the client configure it! [And normally] let's burn an absolute shit-ton of cash building unecessary things!
I'm sorry to be dismissive here, but B2B UIs almost always have to reflect very specific business rules, they require careful turning for the clients. This doesn't mean they needs to be complicated, but they will have complexity.
If a company allows their client to use a no code framework to build the UI of the product they are selling the client (I stress this is what is being suggested here, I am absolutely not saying that the UI itself cannot be built using prebuilt components), then there is another UI required to underly that, then an API/various APIs, etc, inception style. What the company has to build is a general framework to allow a client to use a framework to use the company's tool.
By analogy, if a business is selling a tool, sometimes yes, it is correct to sell the parts of the tool instead for assembly by the client, but this adds an enormous amount of complexity to the product production and maintenance. More often selling the tool itself is the better option.
Other commenters have noted how "no-code" tools will lead to productivity wins in some cases, as it's done for all similar tools in the past.
And apparently some developers as well, as I'm not a business manager :)
> but B2B UIs almost always have to reflect very specific business rules
I agree that some B2B UIs have to reflect specific business constraints, but there also others that don't, they just have to be a document storage. And others that don't even need that. And others that for sure have to have very specific constraints, maybe outside of the business or maybe not.
I understand that you have a specific perspective on this, but I think your perspective is just considering one of many use cases of having an UI. There are others beyond that, especially when you talk about enterprise use cases, as many of those are hidden from the people not actively in enterprises, it's really hard to know as those details/workflows are often not public.
But they are there, and anyone making assumptions about what others needs, are bound to be wrong at one point or another.
I'm throwing my hands in the air and saying "probably some UIs could be done by the users themselves, if they have the tools" while also saying "there are UIs that needs professionals to be done correctly". Basically that the whole area is a large gray zone of "maybe this, maybe that", as there is no "almost always should be like this". The use cases are so many, and so different, that it's impossible for you to proclaim that someone is basically stupid for even thinking that users could implement their own UI.
- have worked as a designer for enterprise clients
- have worked as a designer for startup/smaller businesses
- have worked as a developer for enterprise, and for B2B serving enterprise clients
- have worked as a front-end GUI developer for enterprise, and for smaller businesses, and for B2B serving enterprise clients
I am not saying that, even in certain cases where it would be useful, UIs shouldn't be "built" by end users gluing together stuff. Obviously that is necessary sometimes. Just that that is not really a common need.
It is a common request though, and that request is normally made by executives. Regardless of if a framework is used or not, the reason it is normally a bad suggestion is that it multiplies the complexity of development, normally by at least an order of magnitude. So it is particularly ill-suited for simple internal CRUD applications. Which, as you say do not need much in the way of "UI". Except they do, just not the highly polished stylised kind. That UI can often be thrown together by the person with the most domain knowledge at the time of creation, ie the developer
There is a lot of garbage UX that seems a result of trying to fit keyboard and touchscreen interactions into the same hole. The UI flow for saving a document in MS Word is a good example of this.
I just want buttons that don't take half the screen, for starters. My mouse is good enough.
If you're going to use off-the-shelf things - any off-the-shelf things - you are then constrained and limited in what you can do.
No. Custom UIs and UI flows are here to stay.
And low code tools are often not adecquate for integration purposes.
Has anyone looked at MaterialUI lately? It looks dated. The new design paradigms are coming, and whether you like it or not, it’s going to make your current stuff look sluggish.
So yeah, no-code tools could quickly build the design of the day, but today’s designs were already yesterday’s design yesterday.
Lastly, from my experience Triplebyte does not really Leetcode their frontend people. Which means the sales pitch for people they certify for front end has to be centered around ‘UI developer’ (html/css/modest js) vs software engineer. They have an incentive to push some kind of narrative here.
Everytime there's a lot code thing there is there. But they all sucked so far.
I dunno. Self promotion I guess? Targeted at LinkedIn, maybe, aimed at corporate?