It’s time for something new

After 14 years we’re hanging up our keyboards. Our team is joining the lovely people at Culture Amp, where we’ll be helping build a better world of work.

Icelab

Using Apple’s Keynote for museum interactives

By Michael Honey01 Jun 2011

We’ve built touch-screen interactives for several museums, and until recently they were mostly built in Flash. These days we’re using HTML5 + JavaScript, but recently a project came up for which the right platform ended up being Apple’s Keynote.

The project, for the National Archives of Australia, features a rich collection of historical documents and photographs relating to the creation of the Australian Constitution, an original of which is in the room next door. Built for both self-directed exploration and small-group guided use, it called for a large, high-quality, robust touchscreen, mirrored to an even larger display. Most capacitative touchscreens are either small (maxing out at 19" or 21") and are built as retrofits on top of monitors from NEC or Dell. They lack solidity, and the bezel isn’t attractive, requiring fabrication to mask plasticky surrounds. We wanted something rock-solid, huge, bright, and sexy. We ended up using a 27" iMac with a TrollTouch touchscreen overlay, and mounted the whole unit at an angle onto a welded steel base using the optional iMac VESA mount. The result is incredibly solid.

NAA interactive in situ

Keynote advantage: superior display

Text rendering on Keynote is beautiful, as is image scaling. Even in the protyping stage, everything looks great. Combined with the 27" iMac (displaying at 1920x1080 pixels rather that the native 2560x1440 – the mirrored 55" display can’t go any higher) the results are simply beautiful. The randomly-bad antialiasing on Flash and frankly poor text rendering on, say Chrome for PC, can’t compete. (On the other hand, Webkit browsers on the Mac render text well, and Safari’s hardware-accelerated CSS animations are super-smooth.)

Keynote advantage: quick prototyping and development

Typically, interactives for cultural institutions come to us after a lengthy period of curatorial content development: our job is to find a way to present that content meaningfully to an audience that hasn’t been exposed to it before. In this case, the sheer amount of content available had to be drastically pruned to make it fit into a reasonable-sized experience. There was also a hard deadline to meet: the interactive needed to be launched in time for the 90th anniversary of the Constitution’s adoption by the Australian people – a date that couldn’t be changed to fit our development schedule. So it was critical that we used a tool that allowed us to quickly prototoype different content approaches, then put them into production without delay.

Keynote excels for this: being able to drag content onto the stage, conform it to master styles, quickly apply transitions and animations, then view the results immediately without compiling means that the interactive design/development turnaround is tight.

You don’t have to be a skilled coder to produce great results quickly with Keynote. That means that content experts can contribute directly to the project by building up stories and rearranging content flow themselves, rather than having to have the whole thing authored by code-capable staff.

Keynote advantage: good memory management

Most of our experiences of interactive media are very short. You might spend five minutes on a web page, or a bit longer watching a video, then you close the window and move on. And interactive in a gallery or museum environment has to run all day, every day. Compared to alternatives, Keynote is very robust over long periods.

Flash has persistent memory-leak problems which aren’t apparent in a normal web-browsing situation. Every minute the application’s memory footprint grows juuust a bit – and a few bytes every minute adds up when you’re keeping the interactive running for eight or more hours a day. That’s particularly problematic when you’re pumping out video, pushing lots of bits through the system: a Flash 10 .exe will crash Windows XP, for example, once the app takes up about 1.5GB. We’ve never been able to plug the memory leaks completely – the best we can do is make the trickle slow enough that it can last a day between restarts.

Google Chrome, which we used recently when delivering HTML5 interactives for the National Museum of Australia, has similar problems, which we eventually solved by writing an extension that periodically reloads the entire interactive in a different process, then kills the old process, freeing up its memory.

Keynote, on the other hand, just keeps on going.

Keynote disadvantage: limited interactivity options

That’s not to say Keynote is without limitations. The major challenge is that the range of interactions available to the developer is relatively constrained: it’s best suited to telling linear sequences with occasional branches. It’s the choose-your-own-adventure approach, meaning any permutation of the story needs to be represented as a sequence of screens, and you can’t use variables or other programming techniques like conditional branching to avoid a combinatorial explosion in the number of screens required.

It’s also hard to edit complex interactions using the Build inspector, which is optimised for introducing a small number of elements on screen. Complex animations involve splitting up sequences into multiple screens, and the user can’t interrupt a screen sequence once it’s begun, meaning that builds have to be short. And it’s difficult, as with any interface that’s GUI-based rather than using find-and-replace-able text files, to apply changes across multiple screens: for example, changing the duration of every object build is a nightmare across hundreds of screens. On the other hand, good use of master slides can make a huge difference to your productivity and consistency.

Keynote disadvantage: harder to work collaboratively

Compared to an HTML interactive, it’s hard for more than one person to work on the project at a time. The Keynote file is one big lump, and the only way to parallelise development is to split the interactive into multiple files and bring them together at the end – or perhaps to maintain them in separate files throughout and use inter-file linkages, which presents its own problems in building robust navigation.

Worth exploring? Absolutely.

If you find yourself looking at building a project with a storytelling focus, consider using Keynote both to streamline your development and delivery process, and to produce a robust and beautiful result.