> When we pack high-density information into a data table or a complex dashboard we are increasing the visual entropy of the entire system. Forcing the brain to decode intricate, non-universal shapes in a tiny 16-pixel footprint, creates a “cognitive tax” that users pay en masse every time they scan the table.
What if it's an icon with a simple shape? How does that compare to noising up the table with long phrases and repetitive words? Is the cognitive tax if icons a lot higher or just a little higher? What if it's an app where the user will be using it for hours, so they'll quickly learn what the icons mean and will appreciate the space they save?
Is a tick icon really that big a deal in place of "Task completed"? Or a pencil instead of "Edit"? Sometimes you don't have a choice because of lack of space too. There's always tradeoffs to make. Obviously try to avoid icons that are hard to guess though but sometimes that's not always possible.
I can't say I've ever felt tired looking at icons in a table, but when designing I have had the experience of replacing wordy repetitive text with some intuitive icons in a complex table and it suddenly looking less intimidating.
Right, this article overlooks the difference between a first encounter and regular encounters. The concise representation pays off when you do learn it, as long as it's executed well.
And I'm fine with a bit of cognitive exploration to figure out a green check and red X scheme rather than see a whole table column filled up with words like "active" and "inactive". The former allows more columns on screen at once. Horizontal scrolling is a worse impediment to assimilating information from a table.
I would almost always rather have the words; words are things I can easily search for and manipulate using the text-processing tools in my possession.
Personally, my brain "page faults" whenever it has to interpret an emoji, which makes most use of in-line icons far worse than the text they represent. I expect few people have this problem, but I also expect that I'm not the only one with it.
My gut feel (personal experience, not research) is that the whole of the icons' nature is important. Them having simple shapes doesn't necessarily solve the problem and could in some cases make it worse.
Imagine for example a set of icons that are monochrome, open-ended glyphs comprised of a single stroke with line weight similar to that of the text. This could complicate visual parsing greatly due to high visual similarity to text.
On the other hand, a 16px checkbox control with subtle gradients, shadows, and depth cues looks absolutely nothing like text and is filtered out by the brain almost automatically (unless of course the checkbox state is pertinent to the user's intent). Same goes for a 16px colorful icon with shading like used to be ubiquitous in desktop operating systems.
The box itself around a data table label could hint at a state, if the goal is to define only a handful of states (green rounded capsule for a completed state; diamond capsule for an in-progress condition; red square for an error; purple parallelogram for some special condition; etc).
Not sure how this is for accessibility in terms of colour selection, but I’m sure this could be fine-tuned.
> The rules of the language insist that when you use a nullable variable, you must first check that variable for null. So if s is a String? then var l = s.length() won’t compile. ...
> The question is: Whose job is it to manage the nulls. The language? Or the programmer? ...
> And what is it that programmers are supposed to do to prevent defects? I’ll give you one guess. Here are some hints. It’s a verb. It starts with a “T”. Yeah. You got it. TEST!
> You test that your system does not emit unexpected nulls. You test that your system handles nulls at it’s inputs.
Am I reading or quoting this wrong?
Just some pros of static type checking: you can't forget to handle the null cases (how can you confirm your tests didn't forget some permutation of null variables somewhere?), it's 100% exhaustive for all edge cases and code paths across the whole project, it handholds you while refactoring (changing a field from being non-null to null later in a complex project is going to be a nightmare relying on just tests especially if you don't know the code well), it's faster than waiting for a test suite to run, it pinpoints to the line where the problem is (vs having to step through a failed test), and it provides clear, concise, and accurate documentation (instead of burying this info across test files).
And the more realistic comparison is most programmers aren't going to be writing lots of unhappy path tests for null edge cases any way so you'll be debugging via runtime errors if you're lucky.
Static typing here is so clearly better and less risky to me that I think expecting tests instead is...irresponsible? I try to be charitable but I can't take it seriously anymore if I'm honest.
A tool for creating CSS color palettes for web UIs that pass WCAG accessibility standards for color contrast, where you can fine tweak all the tints/shades quickly using a hue/saturation/lightness curve editing interface:
Unlike most tools based around autogenerating colors, this is more of an editor that lets you fully customise all the tint/shades to your liking with a focus on accessibility. This is important when you've got existing brand colors to include and want to find accessible color combinations that work together.
Would love feedback in general and especially from designers/devs who have different needs in how they go about creating branded palettes!
> I've been relying on ChatGPT to select color schemes/palettes for me
Thanks! Any problems you've found with this approach or it's usually good enough?
For me, I couldn't find a tool that would let me customize multiple color scales at once, check they look good together on a mockup, and also be accessible. It's one of those problems where you can autogenerate something that gets you most of the way there, but then for it to be usable you need need to see how it looks on designs and fine tweak it.
So for my tool, I really need the live UI mockup without having to export first to tweak the colors until they work (e.g. often the off-white/very-light colors used for backgrounds are too vibrant otherwise), the control-point based curve editing helps to explore hue/saturation/lightness curves around a brand color without a lot of clicking, and I want the option for palettes where each color scale follows the same steps in lightness (for predictable contrast between steps from different color scales).
Barely any designers I work with know about P3 colors (feels like P3 mostly appeals to developers right now, for programmatic reasons?), so I'm not that interested in P3 if it means using OKLCH with its intimidating looking color picker. My tool uses HSLuv, which looks familiar like an HSL color picker, where unlike HSL only the lightness slider alters the WCAG contrast, so HSLuv (while limited to sRGB) is great for exploring accessible colors.
I've actually got support for APCA, but I find many struggle understanding WCAG contrast requirements already. There's Figma export too.
Anyway, there's lots of overlap between different color tools but the small details are important for different workflows and needs. I've started to realise too that most designers need a lot of introduction into building (accessible) color palettes in general so it's a tricky puzzle between adding features and trying to keep it simple, which is why I'm very open to suggestions!
I help startups with the UX/UI and web design of their products. This includes web apps, websites, landing pages, copywriting, and I can assist with frontend development where needed. My background of launching my own products and being a full stack developer helps me create practical designs that balance usability, aesthetics, development effort, and performance. I work to fixed price quotes for self-contained projects.
---
The best live example of my work is Checkbot (https://checkbot.io/), a browser extension that tests websites for SEO/speed/security problems. The entire project is my own work including coding the extension itself, UX/UI design, website design (the homepage is optimised to load in 0.7 seconds, 0.3MB data transferred), marketing, website copy, and website articles on web best practices.
[ Rated 4.9/5, 80K+ active users, 100s of paying subscribers ]
---
I have 10+ years of experience, including a PhD in software verification and 5+ years working for myself helping over 25 companies including Just Eat, Triumph Motorcycles and Fogbender (YC W22). See my website for testimonials, portfolio and more: https://seanw.org
Note: For large projects, my partner usually assists me in the background (I’m working on starting a design studio with her in the future)
---
Email sw@seanw.org with a short description of 1) your project 2) how you think I can help 3) the business outcome you’re looking for and 4) any deadlines. I can get back to you in one working day to arrange a call to discuss a quote and how we can work together!
There's also the significant cost to climate change because growing crops to feed to animals instead of eating crops directly loses the majority of calories, but it gets ignored because doing something about it is going to be unpopular:
> More than three-quarters of global agricultural land is used for livestock, despite meat and dairy making up a much smaller share of the world's protein and calories.
> Despite the vast land used for livestock animals, they contribute quite a small share of the global calorie and protein supply. Meat, dairy, and farmed fish provide just 17% of the world’s calories and 38% of its protein.
> Livestock are fed from two sources – lands on which the animals graze and land on which feeding crops, such as soy and cereals, are grown. How much would our agricultural land use decline if the world adopted a plant-based diet?
> Research suggests that if everyone shifted to a plant-based diet, we would reduce global land use for agriculture by 75%.
In the US 8 out of the top 10 environmental organizations with most membership oppose nuclear power broadly and the majority oppose wind and solar locally so I think we can safely conclude that climate change is not important to US environmental causes.
The primary work by US environmentalists (or at least the popular ones) is in ensuring rich people’s homes abut publicly-maintained parks.
Not really; but talking about it more also seems like it will have approximately zero marginal benefit, and trying to insinuate that other people are immoral is probably net counterproductive.
If the goal of the post is to pick terminal colors that contrast on both white/light and black/dark backgrounds, it means you're stuck with midtone colors (between light and dark). This is really limiting for color choice (there's no such thing as "dark yellow" for example), and lowers the maximum contrast you can have for text because you get the best contrast when one color is dark and the other is light.
Ideally, instead of the CLI app switching to "bright green", it would pick a "bright contrasting green". So if the terminal background was dark, it would pick bright green, and for light background it would pick a darker green. There isn't CLI app implementations for this? This is similar to how you'd implement dark mode in a web app.
> Ideally, instead of the CLI app switching to "bright green", it would pick a "bright contrasting green". So if the terminal background was dark, it would pick bright green, and for light background it would pick a darker green. There isn't CLI app implementations for this? This is similar to how you'd implement dark mode in a web app.
The responsibility for this lies with the color scheme not the terminal program.
It's not recent, and most terminals support it. You send an escape sequence to the terminal, and get back a sequence that tells you the exact background color.
That's called `\e[0;92m`, aka the ANSI terminal espace sequence for bright green. You have 15 others, that will be displayed however the terminal's user wants. They're already available in most terminal color libraries, too.
I wish one of those regex libraries that replaces the regex symbols with human readable words would become standard. Or they don't work well?
Regex is one of those things where I have to look up to remind myself what the symbols are, and by the time I need this info again I've forgotten it all.
I can't think of anywhere else in general programming where we have something so terse and symbol heavy.
It’s been done. Emacs, for example, has rx notation. From the manual:
35.3.3 The ‘rx’ Structured Regexp Notation
------------------------------------------
As an alternative to the string-based syntax, Emacs provides the
structured ‘rx’ notation based on Lisp S-expressions. This notation is
usually easier to read, write and maintain than regexp strings, and can
be indented and commented freely. It requires a conversion into string
form since that is what regexp functions expect, but that conversion
typically takes place during byte-compilation rather than when the Lisp
code using the regexp is run.
Here is an ‘rx’ regexp(1) that matches a block comment in the C
programming language:
(rx "/*" ; Initial /*
(zero-or-more
(or (not "*") ; Either non-*,
(seq "*" ; or * followed by
(not "/")))) ; non-/
(one-or-more "*") ; At least one star,
"/") ; and the final /
or, using shorter synonyms and written more compactly,
(rx "/*"
(* (| (not "*")
(: "*" (not "/"))))
(+ "*") "/")
In conventional string syntax, it would be written
"/\\*\\(?:[^*]\\|\\*[^/]\\)*\\*+/"
Of course, it does have one disadvantage. As the manual says:
The ‘rx’ notation is mainly useful in Lisp code; it cannot be used in
most interactive situations where a regexp is requested, such as when
running ‘query-replace-regexp’ or in variable customization.
Raku also has advanced the state of the art considerably.
> They act as stand-ins for actual users and will flag all sorts of usability problems.
I think everyone on the team should get involved in this kind of feedback because raw first impressions on new content (which you can only experience once, and will be somewhat similar to impatient new users) is super valuable.
I remember as a dev flagging some tech marketing copy aimed at non-devs as confusing and being told by a manager not to give any more feedback like that because I wasn't in marketing... If your own team that's familiar with your product is a little confused, you can probably x10 that confusion for outside users, and multiply that again if a dev is confused by tech content aimed at non-devs.
I find it really common as well that you get non-tech people writing about tech topics for marketing and landing pages, and because they only have a surface level understanding of the the tech the text becomes really vague with little meaning.
And you'll get lots devs and other people on the team agreeing in secret the e.g. the product homepage content isn't great but are scared to say anything because they feel they have to stay inside their bubble and there isn't a culture of sharing feedback like that.
What if it's an icon with a simple shape? How does that compare to noising up the table with long phrases and repetitive words? Is the cognitive tax if icons a lot higher or just a little higher? What if it's an app where the user will be using it for hours, so they'll quickly learn what the icons mean and will appreciate the space they save?
Is a tick icon really that big a deal in place of "Task completed"? Or a pencil instead of "Edit"? Sometimes you don't have a choice because of lack of space too. There's always tradeoffs to make. Obviously try to avoid icons that are hard to guess though but sometimes that's not always possible.
I can't say I've ever felt tired looking at icons in a table, but when designing I have had the experience of replacing wordy repetitive text with some intuitive icons in a complex table and it suddenly looking less intimidating.
reply