davidverhasselt

You've missed the point of my comment entirely and pulled two items out of context.

I'm missing a good reason why the distinction needs to be made visually clear. More about this at the end.

I think a lot of this design thinking is stuck in the past, and we should be able to challenge and throw off some of the shackles or crutches that made sense back then, but might not anymore today, in order to advance and give priority to different goals.

In this specific case, it should be clear that you can select multiple options from context or by text, or it should be encouraged to try it out (i.e. easy to undo). If you need to rely on the visual difference of the icon, then you've already lost more than 50% of the people who don't realise this.

My thesis is that this visual difference is only useful to a select, minority group of people who have an above average level of interest in software, who would even be aware of it. Yes, they were probably the target market decades ago, but nowadays software caters to a wider group than that, and I wonder if you would survey a group of "normies" how many would actually rely on the visual distinction in any way (even just supportive).

I'm late 30s and I remember being confused about the difference between "radio buttons" and "checkboxes" when trying to learn HTML4 when I was young - even the name "radio button" was back then already only something older folks would be able to understand, why it's called that way. The distinction, even conceptually, was more confusing than helpful. It's really just a property of a list of checkboxes, how many you can select, not an entirely different class of UI component.

To continue on from my first sentence, and conclude my argument, this whole article does not contain a single good reason why that visual distinction is important in 2024. The closest I could find, is this line which implies confusion: "There was a brief confusion up until 1986 when Apple used rounded rectangles instead of circles". Just the fact that the article has to describe the difference and show visual examples, tells me that this is just no longer a concept that's important, as it may have been 30 years ago, from when it originated.

Instead, it only makes references to "tradition", "convention", "internal training", or arguments from authority such as "art director says so".

I think that kind of supports my point - in the context of UI of 2024, the only reason that one would keep the distinction visually is for tradition, not for any actual practical reason anymore, or the practical benefits that may still be there have diminished in value so that they don't outweigh the downsides or extra constraint anymore.

Hehe, that's creative. But I'd say - if you're making it that complex, just use a boolean column and a timestamp column separately instead, if you really need the timestamp, and make it explicit and simple to understand.

The OP does not talk about events, OP talks about state and when it was set. There's no where in the article that OP restricts themselves to discrete events that may or may not have occured.

I'd assume most languages don't have a problem with distinguishing between nil and false. The article explicitly maps nil to false, thus I don't see the relevance of your comment.

There is a downside which I've experienced: if you want a triple-state boolean (null, false, true) then having a boolean column allows for that while a timestamp-as-boolean column does not (you lose the "null" value because that equals `false` in timestamp-as-boolean).

Having a distinction between `null` and `false` can be handy for values that are optional or have a dynamic default. If it's `null` you know it is not explicitly set and could use a fallback value. If it's false you know it's explicitly set as false.

A simple use-case for this is when a user can leave the field blank. This is impossible to model with only a timestamp-as-boolean.

Another use-case is dynamic defaults or fallbacks, e.g. `hidden` of a folder where if `hidden` is nil, you fall back to the parent folder's value.

TL;DR a boolean column actually has 3 states, a timestamp only has 2. Article makes a big deal about there not being any nuance about the fact that a timestamp is superior. I disagree, because you go from 3 states to 2 states, there are cases where you'd want a boolean instead of a timestamp. Ironically OP missed this nuance (or they'll pull a no-true-scotsman).

To stay in your simplified universe, consider just two entities, A and B. A has all $100K, B has $0.

- A loans $100K to B at 10%.

- B buys raw materials from A for $100K and creates products X and Y.

- A buys product X from B for $60K.

- B returns $60K to A.

- A buys product Y from B for $60K.

- B returns $50K to B.

A ends up with $90K and product X and Y. B ends up with $10K. At no step was money created out of thin air. Total supply still $100K.

You could simplify it some more by allowing B to pay back A using product X and Y instead of moving $60K around back and forth.