What can be done to preserve the history of digital design?

Question

I have recently moved, so I went through the process of deciding what to keep, what to donate and what to throw away.

One of the things I kept was a banker's box full of examples of my print and packaging designs. I might never use them but I thought it was a neat idea to keep examples of my work.

One of the things I threw away was a box of old floppy discs. They contained a copy of my "graduate thesis". Although they brought back memories and made me shed a tear, there was no point on keeping it since I don't own a floppy disk drive and, even if I had one, knowing how unreliable floppy discs are, I am pretty sure that by now they are unreadable.

This exercise made me think on how fragile and volatile digital design is. Websites, software and digital imagery get replaced and upgraded at a very fast pace nowadays. True, sometimes their old versions get backed up for future reference but very often the storage medium used for the backup becomes obsolete, defeating the purpose of archiving.

One can always print versions of digital imagery, of course, but dynamic design pieces, such as a responsive website layout or an SVG animation, cannot be easily archived or communicated in printed form.

It frightens me to think that one day all this design effort will be gone and impossible to recall, like the hypothetical poly-chromatic façade painting of the Greek temples, washed away by the rain and gone down the drain.

So, my question(s) are:

• What can be done to preserve the history of digital design for future generations?
• What would be a good way of archiving dynamic design pieces in a way that does not become obsolete?
• Is it pointless to do so?

Answer 1

I tend to keep everything digital.

When floppys died I moved everything to Zip disks.

When Zip disks died I moved everything to a hard drive. (considered moving to Jaz drives but was wary of yet another external format at the time)

When CDs started to fade, I moved all CD content to hard drives.

Primarily because by that time hard drives grew 10x+ times in capacity and dropped 10x times in price.

I then simply filed the old work in my archives.

Technologies change but overall file structure hasn't really changed that much. A Photoshop 2 file can still be opened by Photoshop today. Just as an Illustrator 88 file is still a valid vector file. HTML is still HTML and any web site built is a built site so all the technologies needed are there in the build. While older sites may use things like PHP3, they could be upgraded if needed or simply paired down or dummied up to render the front-end properly if needed.

Some file structures are dead though. I did, at one point, simply "move on" and trashed all my Pagemaker Files. There was no hope of opening them at the time and no point in trying to regenerate them. Same held true for many QuarkXpress 2-3 files. There just wasn't any added benefit to retaining those files. So, the desire to save the work was outweighed by the actual usefulness of the file structure. Today, a great deal of my print work is saved to PDF for one reason or another. Storing PDFs means they should be visible for many, many years to come even if someday InDesign dies.

Essentially, if I can open the file today... I keep it.

I, personally, have never found a reason to just throw away any digital work other than what's mentioned above. HDDs are dirt cheap and it costs nothing to store them. However, for the most part, I retain all this more for nostalgia than anything else. It's rare I need to go back and pull up a design piece for any practical reason. Artwork is another matter though. I still go back and use artwork I created 20 years ago. I'll update it, refresh it, alter it and then use it if it fits a piece.

The only thing I've ever lost digitally was a SyQuest disk because there was no way I was going to buy a SyQuest drive for one disk and the content on it wasn't imperative.

Imagine if Picasso never kept his sketches? (Not that I'm anywhere near Picasso). I often find value and inspiration from older work when I'm blocked. It not only brings me back to that design sense but recalls the time in my life when the piece was created which can lead to further inspiration.

I'd love to see early work from Glazer, Bass, Rand, Tharp before their names were "known". I don't begin to compare myself to that, but preserving one's own history is somewhat imperative to me.

Also be aware, I have, on extremely rare occasions, had a client contact me a decade later looking for artwork or updates. It can happen. Although I'd not feel obligated to have their artwork at that point.

Answer 2

You have a few things that you need to be concerned about preserving. When we talk about digital preservation, we typically are concerned with:

1. The physical media. This is handled through what's called a 'media refresh', typically done every 5-10 years, depending on the type of media. You read everything off of the older media, validate it against the checksums (that you hopefully stored in multiple locations), and then write it all back out to fresh media. This is typically known as 'bit preservation', as you're only concerned with the digital file existing as it has before, not if you can actually read it or not.

2. The file format. You need to make sure that whatever format the information is stored in can still be read. This might mean opening up the files in a newer version of the software and saving it again, or writing it out to a different file format. In some cases, we archive both the original and a few varient forms. (see note below re: museums)

3. The software / operating system / hardware. There are cases where projects may be tightly tied to to the software or hardware on which it runs. (eg, Doomsday Project. If you have something in HyperCard or other software that no longer exists, you might have to archive the software, a virtual machine that can run the software, plus an emulator for the hardware. In some cases, there are groups that are specifically archiving old hardware, but it tends to be for cases where they have lots of software that all needs the same hardware (such as the UT Videogame Archive). If you're trying to re-create the experience of an early video game, the monochrome monitor and buckling spring keyboard may be as much of a part of the experience as the software.

   And remember, if you're archiving a website, you'd want to not only archive a VM with the fully functional server, but you also need to archive browsers from that era which will interact with them properly, as we have cases where certain features are deprecated (<flash>, multiple <title>s, lowsrc ) or on the way out (XLST). You might also need a proxy to recreate the appropriate network speeds (ie, dialup), to set the proper context.

Which gets us into the question of what it is that you're actually trying to preserve.

Although some museums will make replicas of items to go on display, and the Smithsonian has started 3D scanning items, most museum digitalization projects are actually taking images of objects or other recordings (audio, video, etc.).

If you just need the basic look of your work, and not the interactive aspects, you might want take screen shots or generate PDFs of specific portions of the work. You should document/catalog those images to explain what specifically you're trying to show in the image. You could also capture video of typical usage, or the specific interactive components that you most want to highlight for your portfolio.

So remember -- trying to capture the 'essence' of the work is fundamentally different from trying to capture the 'bits' of the file, which is different from trying to ensure future use of the 'content' of the file(s). You need to decide what it is that you're trying to preserve, as that will affect what you preserve, how you preserve it, and how you catalog it for future use.

Note : There have been both Digital Preservation and Library SE sites through the years, neither of which made it out of beta.

Answer 3

You can't easily preserve digital files for a few reasons:

• physical media becomes outdated
• software becomes out dated
• systems to run said outdated software becomes outdated

Not that you shouldn't back up data, of course. 'The Cloud' makes this a little easier in regards to the physical media issue. You still have the other two issues, though. For example, I have a lot of Freehand files on Syquest disks. Not only is the media out dated, but I don't have a copy of Freehand and, even if I did, I have nothing to run it on.

So, bottom line, the best way to archive work for posterity is to find a long lasting medium. One medium is slide film. It's small, can last a long time if properly stored, and requires no special hardware or software to view it.

All that said, there's also the 'why hold on to stuff you don't need' argument. Like the physical world, we humans tend to collect detrius in our houses as well as on our laptops. Maybe it's best both practical and psychologically healthier to just let it go. :)

Answer 4

Digital archiving is hard. You have to plan to overcome the technical barriers. So the media needs to be refreshed periodically to avoid becoming obsolete you also need multiple copies to avoid bit rot. Digital stuff rarely survive even small partial corruption. So redundant store is a must.

Files should rely on standards as those are easier to reproduce later, they are better documented and the documents can be stored side by side with the data (Standards atleast more mature standards bodies allready archive). The other strategy is to archive the executable. This may be hard for properitary things, licencing is a bit problematic for ancient versions. (so dont expect to use 15 year old photoshops, certainly not creative cloud). But you may need to go further and virtualize the entire os. Webpages may be hard to archive for this reason but easier because they are text (text standards also change, slowly, so prepare to resave the streams)

Another strategy is continious refreshing, so you continiously maintain the file. Upgrade to current versions, and fix things when they break. This may be very expensive. But can be worth it. Apparently pixar used this strategy. To increase sales value. A graphics designer also should do this as clients may come asking for some of these later.

Answer 5

Clearly digital technologies introduced ipso facto some very interesting concerns in terms of preservation. Without entering the old paper vs digital debate, it's true that we are still able to read some ancient egypt papyrus when some CDs we burnt only a few years ago are not readable anymore.

This preservation paradygm relies on two aspects. First of all, the maintenance of the tools to read those digital supports. As you noticed, who kept a Floppy Disk reader by these days ? On a personal note, I can't remember the last time I used my CD/DVD reader on my laptop. The second of all is that given that technologies sooner or later are deprecated, you need to port data from one technology to another and this conversion may affect the nature of the data. Given an image, some render may differ from time to time depending how it's converted from device A to device B. That repeated decades after decades. What will be left from teh original material. How truthfull will be the material you will look at in a thousand years from now ? Digital has brought many amazing things but also weakness. Our hard drives can fail, our CDs may be corrupted by scratches, sunbeams, heat…Yeah that's also true with paper. A book can burn, be swamped…But still, paper is more solid in terms of times. To conclude, teh most interesting technologies I see for digital preservation are those open sourced and based on an easy to read and recreate supports like ones expressed in XML. The more it's proprietary, the biggest is the risk to loose data.

Answer 6

The situation is not nearly as dire as you think. The problem you have is solved by WorldWideWeb. More specifically, by W3C HTML5 and ISO MPEG-4.

Preserving documents is what W3C HTML5 and ISO MPEG-4 are for. It’s why they exist.

HTML5/MPEG-4 are not just to enable you to share your documents across space, but also across time. That is because the decoder for HTML5 is a tiny piece of software that is totally standardized and totally cross-platform and is carried forward into future HTML decoders. The decoder for ISO MPEG-4 is also totally standardized and is built into every single hardware device in the world that can play audio video, and will be carried forward into future MPEG decoders. (But wait, the MPEG-4 patents! They expire in something like 2022.) Both HTML5 documents and MPEG-4 media are served from a Web server which is a tiny piece of standardized open source software that sends the document over the Internet via standardized HTTP. So your HTML5/MPEG-4 documents will be readable by future generations, even if they are using HTML15 and MPEG-10.

There is also ISO JPEG for photos. Works just like ISO MPEG works for audio video, and for all intents and purposes you can consider it to be part of HTML5 and/or MPEG-4.

Notice all the instances of “standardized” in the above. That is in stark contrast to various kinds of floppy/optical disks, FreeHand documents, physical media, print media, HTML4 (has plugins,) HTML3 (is not Unicode,) Flash, Director, Word, Excel, PowerPoint, PSD, etc. etc. Those are all temporary formats. You can work on a FreeHand document all day, but if you don’t create an SVG of it and put that on a Web server, it won’t outlive you.

So whatever documents you want to preserve, create HTML5/MPEG-4 versions of them, and store them on a standard Web server. Also keep a copy on your current computer. Also keep a local backup of that computer. Also keep a cloud backup of that computer. Then move all of those copies forward to your next computer. The truth is, your floppy disk data should have moved onto your first hard disk, and then onto successive hard disks, and then recently onto SSD.

Whatever you are creating today, you should primarily be creating an HTML5/MPEG-4 version, and aware throughout the whole process that your Illustrator or Word or Final Cut documents are just a bridge to get to a final HTML5/MPEG-4 version that represents your actual published work. Same as a graphic artist in 1995 was primarily creating a print brochure, and was aware that the FreeHand document they were working in was just a bridge to that print document.

There is an issue with keeping the Web server containing your archived documents online in perpetuity, but that is more financial/logistical than technical. In theory, part of your life insurance policy could be dedicated to purchasing a T-bill that pays out enough every year to keep your Web server online. Or you could buy such a T-bill right now.

Some example media from the question and answers above:

• graduate thesis or any text document (e.g. Word) ➡ convert it to a semantic HTML article

• FreeHand file or any graphic ➡ convert to SVG graphic

• print photos ➡ convert to high-quality ISO JPEG

• print documents ➡ Web documents (print is obsolete now and has been replaced by Retina Displays and gigantic billboard screens)

• VHS video, DVD (MPEG-2,) MPEG-1 ➡ convert to ISO MPEG-4 H.264

• Compact Cassette audio, DAT audio, CD audio, MP3 ➡ convert to ISO MPEG-4 AAC

• animated graphic (e.g. GIF) ➡ convert to animated SVG

• interactive animation of any kind ➡ convert to interactive HTML5 animation (Tumult Hype is a great tool for this)

• legacy computer application (e.g. BASIC or FORTRAN) ➡ convert to HTML application (e.g. JavaScript)

… the list goes on and on, because there is always a way to convert legacy media into modern HTML5/MPEG-4.

There is an old digital saying: “if you only have one copy, it doesn’t exist.” That covers the data loss part of archiving. You can’t put some data onto just one computer and rely on that computer not to fail or be stolen or lost. You have to make multiple copies to ensure you can actually get the bits off later when you want them. But there is also a second part to that: “if you don’t have a standardized document, it doesn’t exist.” So you can have 8 copies of a FreeHand document at 8 different locations, but then you try to read it and you don’t have a functioning version of non-standard FreeHand, so your documents also don’t exist. The standardized document formats are HTML5/MPEG-4.

So to put it all together: if you don’t have multiple copies of your document in HTML5/MPEG-4 format, your document doesn’t exist.

There is also one other archival issue, which is whether or not a future generation can actually understand your document. For example, if the text of your thesis reads “the test subject is 5-foot-4” then the vast majority of human beings who are alive today can’t understand those already-antique measurements, and even fewer of the next generation and the one after that will understand. In the same way we have ISO video and ISO photos, we also have ISO measurements. So you need to replace “5-foot-3” with “160 centimeters” and “32 degrees Fahrenheit” with “0 degrees” and “2 miles” with “3.2 kilometers” and so on. But that is true even if you are just publishing something on the Web today that expires a year from now. We also have ISO time formats (YYYY-MM-DD) and so on, which you should use in your document and then optionally, you can use scripting to localize it.

If you are skeptical for some reason, you can watch 13+ hours of 1980’s music videos on YouTube:

1980’s Playlist

… which are being served to you as HTML5 pages with MPEG-4 video in them. Likely these songs and videos predate all of the media you are thinking of archiving.

Or a playlist of 1970’s music:

1970’s music hits playlist

… or let’s go back to the 1940’s via HTML5/MPEG-4:

Big Band / Swing / Jazz 1940’s

… or look at a photo from 1953 which lives on as ISO JPEG in an HTML5 document:

The Forces Show, 1953 (BBC Archives)

… or a Mac Plus which was hardware in 1985, but which lives on today as an HTML5 document:

Mac Plus Emulator

… it goes on and on.

So WorldWideWeb is full of old stuff that not only predates many of the people who are alive today, but also predates WorldWideWeb.