Taking Screenshots

Staging

Consider the object boundary of an artwork when taking screenshots: what belongs to the artwork, what parts of its environment are essential to understanding it, what do you want to focus on? One rule of thumb is that if an object moves or can be moved independently onscreen, it may be separated from its surrounding environment for the purposes of a screenshot. For example, In the case of a file icon, the desktop background does not need to be part of the screenshot. Conversely, a website cannot be moved independently of the browser window frame, and so this frame should be included in the screenshot. In some cases, items that may be moved independently are still deeply connected to their surrounding environment. For example, a GIF animation that can be found on many different websites should be screenshotted on many different websites to express its objecthood.

Regardless of how the object boundary is drawn, it is important to make sure the image is visually bound. Some operating systems present their windows “chromeless,” without visually expressed user interface elements at the windows’ borders; a website with a white background will just blend into the paper it is printed on. If applicable, include drop shadows, scroll bars, status bars, and other elements on the screenshot that help to visually define unambiguous borders.

Pay attention to relations of pixel dimensions, consciously chose zoom levels and window sizes: art on screen does not have a fixed physical size, but is created in relation to the dimensions of other common elements, such as a mouse pointer, file icons, common interface widgets like buttons or text input fields, default system fonts, notification icons, etc. Do not full-screen a window if you want to get a screenshot just focused on the contents of that window. Reflect on the conditions the creators of an artwork were assuming: Were high dpi screens (“retina” in Apple speak) available at the time? Was the object designed to fit in the scenery of a software environment, or does it try to capture the whole view? Avoid taking screenshots of upscaled bitmap graphics, it will introduce undesired blur. If you are looking at a web page made in 1998 (when people used 800×600 pixel screens with a diagonal of 15”), on your new 2020 Microsoft Surface laptop (3000×2000 pixel screen with a diagonal of 13.5”), it is extremely likely that legacy graphics are being scaled up. If you are unable to (temporarily) switch to a fitting screen resolution or use an emulator when legacy pixel dimensions are required, annotate the screenshot accordingly.

Web pages

Websites are not fixed, self-contained items, they are always actively rendered by a browser. Include the browser in the screenshot; on a desktop operating system, snap the browser window. It might seem not important, everyone knows how a browser looks; but in a year’s time, the memory of that particular browser version will already have faded away.

Make sure the full URL is visible on the screenshot. If you absolutely have to use Safari, which by default just displays the domain name part of a URL, change the setting so it does display the full URL. The URL is an important part of a web site, not just some arbitrary address; it signifies ownership and control, and is often subject to artistic choices.

Annotation

Annotate screenshots with the time the artwork was created, the time the screenshot was created, and note relevant parts of the software environment that are responsible for rendering the object. For a web page this includes the browser (that composes the legible object of a web page from remote resources), any critical plugins (that are required to display specific media types not supported by the browser), and the operating system (providing typeface rendering, image scaling, default user interface widgets, etc). Use “and” to list software components, “on” to note the operating system. If you’re running some operating system hybrid, like WINE or WSL, use “for” instead of “on.” Also list the URL for web pages, so readers have the ability to compare how the site looks with setups available to them.

Examples from Rhizome’s book The Art Happens Here:

Victoria Vesna, Bodies© INCorporated, 1996. Screenshot, 2018, Netscape Communicator 4.7 and Cosmo Player 2.0 on Windows 98, http://archive.rhizome.org/anthology/bodiesinc/home/vrml.html.

Harm van den Dorpel, Death Imitates Language, 2016. Screenshot, 2018, Google Chrome 70 on Android 8.1, https://deathimitateslanguage.harmvandendorpel.com/.

DIS, DIS Images, 2013. Screenshot, 2017, Google Chrome 63 on macOS 10.12, http://disimages.com/.

Laura Brother’s profile page on Computers Club. Screenshot, 2018. Epiphany 3.28 on Linux, http://laurabrothers.computersclub.org/.

Electronic Disturbance Theater, FloodNet, website for April 10, 1998 action. Screenshot, 2016, Netscape Communicator 4.8 for Windows, http://archive.rhizome.org/anthology/Flood-Net/april10v2/zapsTactical/zaps.html.

Data handling

Create the screenshot with a tool that writes lossless images. Opt for the PNG format; avoid JPEG. A PNG image preserves the color and position of every pixel as-is; JPEGs can introduce artifacts and distortions that significantly can alter a web site’s appearance. User interfaces are not lens-based photography!

Also avoid archivists’ favorite image format TIFF: unless you, and everyone you work with now and will work with in the future, know exactly what they’re doing, you might end up with TIFFs that actually embed JPEGs, or store screenshots in CMYK colorspace that is designed for printing (instead of the RGB colorspace that screens work with). It’s not worth it, use PNG.

Do not collect or manage screenshots by pasting them into other tools, like Microsoft Word, PowerPoint, Google Docs, etc and do not transport them as PDF. All of these actions possibly introduce unwanted lossy compression or scaling of the image data.