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.
We’re a bunch of fine folks in a fully remote team, working on a nice up-to-date Rails monolith with some Vue.js sprinkled on top.
Our SaaS product and platform is making accountant’s work more meaningful by improving their workflows and replacing their hairy Excel sheets with a 21st century product.
Read more about what our values are and what working with us is like on our job ad: https://grnh.se/550cf58b2us
We’re a bunch of fine folks in a fully remote team, working on a nice up-to-date Rails monolith with some Vue.js sprinkled on top.
Our SaaS product and platform is making accountant’s work more meaningful by improving their workflows and replacing their hairy Excel sheets with a 21st century product.
How to choose? As a Senior Ruby Engineer you will work on our main product in our large codebase together with 25 other engineers. As a Senior Ruby Integration Developer you will work in a smaller team of engineers closer to the professional services team, and will be developing smaller greenfield products that link our main product with third party software to accomplish commercial goals.
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).
We’re a bunch of fine folks in a fully remote team, working on a nice up-to-date Rails monolith with some Vue.js sprinkled on top.
Our SaaS product and platform is making accountant’s work more meaningful by improving their workflows and replacing their hairy Excel sheets with a 21st century product.
How to choose? As a Senior Ruby Engineer you will work on our main product in our large codebase together with 25 other engineers. As a Senior Ruby Integration Developer you will work in a smaller team of engineers closer to the professional services team, and will be developing smaller greenfield products that link our main product with third party software to accomplish commercial goals.
To try and cut down on my pandemic-related news consumption I forked my code for https://hndigest.com and repurposed it to send out a daily report every morning with the stats and graphs of the day before. I made this my "single corona-related moment" of the day, so I can get it over with and get on with my day.
You can select which regions you'd like the graphs to be from, including specific subregions in the US. As a Belgian living in Estonia I've set mine to send the stats on Belgium, Estonia, US, and China.
It's a rough first version and I'll be adding more stats and polishing things up a bit as we go along. I'll try answering questions as best I can, and will gladly accept feedback.
If you would like to learn why this common myth is false, I would recommend the book "The Ascent of Money: A Financial History of the World", which in one of its chapters explains that this result actually made the Rotschilds go almost bankrupt because they were betting on a prolonged war, and they were just barely able to maintain their wealth despite the defeat of napoleon, not because of it.
Heya, I run https://hndigest.com - you can configure it to email you the top n posts over a certain period (daily up to weekly). Check it out, it might suit your needs.
Indeed, I too had difficulty finding exact information on this new change. I then stumbled upon the PwC tax alerts where it was very transparently explained. Personally I wouldn't mind if they would take a bit longer to implement changes like this, so everyone can be accurately informed and optimise in time.
> In addition, if you've taken out profits before, then the company income tax is 14%, up to the amount that equals the average of the last 3 years. So if you take out similar profits on a regular basis, the tax rate is only 14% on everything.
As I understood it, this is only so for distributing profits to legal entities. If you're distributing to a private person, the private person will have to pay a new 7% income tax which sums up to a total of about 20%. This of course only matters if the private person is tax resident in Estonia.