I can't imagine it would, at least not without some (a lot of) social lube. Even bars might prove hard, since a lot of people there will be the regulars and other fixed groups who probably aren't interested in making friends. If you could join the smokers for a fag that might work out, but that doesn't happen any more since you can't smoke outside public establishments (which is fair, but it does remove a potential social arena).
It's reasonably possible at events. Cars and Coffee works great, since everybody wants to talk about their car. I doubt it will work at the dentist, since nobody really wants to be there in the first place. Maybe if they're wearing a shirt or something you can compliment or ask about and then can use that as a springboard?
If you're the dictionary definition of an extrovert you can probably still make it work, but you'll really stand out, and you'll be rejected a lot.
I am bothered by random people wanting to talk to me -> Randomly talking to other people would bother them -> Bothering people is rude -> Randomly talking to people is rude.
Hence why the platinum rule is better. Once you know that other people (apparently!) aren't bothered by randomly striking up a conversation, you can adjust your actions accordingly.
No, that rule does not say "it is rude for others to do unto you differently from how you would do unto them"--it's about how you should behave toward others, not a justification for your negative judgment of how others behave toward you.
I agree that the platinum rule is better, but that difference is not the problem here.
I don't judge them negatively. They're working based on the available information. That line of reasoning is the exact same that I would use if it weren't for the fact that I have better information available and thus can apply the platinum rule. I don't enjoy random conversations, and would consider it rude to engage in them if it weren't for the fact people seem to enjoy them. Since they do, I try to engage in them when people try to strike one up.
If I didn't have that information (and people used the golden rule consistently and weren't just knobheads), then I would be consistently annoyed at people not following the golden rule. As long as my theory of mind doesn't include 'other people generally enjoy random conversations', my perception would be that the golden rule is consistently broken by people striking up random conversations.
I'm curious how much this one guy, all on his own, has stalled passkey adoption.
In theory, this issue could never touch average users. It's only power users who use standalone open-source password managers. All the options normal users are funnelled into aren't going to expose passkeys in plain text (except maybe Firefox?), and thus aren't going to be phishable in any meaningful sense.
But this guy opted to tell the open-source community that having exportable passkeys is wrong, full stop, and that open-source implementations might get banned for allowing this, planting a gigantic red flag right next to the very idea of passkeys, making every single power user who sees that post (which is linked on every thread which touches on passkeys) either completely reject the idea, or approach it with extreme caution. And thus no power user will recommend it to anybody else, not to mention the general usability problems they have.
I guess if it weren't him, the same ideas would have been made clear in other ways.
There are a lot of UI concepts that are foreign to younger developers, simply because they grew up using web apps and smartphones. I think computer science departments need to make a class on human-computer interaction a mandatory part of the curriculum, and those classes need to require students to sit down with and actually use a variety of UIs from two, three, four decades ago. There's a ton of value in being conversant in the basic building blocks and paradigms of multiple UI systems, and in knowing what problems have been solved in the past so we don't keep badly reinventing the same features or failing to learn from the mistakes of the past.
There are a lot of things in older UIs that I think every developer should have hands-on experience with, eg. using nested menus in classic Mac OS; using an MDI application on Windows 9x; using the file browser and dock on NeXTSTEP; using X11 with focus follows mouse; anything with pie menus. Not because those things are necessarily the right choices for today's GUIs, but because there are valuable lessons to be learned from them, and reading an article like this or studying an old HIG document doesn't have the same impact.
> Forcing users to click on graphical elements presents many challenges: what constitutes an "element"; what are its boundaries; when is it active, inactive, disabled, etc.; if it has icons, what do they mean; are interactive elements visually distinguishable from non-interactive elements; and so on.
There are standards and common conventions for a lot of this in the Windows 9X/2000 design language, and even in basic HTML. These challenges could have been solved (for values of) by using them consistently, and I think we might have been there for a little while, at least within the Windows bubble. The fact that we threw all of those out the window with new and worse design, then did that again a few more times just to make sure all the users learned to never bother actually learning the UI, since it will just change on them anyway, doesn't entail that this is an unsolvable problem (well, it might be now, but I doubt it was back in 1995).
> Like you, I do have a soft spot for the Windows 2000 GUI in particular, and consider it the pinnacle of Microsoft's designs, but it still feels outdated and inneficient by modern standards. The reason for this is because it follows the visual trends of the era, and it can't accomodate some of the UX improvements newer GUIs have (universal search, tiled/snappable windows, workspaces, etc.).
I fail to see why any of these features couldn't be implemented within the design constraints of the Windows 9X/2000 design language. There are certainly technical constrains, but I can't see any design constrains. They were never implemented at the time, and those features didn't become relevant until we'd gone through several rounds of different designs, so we never had the opportunity to see how it would work out.
> There are standards and common conventions for a lot of this in the Windows 9X/2000 design language, and even in basic HTML. These challenges could have been solved (for values of) by using them consistently [...]
The thing is that GUIs naturally have to evolve to cater to their user base. The "office" metaphor was useful in the 1980s and 90s for making computing familiar to people who were used to "desktops", "folders", "files", etc. Some of these terms still exist today, but the vast majority of users can't relate to it, so it's meaningless to them.
This is why GUIs will always have to change and adapt to trends, which will always cause friction for existing users.
My point is that by minimizing the amount of graphical elements (note: not completely eliminate them), we minimize the amount of this friction. The difficult thing is, of course, maintaining the appropriate balance of all elements while optimizing for usability, which is ultimately very subjective.
But consider that CLIs are effectively timeless. The friction comes from their lack of discoverability, arcane I/O, every program can have a different UI, etc. And yet this interface has persisted and has largely remained the same for decades. Most programs rarely change their CLI, so the user only needs to learn a few commands to be productive.
So I think that the most usable UI is somewhere in the middle. It should avoid the constant churn of GUIs, and be more accessible than CLIs. This is possible to build for power users, but it can also be made approachable for less technical users.
> I fail to see why any of these features couldn't be implemented within the design constraints of the Windows 9X/2000 design language.
That's true. But then again, what exactly is the Windows 9x/2000 design language, and what makes it better than the modern Windows GUI? Is it the basic Start Menu? The task panel with blocks for each window instead of icons? The square instead of round windows? The lack of smooth transitions, transparency, and graphical effects? The overall brutalist theme?
We can certainly add all the features I mentioned to Windows 9x/2000, and we had some of them even back then via 3rd party tools, but isn't that essentially what modern Windows has become? There are ways to revert some Windows 11 features today with alternative shells and such, so is that the ideal UI then?
When I think of Win2k, I think of the overall simplicity. This is mostly due to nostalgia than for any practical reasons. I'm sure that I couldn't stand using its barebones UI today, as much as I would enjoy the simplicity for a brief moment.
> The thing is that GUIs naturally have to evolve to cater to their user base. The "office" metaphor was useful in the 1980s and 90s for making computing familiar to people who were used to "desktops", "folders", "files", etc. Some of these terms still exist today, but the vast majority of users can't relate to it, so it's meaningless to them.
We still 'dial' with our phones, even though phones haven't had dials in over 50 years by this point. Nobody would even explain phones using that metaphor anymore. Even just having a foundation of common terminology is helpful in teaching people new systems.
> This is why GUIs will always have to change and adapt to trends, which will always cause friction for existing users.
I fail to see the connection.
> My point is that by minimizing the amount of graphical elements (note: not completely eliminate them), we minimize the amount of this friction. The difficult thing is, of course, maintaining the appropriate balance of all elements while optimizing for usability, which is ultimately very subjective.
This is true in today's world, but not necessarily in a world where the UI language of computers is stable and users can trust their computers to not change render their understanding of the system from underneath them. If all buttons had the same hints to tell a user 'I'm a button', in the same way default HTML links tell users 'I'm a link', then we could trust users to have this understanding.
> But consider that CLIs are effectively timeless. The friction comes from their lack of discoverability, arcane I/O, every program can have a different UI, etc. And yet this interface has persisted and has largely remained the same for decades. Most programs rarely change their CLI, so the user only needs to learn a few commands to be productive.
It's remained true in a small niche of power users, while for the rest of the world, this environment might as well not exist (beyond the functionality it provides to them after it's been filtered through several layers). CLIs are irrelevant dead-end in the story of user accessible design; one that there's probably some lessons to take from, but not one to entertain in any serious manner.
> That's true. But then again, what exactly is the Windows 9x/2000 design language, and what makes it better than the modern Windows GUI? Is it the basic Start Menu? The task panel with blocks for each window instead of icons? The square instead of round windows? The lack of smooth transitions, transparency, and graphical effects? The overall brutalist theme?
Yes.
> We can certainly add all the features I mentioned to Windows 9x/2000, and we had some of them even back then via 3rd party tools, but isn't that essentially what modern Windows has become? There are ways to revert some Windows 11 features today with alternative shells and such, so is that the ideal UI then?
The classic theme survived up until Windows 7, and I'll give that a pass, since although there still are holes where the newer design language of Windows peeks through, it's stayed mostly consistent, and even managed to add new features without breaking the design language to fit them.
Then that died with Windows 8, and there's been no hope for consistency in UI language since. The dream of a casual user being able to learn a UI and stick to it is dead, since even if they do, it will just change out from underneath them. That's why they don't even bother. Heck, even I barely bother.
> I'm sure that I couldn't stand using its barebones UI today, as much as I would enjoy the simplicity for a brief moment.
I disagree. I don't use many modern UI features, and the few that I do use, like snappable windows, are things I can imagine working within the old design language. I still write documents using a copy of Word 2000 in a Win2K VM every now and then, and when I don't use that, I use LibreOffice, a program many people refuse to use because it looks ancient to them. That's a feature for me. It not changing and thus not breaking my workflow is a huge feature that nothing in Windows 11 can even hope to compare with.
MS may not have been as tasteful as MacOS, but the functionality was at least there and it was easy to find and use. That goes a long way to make up for the bland-ish look.
Then we lost even more taste, and eventually the functionality and user friendlyness, on both sides of the isle.
I love the idea of hardware keys, and would absolutely use them for the essential stuff (email, domain registrar, bank) but they're just too expensive, while plain old TOTP 2FA is free and provides 99% of the benefits for my use case. TOTP also has a much better workflow in my experience, but this isn't that big of a problem for the things I'd consider essential, but it would be annoying if I were to use a hardware key for everything.
I can buy 6-8 physical keys for the front door of my house for the cost of one Yubikey. Even though there are options at half price, that then gets eaten into by the need to have two or three of them, since a backup is not optional for this sort of use case. I can't imagine convincing one's parents to buy 'a key for your email account' will be easy when the old way mostly 'worked fine' and was free, meanwhile the new one will cost them a non-trivial amount of money. It's an easy flow if you're their sysadmin, but I wouldn't want to throw my parents into the deep end of hardware keys and have to explain to them that they don't need the expensive one, but still have them be discouraged by the mere existence of 100+ dollar options for what should be damn-near throwaway hardware.
Passkeys somehow manages to have a worse workflow than both though.
> For a random website, no, for bank and primary email (used for account recovery), they probably should.
Even for this, for grandma, this is probably still asking for a lot.
Grandma's bank will have a recovery option even if she's tossed her phone, computer and hardware token in the ocean, and then had a stroke which made her forget any passphrases or whatever: You can call the bank and physically authenticate yourself with a passport, driver's licence or some other ID. It's a bitch to do, you may have to go to an actual bank branch, but grandma will get access to her money again. Meanwhile, her access to physical mail doesn't stop just because she's forgotten some passphrase or lost her phone.
Even techy people get caught out by Google forcing 2FA, while casuals don't even consider the possibility of losing access to their email. While both the rhetorical you and grandma both should probably have a bulletproof recovery option for their email, since it will be the foundation of their digital identity, getting them to acknowledge the problem is going to be hard, and the solution, paying for a Yubikey or some other house of cards solution, is a tough sell.
