I really appreciate that someone's job (or at least part of it) was to "prototype concepts that would add some interactive sparkle to the site". Working on a larger team, we generally add this kind of interaction at the start of a project or during redesign. There are larger prototypes, of course. But very rarely is someone designated to independently go out and just find small ways of making the experience just a bit nicer for the users, and build that; and I really like that idea.

That’s my site. I’d be happy to answer any questions you might have about it.

Since this is about old iPod technology, I thought this might be interesting here:

I’ve been working on getting the real Apple iPod Classic 6G firmware running in QEMU. It currently emulates two clickwheel iPods, including the display ,click wheel input and music player.

https://github.com/davidmonterocrespo24/qemu-ipod-classic

Still a work in progress

> We obviously have much better ways of doing such things today, but in 2005, with limited browser technology, those solutions seemed a little bit magical

Nah, this still seems like a pretty good way of doing things. Yes, we can probably run the image engraving on the client now, but to address a wide audience of older devices, we probably shouldn't change very much about this process.

> The engraving was created using imagemagick, which took the user’s text and returned an “engraved” image to be overlaid on the rear of the iPod.

Couldn't this be handled client-side, just overlaying plain text in gray 'Helvetica, Arial, sans-serif' on top of the image? At this scale, the specific font doesn't matter.

Although interestingly, Apple still renders the text server-side (and offers engraving only for iPads, apparently): https://www.apple.com/shop/preview/engrave/PH304LL/A?th=hell...

The article mentions the 'yellow fade' or 'yellow flash' to highlight when elements change -- I miss that!

We all want to be able to afford to do what Apple did back in 2019. Have a full developers salary dedicated to adding sparkle. I wonder in todays day and age how do you add that level of personalization and differentiation?

I loved the custom engravings. I still have two red iPod shuffles with "STEAL THIS" engraved on them, one I occasionally use, one unopened it its box.

Ironically, the reason I have two is because I accidentally ordered two, didn't realize until I received them…and they were non-returnable because of the engravings.

I figured I'd just give one away as a gift, but this was right around the time everyone started getting smartphones so the opportunity to do so never presented itself.

I used to love that glossy gradient header that looked like physical tabs. Apple used to be so colorful and skeumorephic in their interfaces, I kind of miss that.

I really enjoyed working with imagemagick back in the day. Really did feel like magic to be able to manipulate custom images dynamically.

I wish I could write up short blog posts on some of the past projects I worked on like this, but I am afraid my former employers would not like that

> We obviously have much better ways of doing such things today

Do we?

I mean you can skip imagemagick and use HTML5 canvas, but otherwise I think I wouldn't change a thing.

We have much more complicated ways of doing such things today, for sure.

I think it's worth noting that 2004-2006 was a time period where a Flash applet could have done this on the client. This was also a time when Flash content was supported by Apple QuickTime, so it's interesting that they didn't make use of it here.

I wonder if a SWF was ever hosted on the apple.com domain.

The old demo makes the 2005 constraints tangible; using a yellow fade and server-rendered frames to create that sparkle is still charming.

Sad that it quickly became a dark pattern to reduce resale value, thus increasing future sales.

That’s the real reason it got added.

It is interesting to think about the socio-technical reasons to make a serverside roundtrip for each keypress. Another approach might be to load up the dictionary client-side and use javascript to swap letterforms in various pre-determined locations. Presumably using browser-text with a transparent background wouldn't sufficiently simulate what the real product looked like.

Off topic: why would someone engrave their item? If you or whoever is gifted the item ever decides to resell it some day, it becomes a headache. And I don't recall any other company offer such service for consumer electronics.

Ask yourself, why do apple provide this engraving service free of charge? They would never tell that to you in a million years. It’s because the normal consumer protection laws doesn’t apply if a product has been personalized! A very smart way of steve jobs to circumvent consumer protections, a thing he was actually known for.

It helps that it's not very big. In the working demo, the image is 132x26, and the actual JPEG file size is about 2-4 kB (depending on the text).

So even on a 56k modem, it might take less than 1 second to load each image.

You could also optimize it so it skips intermediate images if the user types fast. Suppose the user mashes "12345" in a fraction of a second. You start loading "1.jpg" on the first keypress. When you've finished loading "1.jpg", the field contains "12345", so skip straight to loading "12345.jpg".

The demo page's JS doesn't seem to include any optimization code like that. It just updates the img src whenever the text changes. Yet my browser seems to do it automatically! If I mash several keys, the console network log shows only some intermediate images get loaded.

I guess the browser is smart enough to know that, by the time it would have started the download, the resource no longer exists in the page. I'm not sure if browsers ~20 years ago did this, but it would have been worthwhile given how slow networks were.

Yes, this is pretty much how we did such things already in the 1990s. The problem with this is that this only supports a predefined, rather limitted character set. But you could have expanded on this and may have loaded custom characters on demand (which would have been a rather small payload for a single character.) But there's yet another problem, namely color management, which isn't supported by GIF (which we need for the transparent background), and they probably really wanted to go with JPEG for this. (At that time, CRTs were still much around and those tended to show greys with a reddish tint when managed badly. Something Apple would have certainly wanted to avoid.)

BTW, here's a PoC (a website from 1998 written in about two hours [so not much of hassle even then] demoing pure JS rendering from a data file, all just classic table layout rendered in the browser, all styled text and the ticker are rendered from single-character images): https://www.masswerk.at/demospace/relayWeb_en/welcome.htm

Basically, it was easier. Or even... barely even possible to do what you describe. Maybe you could, but it would have been nightmarish whack-a-mole, and a good chance that the next update to any given browser would break it completely.

In ‘05, you had IE6, plenty of folks still on IE5, IE5 for Mac was still in use (don’t be fooled by the name - it did not behave like IE5 on windows), safari was 2.0, respectable but still a minority browser, and Firefox was on 1.0. Plenty of folks were still on Netscape navigator, which by that point was actively decomposing.

IE6 was what you built for, as it was the majority browser by a country mile. Transparency was hit and miss. Alpha PNGs just weren’t supported, you had to hack them in via JS.

Most websites were laid out using <table>. Using a <div> was new and exotic.

Oh, and you could only do custom fonts using… flash. sIFR, if you want to delve into the hell that was web dev back then. Most folks would just end up with TNR. Transparency on sIFR you could only achieve by replicating your background into the SWF, and good luck getting it to line up.

So. Support an absolute soup of edge cases across a bunch of different browser engines, and deal with “IT LOOKS NOTHING LIKE IT DID ON THE WEBPAGE” from customers, or just do it server side.

Also, it was perfectly acceptable to wait for a website to load - 50% of the U.S. was still on dialup, and “broadband” was commonly 512k.