Not sure if anyone remembers the height of ecards as a medium, sometime in the early 2000s in the hazy period after broad popularization of the Internet but before the rise of social media -- or if anyone who remembers them does so with any fondness, given what seemed like their overall jankiness and unreliability even at the best of times.
There was always something spammy-feeling about ecards, and receiving one generally involved visiting a page filled with advertising and pop-ups and all kinds of animations and auto-playing audio. Then, if you wanted to go back and look at them later (perhaps after finding a link in an old email), you would inevitably discover that the card content had long since expired. Given that these were obviously not the sort of links that the Internet Archive would ever get the chance to crawl, the content of these cards was therefore permanently unrecoverable. Perhaps, for some, this ephemerality was part of their charm.
Looking back at the concept of ecards a few years ago from the post-social media world brought back a surprising amount of nostalgia (granted, perhaps misplaced) for a simpler time when the default option for sending greetings and well-wishes to a single person was not necessarily to broadcast them to the entire world simultaneously. However, even more surprising was how desolate the ecard industry had become -- at some point someone asked me if there was an easy way to send a card via email and I just assumed it would be as simple as it always had been years before: go to some site and fill out a few details, and then send a link. But the selection was now somehow worse and more spam-filled than before[0]. Websites were heavy and slow and sometimes broken, required accounts or registration, were filled with unnecessary options, animations and (still) auto-playing audio. The sort of sites where you needed to wait while they "loaded" before viewing or creating a card.
I looked around to see if there wasn't already some kind of simple DIY tool that you could run on GitHub Pages or your own server, but couldn't find anything similar. Obviously whatever niche ecards had originally filled was currently being served by other tools: social media, instant messaging, and of course email and paper cards (both of which still exist, of course).
Even if nobody seemed to miss ecards, there were a few things that were always frustratingly inefficient about the whole process of sending and receiving them, and it was an interesting technical challenge to see if all of that was by necessity or not. For one thing, it never made sense -- even at the height of their popularity -- why a third party needed to be involved at all in the process of sending ecards. Of course, you had to store the card content somewhere, most likely a server, and that server probably needed to pay its bills, which then brings us naturally to ads and tracking and monetization...
But what if you didn't need to store the content on a server? I wanted to see if it was possible (or practical) to store all of the card content (including information about the design and images) in the URL instead. Of course, it's fairly straightforward to build a URL with a bunch of query strings containing all the content of the card. However, apart from the question of privacy[1], the main issue for most normal uses of ecards is "giving away" the content of the card before the receiver has viewed it. One of the few remaining charms of the medium that is not already covered by IM or normal email is the slight element of surprise -- the process of opening the card before knowing what it says. For that reason, the query strings have been minimally encoded -- which seems to work fairly nicely, though it does produce rather long URLs.[2][3]
The most important feature of this implementation is persistence -- the cards are "non-expiring" in the sense that even if the server goes down any card link can be imported and viewed on any other instance of the site, or even locally (the site can be downloaded and opened directly using any browser's file:// protocol). An upcoming feature will be to take a snapshot of the card so it can be downloaded directly, probably using the same approach as the "Save PNG" function here[4].
Another aspect that is (in my opinion) also an improvement on commercial ecard platforms is that you can supply your own image for the card. From a (site) design perspective this is nice because it makes it possible to have a bare minimum of default open licensed imagery as a starting point while still having the flexibility to use any other image if needed (Open Clipart[5], even in its current reduced state, works quite well for this purpose in many cases, though any image will do -- photos work nicely too). This also means not having to worry too much about finding or somehow creating an entire library of (possibly quite cheesy) card content for every possible occasion. Most existing sites seem to be organized around "themes" such as particular holidays or festivals, but with this simpler (and more flexible) approach there is a bit more room for creativity. Having said that, one feature on the to-do list is to add themes for specific occasions (or just example starter cards) by creating an API for the "create card" page -- similar to the "receive card" page -- that would load a preset series of values for each available field.
Hopefully, the above will help to answer questions people might have about why anyone would be interested in something like this. TLDR: nostalgia, experimenting with something new, technical challenge of adding functionality without necessitating servers or third parties, and the element of pleasant surprise.
[1]: Privacy is sort of an added bonus here, given that there are exactly zero cookies or trackers or even local storage being used on the site. However I would be very interested to hear from any experts out there if my assumption that content of HTTPS URLs after the domain name is secure in this context is incorrect.
There was always something spammy-feeling about ecards, and receiving one generally involved visiting a page filled with advertising and pop-ups and all kinds of animations and auto-playing audio. Then, if you wanted to go back and look at them later (perhaps after finding a link in an old email), you would inevitably discover that the card content had long since expired. Given that these were obviously not the sort of links that the Internet Archive would ever get the chance to crawl, the content of these cards was therefore permanently unrecoverable. Perhaps, for some, this ephemerality was part of their charm.
Looking back at the concept of ecards a few years ago from the post-social media world brought back a surprising amount of nostalgia (granted, perhaps misplaced) for a simpler time when the default option for sending greetings and well-wishes to a single person was not necessarily to broadcast them to the entire world simultaneously. However, even more surprising was how desolate the ecard industry had become -- at some point someone asked me if there was an easy way to send a card via email and I just assumed it would be as simple as it always had been years before: go to some site and fill out a few details, and then send a link. But the selection was now somehow worse and more spam-filled than before[0]. Websites were heavy and slow and sometimes broken, required accounts or registration, were filled with unnecessary options, animations and (still) auto-playing audio. The sort of sites where you needed to wait while they "loaded" before viewing or creating a card.
I looked around to see if there wasn't already some kind of simple DIY tool that you could run on GitHub Pages or your own server, but couldn't find anything similar. Obviously whatever niche ecards had originally filled was currently being served by other tools: social media, instant messaging, and of course email and paper cards (both of which still exist, of course).
Even if nobody seemed to miss ecards, there were a few things that were always frustratingly inefficient about the whole process of sending and receiving them, and it was an interesting technical challenge to see if all of that was by necessity or not. For one thing, it never made sense -- even at the height of their popularity -- why a third party needed to be involved at all in the process of sending ecards. Of course, you had to store the card content somewhere, most likely a server, and that server probably needed to pay its bills, which then brings us naturally to ads and tracking and monetization...
But what if you didn't need to store the content on a server? I wanted to see if it was possible (or practical) to store all of the card content (including information about the design and images) in the URL instead. Of course, it's fairly straightforward to build a URL with a bunch of query strings containing all the content of the card. However, apart from the question of privacy[1], the main issue for most normal uses of ecards is "giving away" the content of the card before the receiver has viewed it. One of the few remaining charms of the medium that is not already covered by IM or normal email is the slight element of surprise -- the process of opening the card before knowing what it says. For that reason, the query strings have been minimally encoded -- which seems to work fairly nicely, though it does produce rather long URLs.[2][3]
The most important feature of this implementation is persistence -- the cards are "non-expiring" in the sense that even if the server goes down any card link can be imported and viewed on any other instance of the site, or even locally (the site can be downloaded and opened directly using any browser's file:// protocol). An upcoming feature will be to take a snapshot of the card so it can be downloaded directly, probably using the same approach as the "Save PNG" function here[4].
Another aspect that is (in my opinion) also an improvement on commercial ecard platforms is that you can supply your own image for the card. From a (site) design perspective this is nice because it makes it possible to have a bare minimum of default open licensed imagery as a starting point while still having the flexibility to use any other image if needed (Open Clipart[5], even in its current reduced state, works quite well for this purpose in many cases, though any image will do -- photos work nicely too). This also means not having to worry too much about finding or somehow creating an entire library of (possibly quite cheesy) card content for every possible occasion. Most existing sites seem to be organized around "themes" such as particular holidays or festivals, but with this simpler (and more flexible) approach there is a bit more room for creativity. Having said that, one feature on the to-do list is to add themes for specific occasions (or just example starter cards) by creating an API for the "create card" page -- similar to the "receive card" page -- that would load a preset series of values for each available field.
Hopefully, the above will help to answer questions people might have about why anyone would be interested in something like this. TLDR: nostalgia, experimenting with something new, technical challenge of adding functionality without necessitating servers or third parties, and the element of pleasant surprise.
[0]: https://www.google.com/search?q=ecards
[1]: Privacy is sort of an added bonus here, given that there are exactly zero cookies or trackers or even local storage being used on the site. However I would be very interested to hear from any experts out there if my assumption that content of HTTPS URLs after the domain name is secure in this context is incorrect.
[2]: https://dohliam.github.io/ecards/receive.html?i=aHR0cHM6Ly9k...
[3]: Is the above link even clickable on HN? I guess we'll find out -- might need to copy-paste otherwise.
[4]: https://dohliam.github.io/rubify/
[5]: https://openclipart.org/