Crowdsourcing 404s

Engaging your audience in an unlikely place

By Hannah Baker

May 26, 2023

For Cogapp’s 23rd hack day, we teamed up with the Art Institute of Chicago, who have a great API that provides JSON-formatted data, allowing developers like us to integrate the museum’s public data into our own projects. This API is the same tool that powers the AIC website.

For my project, I decided to tackle the age-old problem of the boring 404 error page and come up with a solution to make a (marginally) funner experience for a user who finds themselves lost on a website.

My idea was to ask users who encountered a 404 page to decide whether a random artwork from the AIC’s collection was relevant for such a page. For instance, if the user deemed the artwork to have a theme such as lost, missing, fail, oops, cry, or sad, however tenuously, they would be asked to provide a (preferably humorous) sentence to fill in the blank at the start of this statement: “_________. Sorry, we can’t find that page. You’ll find loads to explore on the home page.” (A bit like playing the 1950’s party game Mad Libs). This sentence would then be displayed alongside the approved artwork on future 404 pages.

As the AIC’s API provides access to over 100,000 artworks from the museum’s collection, I decided to whittle down the sample of artworks to those that hadn’t been viewed much. I thought this would be an interesting way to highlight some of the AIC’s lesser seen works, and luckily, it was easy to achieve this because the API includes a ‘has_not_been_viewed_much’ key.

So, I structured my API call to only return artworks that haven’t been seen much and are in the public domain, and to only return the key pieces of information I needed for my project, which were the artwork id, image id and title. The results from my API call looked like this:

  "data": [
  {
      "_score": 6.8850713,
      "is_public_domain": true,
      "has_not_been_viewed_much": true,
      "id": 59819,
      "image_id": "30dff056-2127-efac-3438-0e46c697fecd",
      "title": "High Chair"
  },
  {
      "_score": 6.8850713,
      "is_public_domain": true,
      "has_not_been_viewed_much": true,
      "id": 148350,
      "image_id": "d23cd8a0-f54b-366d-3c50-955f9889eaf5",
      "title": "Female Figure with Two Joined Heads"
  },
  {
      "_score": 6.8850713,
      "is_public_domain": true,
      "has_not_been_viewed_much": true,
      "id": 90312,
      "image_id": "340ce78b-cf17-6818-7311-1ab2fdbf4e57",
      "title": "Vision"
  },
  {
      "_score": 6.8850713,
      "is_public_domain": true,
      "has_not_been_viewed_much": true,
      "id": 44750,
      "image_id": "96cb8426-330a-ac3c-ba9d-172d9e78b9ce",
      "title": "Madonna and Child on Clouds"
  },
]
                                  

Once I had this data, the next step was to think of a way to gather and store the user input. I decided to use a simple form to capture the user’s decision and their comical accompanying sentence for the artwork. As my time was limited, I focused on functionality over style and design, so this was the end result of the form (I know, it’s not very pretty):

A simple, un-styled form in a web browser — A simple form to capture the users answer

If the user didn’t think the artwork was appropriate for a 404 page, they had the option to say ‘No’ and the artwork would be permanently discarded, never to be seen on a 404 page again (cue dramatic music).

Underneath the form, I wanted to display the artwork in as high a quality as possible, along with the artwork title — both so that the user knew what the artwork was, and to help provide them with inspiration. As the AIC offer IIIF manifests for all of their public domain artworks, I was able to display a high-quality copy of the artwork very easily. The IIIF manifests follow a standardised API, meaning they can be used with any IIIF-compliant tools, and I chose to use OpenSeadragon.

To display the artwork in an OpenSeadragon viewer, I simply pulled in a random artwork from my data sample and injected the artwork id into the AIC’s uniform IIIF manifest URL and used that to generate an OpenSeadragon viewer:

  // Generate an OSD viewer for a provided artwork, and display in the relevant container
export function generateOSDViewer(artwork, id) {
    // Construct the manifest url 
    let manifestUrl = 'https://api.artic.edu/api/v1/artworks/' + artwork.id + '/manifest.json';

    // Fetch the IIIF manifest
    fetch(manifestUrl)
    .then(response => response.json())
    .then(manifest => {
        // Extract the image URL and tile information from the manifest
        var imageUrl = manifest["sequences"][0]["canvases"][0]["images"][0]["resource"]["@id"];
        var tileWidth = manifest["sequences"][0]["canvases"][0]["images"][0]["resource"]["width"];
        var tileHeight = manifest["sequences"][0]["canvases"][0]["images"][0]["resource"]["height"];
        
        // Construct the OpenSeadragon tileSources object
        var tileSources = [{
          // ...construct tileSources object here...
        }];

        // Create the OpenSeadragon viewer with the IIIF manifest as the tile source
        let viewer = OpenSeadragon({
          // ...create OpenSeadragon viewer here...
        });

        return viewer;
    })
    .catch(error => console.error(error));

}
                                  

Adding this to the page allowed the user to see a high resolution display of the artwork with the ability to zoom in and out, and to move around the artwork to see different areas in more detail:

An artwork depicting a woman in Victorian clothing, shown in an OpenSeadragon viewer — ‘Mrs. Vanderveer, or Mrs. Vandeveer’ artwork in OpenSeadragon viewer. The artwork is public domain.

For the hack day, I wanted a quick and easy way to store the data, so I opted to store the user-approved artworks and sentences in the browser’s local storage. This approach wouldn’t work in the real world, as the data would need to be stored in a centralised location so that the list of approved and discarded artworks would be the same for all users, but it was a quick way to spin up a demo ready for the 4.30pm deadline, so I went with it.

Assuming at least one artwork has been approved, then each time a user encountered a 404 error they would either be shown a 404 page with a randomly selected artwork from the approved list along with the accompanying sentence, or they would see the form with the ability to vote on a new artwork. If it was the latter, they could then decide whether it should be stored to be enjoyed by future lost users or permanently discarded as it was off-topic for a 404 image.

I certainly had fun testing the project and trying to come up with sentences for some artworks. Admittedly, I’m no comedian but here’s an attempt that made me chuckle:

A 404 page showing a sculpture of a woman with two heads, and the sentence: Let’s put our heads together and figure out what’s happened here… Sorry, we can’t find that page. You’ll find loads to explore on the home page. — An example 404 page with the sculpture ‘Female Figure with Two Joined Heads’. The artwork is public domain.

I warned you, I’m no comedian.

I had a great time working on this hack day project and I was happy with the end results, although there are certainly some updates and enhancements that would need to be made in order for it to be a viable feature on a real life website. For instance, as mentioned previously, the data would need to be stored in a centralised location (not in local storage) and the owners of the website would need to have the ability to monitor and approve the sentences accompanying the images (to weed out any dull or inappropriate entries). However, it would be exciting to see users actively engaging with and shaping the content of a website, so it could be a feature worth improving and refining in the future.

So, the next time you encounter a dull 404 error page, remember that there are some kind people out there working hard to make them less boring.

Have a go with the live demo, or take a look at the source code.