The idea of getting Mr Macintosh instead of a menu occasionally would be UX nightmare. But there could be other cute places to include it, like occasionally it's present inside About My Mac or whatever.
Mister Macintosh (2004)
21–30 of 59 posts
Re: Mister Macintosh (2004)
#22I wouldn't have liked this. I don't want any part of my computer to be eerie or mysterious. I also don't want there to be anything romantic or mysterious about my bank account. If this had been deployed and its existence has been widely publicized and described right after its deployment (which seems likely to me even if Apple tried to suppress it) the only deleterious effect on me would have been my wasting a little…
definitely seems like some people would have perceived it as a virus having infected their computer, although 1984 was pretty early for virii
This was definitely the "no arrow keys because we have a mouse" era of Apple. Everything we take for granted today was still in flux, and I can certainly imagine that even by the Macintosh 512k, just enough dust had settled that Jobs had reconsidered the idea of intentionally non-deterministic OS behavior.
Re: Mister Macintosh (2004)
#23Sort of like a reverse Clippy, which you do find easily and wish you wouldn't. Generally speaking, programs used to have more Easter eggs. I can't recall a single one in the cloud era. The only one remotely whimsical is PostHog.
The lack of Easter eggs in programs I feel like is a combination of 3 things
1) more “professionalism” being expected in software. Computers aren’t quirky things anymore they’re “serious business” and “serious businesses don’t do quirky”. Or some other such nonsense.
2) Offense risk, something innocuous has serious potential to be taken wrong now or even at some future date. I worked on a system where we needed to impose some effectively arbitrary max limit on the number of items allowed to be configured. We eventually settled on “640k” and originally had an error if you exceed that that said “640k ought to be enough for anyone”. The devs who would have seen that message would have gotten the reference and hopefully had a good chuckle. But I’ve seen customers get short about innocuous jokes before and could easily have seen someone complaining that we weren’t taking their needs seriously.
3) Security liability. A lot of Easter eggs were distinct code paths or sometimes even entire tiny embedded applications. In an ever connected world where your credit card terminal might be the gateway to your entire customer database, any unnecessary code path is also a potential security hole and risk. No one really wants to be in the news because a cute joke their developers put in 4 years ago was the key to a massive exploit.
Still I do agree that I miss some the “personality” older software could have.
Re: Mister Macintosh (2004)
#24Sort of like a reverse Clippy, which you do find easily and wish you wouldn't. Generally speaking, programs used to have more Easter eggs. I can't recall a single one in the cloud era. The only one remotely whimsical is PostHog.
They're security issues, that's why. Microsoft used to have fun ones in Windows and Office (including a Doom-like engine in Excel 95) but in the late 90s or early 2000s they were all taken out by corporate fiat, because they don't add value and may contain security vulnerabilities. Since then, Easter eggs in user-facing software were rare (except for maybe Google Search's "do a barrel roll" and that).
Re: Mister Macintosh (2004)
#25It is fun to read these small stories about Mac OS/Apple. I think for Windows world we have https://devblogs.microsoft.com/oldnewthing/author/oldnewthin...
Not sure if other OS are covered in such a "storyful" ways or have tidbits like this?
Re: Mister Macintosh (2004)
#26Sort of like a reverse Clippy, which you do find easily and wish you wouldn't. Generally speaking, programs used to have more Easter eggs. I can't recall a single one in the cloud era. The only one remotely whimsical is PostHog.
"I can't recall a single one in the cloud era ..." Our PCI compliance page is an easter egg: https://www.rsync.net/resources/regulatory/pci.html
I envy you having written this, because I've wanted to do the same. I'm the adhoc IT guy / CISO / etc. for a small medical practice. I have to jump through the PCI hoops quarterly because it's an ancient junk relic of a time where Infinite Trust Networking and monthly forced password rotation were en vogue.
And why do I have to do PCI stuff? Because we have a credit card scanner that patients use to pay for things. In any sane world, compliance would be on the manufacturer of the scanner: "hey, make devices that actually, you know, encrypt stuff reliably". But since we don't live in that world, I have to have a separate Ethernet drop to the card scanner, which plugs into its own dedicated port on the firewall, which completely segregates it from the rest of the LAN traffic. That isn't horrible in concept, but why? Our servers which store PHI don't have those stringent requirements, because the servers are secured. They don't have to trust that the network is kind and gentle, because they're designed with the idea that it's not. But not so the credit card scanner!
For extra fun, we also have to pay someone to run a PCI compliance scan against our external IP. Said IP listens on exactly one port: the one that doctors use to VPN into the office so that they can check their schedule from home. We got a failing score one year because the VPN appliance supported — not required, but supported — some less-than-perfect crypto algorithm. None of our clients were configured to use those protocols. I know. I configured them. But because the server supported them, we were temporarily[0] judged to be noncompliant because some attacker could, I don't know, hack in and pivot in to the firewall appliance and from their pivot to attack the poor downtrodden credit card scanner which, of course, can't be expected to defend itself from the hostile environment of doctor's office LAN.
PCI's a joke.
[0]It would be against the scanner's ToS to temporarily block that port in our inbound firewall long enough to get them to shut up about it, so I totally did not do that.
Re: Mister Macintosh (2004)
#27Sort of like a reverse Clippy, which you do find easily and wish you wouldn't. Generally speaking, programs used to have more Easter eggs. I can't recall a single one in the cloud era. The only one remotely whimsical is PostHog.
I feel that GNU Terry Pratchett is a cute little harmless easter egg that can be easily implemented: https://gnuterrypratchett.com/
https://www.theregister.com/ have it for instance.
Re: Mister Macintosh (2004)
#28I bring this story up all the time. It's tragic that it was never implemented! I know you could read it as a story about CEO capriciousness, but to me it highlights how far Steve was willing to go to make the Mac playful and enjoyable. Back then, even the idea of dragging a file into a little trashcan was delightful.
they could’ve implemented it in the 128k rom but I think jobs was gone by then
Imagine the rumors that a remnant of Steve still lived on in the Mac, via some as yet unidentified unremoved OS code.
Re: Mister Macintosh (2004)
#29Sort of like a reverse Clippy, which you do find easily and wish you wouldn't. Generally speaking, programs used to have more Easter eggs. I can't recall a single one in the cloud era. The only one remotely whimsical is PostHog.
Discord has lots of Easter eggs, presumably because of its gaming origins.
Re: Mister Macintosh (2004)
#30Texaco Towers was an Apple office above a Texaco gas station: https://www.folklore.org/Texaco_Towers.html
Strictly speaking, it was a two-story building behind the Texaco station: > There was a Texaco gas station at the corner, and a two-story, small, brown, wood paneled office building behind it, the kind that might house some accountants or insurance agents. Apple rented the top floor, which had four little suites split by a corridor, two on a side. Because of the proximity of the gas station and the perch on the secon…
Tymshare! What kind of work did you do for them?