4 ms·

Nope, that is not what I'm thinking about. B2C applications have different constraints, sure, but that's not really anything to do with this. > If you look at

Nope, that is not what I'm thinking about. B2C applications have different constraints, sure, but that's not really anything to do with this. > 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.

diggan 6y ago
> said every business manager ever. It's simple! Let the client configure it! 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.
- RobertKerans 6y ago
  So my perspective is: - 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

diggan 6y ago

> said every business manager ever. It's simple! Let the client configure it! 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.

RobertKerans 6y ago
So my perspective is: - 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