For engineers doing UIs once in a while, I can recommend Refactoring UI [1]. It has a bunch of practical tips for making your life easier: Picking a color palette, font sizes, margins/padding etc.
I came to suggest this (also mentioned in the article). Not just engineers, I would suggest this to designers and managers too. A few of the books I always suggest to people involved in Product (the manager, engineers, and designers) are “Good Enough Design” (List Apart), “Refactoring UI” (this is actually a pretty recent addition), and the classic “Don’t Make Me Think.”
For anyone in the trenches long enough will know that most of the facts, such as the ones from “Refactoring UI” are common sense. Unfortunately, I’ve realized that it is NOT, even for many designers.
This stuff is of course subjective, but a lot of the "improvements" on that page involve adding a bunch of extra whitespace everywhere, the exact trend a lot of people are complaining about nowadays. I'm not saying it's bad per se, but I would not present the design choices on that site as broadly good either.
It's fascinating, since I don't get the impression that UI elements needing room to "breathe" was an ironclad rule during for example the era of Windows 95. It sounds like folk wisdom for everyone on the same bandwagon of mobile-first. So much creative design potential (and admittedly some inaccessible ones) is lost when these opinions are passed down as the rule of law.
Another bugbear for me personally: rounded corners. Ask online and it feels like people just parrot the idea that rounding is "more friendly and pleasing" over and over, as if blind repetition of an ideal makes it true. But I've never looked at a picture of old webpages or UI frameworks with sharp corners from 20 years ago and go "that's unfriendly." It feels like with this one, a couple research papers came out a while back showing that rounding makes users spend less energy on element identification, and then used that outcome to conclude "well, I guess a huge swathe of UI design is now a solved problem."
Subjectivity died with the need to squeeze out every last drop of "efficiency" out of every UI design. And no, I don't think that rounded corners are friendlier and more pleasing than all alternatives. In fact, I believe they are a staple of the web and modern UI design in general homogenizing into a bland, unremarkable mess, and are thus irritating. I just border-radius: 0; everything globally and call it a day.
The first example on that page ("Contacts" box) looks way better in the "before" style. Turns me off their entire proposition because it's obviously incredibly subjective.
Love it! Not an iOS dev, but have built a personal app that I want to publish for macOS too. I built on top of SQLite, but didn’t want to tackle the synchronisation yet. That should solve it.
It employs a „last edit wins“ strategy for conflict resolution, which is fine in my case. Obviously could be too basic for collaborative apps.
You’d be surprised; it depends on the scope of the last write wins register. If you do it granularly attribute by attribute, last write wins is fine for mostly-online mostly-realtime collaborative apps. The exception is (rich) text where you really want CRDT/OT/similar intention preserving merges of concurrent edits.
Agreed. Thinking about lifecycle, side effects and state doesn’t just go away. It’s inherent to the system you are building. Hooks is a way to address that, class lifecycle methods are another. None of these tools will magically let you ignore proper design.
The GCP tools are a performance disaster in both Chrome and Safari in my experience. It can be actively painful at times on some screen like the log viewer.
We recently installed a solar system on the roof, battery included. The app it comes with is okay to answer most questions. But that wont prevent me from shipping my own dashboard based on locally scraped data. Just for the sake of it. Also my homelab machine is bored.
We frequently reference this website / guideline for a reference of maximally accessible components / web design, it's really good. Not the prettiest (thick black / yellow borders on form components and the like), but accessibility trumps design.
Not necessarily. For example, good design on a staircase doesn't mean that everyone ever can use it, and not every situation can involve alternatives. Accessibility is always relative and is not a binary state. As another example, not every video can be replaced by its transcript. Thinking in binaries leads to rejecting better-but-not-perfect solutions, such as not rebuilding something to be better for most people because it won't be better (or more accessible) for all people.
In theory, yes. In practice, the typical specialist designer is going to optimize for things that come at the cost of accessibility.
But yes, in general you're absolutely right, that a good designer will take into account all factors, including accessibility. But the way that "design" has evolved in practice in means that the thing we all think of as "web design[er]" is not optimizing for it.
Not everything done in the name of accesility makes it accessible to all, nor does accessibility have a necessary correlation with 'good design'.
That's not to say we should't strive for both and require accesible solutions, but let's not pretend putting lightswitches 40" from the floor or those bumpy concrete pads in grocery store parking lots are better for everyone.
which seems much more sensible, but suffers from a different problem when used in context.
Personally, I think both are confounding two different use cases. Links are often used inline in text. The use case that W3c and the Home Office are addressing are use cases that would be better address by out-of-line buttons:
[Download]
[Documentation]
But both seem broken when the use case is hyperlinks in inline text.
To use a concrete example, how should one rewrite the following?
PiPedal is a guitar effects pedal that runs
on Raspberry Pi. To download PiPedal, *click here*.
To read the documentation, *click here*.
I get the objection. But the fix seems unacceptable:
PiPedal is a guitar effects pedal that runs
on Raspberry Pi. Get Pipedal. Read the documentation.
Nuh uh. Not happening. I'm not sure what you would call that. Meta-grammatically incorrect? Whatever it is, it is not idiomatic English.
Pipedal is a guitar effects pedal that runs on
Raspberry Pi. To download PiPedal, visit the *Download
Page*. To learn more about Pipedal, view the
*Documentation*.
Perhaps. That is the actual text I used in my documentation. But, speaking from personal experience, the challenge is that it is often very difficult to nounify "click here"
Ubuntu Server installs don't suffer from this problem;
but before choosing an Ubuntu Server install, you
should read the *Ubuntu Server* section of the
"Installing on Ubuntu" page.
Which makes one wonder, what exactly is the foul that's
being committed when "here" is used as a pronoun for the
content that's being referenced? In this use case, there
is not an actual accessibility issue, because the the link sits inline within a sentence that provides all the context
that's necessary to indicate what to expect when you click.
And in the very first example given, the text is from a lede in a web page where concision matters.
To download PiPedal, click *here*.
Is that really an accessibility issue? particularly when there's are buttons right above it that say
[ Download ] [ Documentation ]
The actual metric that counts here is: how many times will people visit the Download page? And from that perspective there is significant doubt in my mind as to whether the following text will be better.
Rings true! I’ve built a desktop app for building static sites to meet users (read „my dad“) where they are. Haven’t really touched it for a few years.
https://solar.franz.hamburg/