3 ms·
Using availability as a metric for UI bugs is great. After all, UI is just an API for humans, and it breaking breaks workflows. > These unique kinds of UIs hav
by cobertos 2y ago
Using availability as a metric for UI bugs is great. After all, UI is just an API for humans, and it breaking breaks workflows.
> These unique kinds of UIs have less convention and unique accessibility characteristics that are expensive to solve. But a lot of the time, our budget should be zero. To build it with what we have already. To copy-paste.
If you build UIs like this, you end up with the sort of one-size-fits-all UIs no one likes. Like when Twitter (and others) consolidated their desktop and mobile UIs into one mobile-first one that works worse on. You waste a bunch of space and information density, lose eye scanning ability, for the benefit of higher developer velocity. It must be carefully applied. Things like shipping address forms (example from article) or yes/no modals are a great place for standardization but trying to assemble those pieces on a single page, or show something slightly different and you're back to square one.
---
Didn't we try to standardize some of this already? Isnt this why <input>s are derived from the OS and why alert() and prompt() exist? And default style sheets? And no one wanted this! Browsers have opened up _everything_ to be customized, capitulating to designers. And even with all that customization, some things like HTML5 validation still feel like theyre missing pieces.
- madeofpalk 2y agoFor building as a part of an overall product, I agree that the budget should trend towards zero, not away from it. It should be easy to make things “look like GitHub”, but still possible to build new outside-the-box experiences where relevant.