4 ms·
I don't think that's quite the point. It's not that you want dozens of different widgets in every app. It's that when picking an ecosystem for apps, a business
by crispinb 3y ago
I don't think that's quite the point. It's not that you want dozens of different widgets in every app. It's that when picking an ecosystem for apps, a business will want to know that whatever they need (whatever small sample from that multitude), it's available. A large pool of resources is particularly important when you don't know exactly what you'll need up front, which is most of the time.
You might only want 8 colours, but if you don't know exactly which 8, you'd better have a large palette available.
- weinzierl 3y agoI used to think like that, but it doesn't match my experience from my years of building (traditional) GUIs. I believe it is almost always better to stick to the couple of standard widgets that are available everywhere and known by everyone. In the very rare cases it's not it is better to build a custom widget that matches your customers requirements exactly. Nothing is worse than a half-baked GUI element idea, badly implemented and sloppily maintained that matches like 85% of your customers requirements - and that's what most non-standard widgets are. Quality and consistency trump quantity in my opinion.
- crispinb 3y agoIt matches my experience precisely. Every time I've seen a GUI framework/library chosen that didn't have a huge head of steam behind it and very broad availability of off the shelf components and tooling, the project has either failed, or had to be rewritten after a swerve. This is for relatively mainstream software (consumer apps). Niches are another matter.