Web(maker) Lab

This weekend we checked out the **[Chrome Web Lab](http://www.chromeweblab.com/) in the London Science Museum.**

It’s the first time I’ve seen a major museum host **an interactive exhibit on the wonder of the web.** As we wove through throngs of kids drooling over display cases as web-powered robots drew in sand, it made me realize what an **amazing learning opportunity an exhibit like this is.**

The Web Lab features five different stations, each a playful interaction of machines, haptic interfaces, and occasional online users.

But while I enjoyed getting my portrait drawn by robots and playing instruments with virtual friends, **the Web Lab fell short of exposing the real “magic” behind all its wonders: the web itself.**

**Beneath all of the chrome, the only time you could glimpse any code was when a staff member had to reboot a machine.**

Which got me thinking: how would you design an exhibit that put the web on display and let you play with code in a fun, accessible way?

# An Exhibit for Webmaking

This is certainly not an exhaustive list, but here are some ideas for a webmaker exhibit:

* **Hackability.** Much of the Web Lab seemed predetermined, or at least quite limited in its variables. A webmaker exhibit would invite the unexpected and encourage playful appropriation. Perhaps it could provide a glossary of HTML tags that you could use throughout the exhibit, and prompts for how the tags can be recombined to create new commands and attributes.
* **Interoperable activities.** The stations would be interoperable, so something you made in one activity would transfer over to the other and let you keep adding to it. That way, you see how the pieces fit together.
* **Real code.** You’d definitely get to manipulate real code. Maybe it’d use an interface like Joe’s CodeCards to invite users to shuffle syntax and run neat, short programs.

* **Design.** The team behind the Chrome Web Lab did a brilliant job with a coherent visual concept, a clear path through the space, and gorgeous fiducial markers on name tags so you could save your work and play with it when you got home. Having a consistent user experience and an attractive design goes a long way, letting visitors focus more on what they’re trying to build rather than how to navigate the space.
* **Interest-driven.** The Web Lab gave a lot of presets, which is smart in an exhibit where you just want things to work and to be inoffensive. But their stations didn’t allow for interest-driven personalization. So for example, in an image search activity, you could only select from a prepared list of ca. 20 images. While it’d be riskier, it’d also be more interesting to allow custom searches. Or just more activities that let you play with real content from the web.

It was definitely a pleasure to see the Chrome Web Lab, and together with the [Exquisite Forrest exhibit at the Tate Modern](http://www.tate.org.uk/context-comment/articles/explore-exquisite-forest), Google is making a smart move to be present in heavily visited museums in London. I’d argue there’s an opportunity to complement these exhibits with more activities that emphasize making and hacking, while still being durable and appropriate enough for thousands of visitors.

Photos: Chrome Web Lab / CC BY-NC-SA 2.0 and [Andrew Meredith](http://tellart.com/projects/chrome-web-lab/)

Comments (2)

  1. Dan Wigglesworth

    I hope I will be able to visit this exhibit. Thanks for spreading the word.

    As for making a more interactive exhibit that is also durable and appropriate for a wide audience… Something comes to mind. I have never used — but I have heard from persons first hand who have used — an old “main frame” computer system that uses punchcards/printer instead of a keyboard/video-display. That is, the computer users (students in this case) used a system that was distinct from the computer itself to produce a stack of paper punch cards which were then carried by hand (don’t drop them!) to the computer interface: the automated punch card reader.

    The punch card reader would then, convert the punch cards into what would ultimately become the program that runs in the computer itself. The computer user would then wait (around because many other computers users were also vying for a turn) for the computer program to produce its output which would come in the form of a printed page — no video display screens in this case!

    I see a parallel process suited to an interactive web exhibit at a museum:

    1. The museum visitor is prompted to go to a website on their mobile device (or to use a device attached to the museum display). The visitor uses this webpage to produce “input” for the display (analogous to the process of creating punch cards).
    2. By clicking a “Submit” button, the museum visitor queues their “input” for the exhibit display to process (analogous to bringing the punch cards to the punchcard reader — punchcards were queue in a punchcard hopper). Of course, depending on the nature of the exhibit there might be no queue if the processing and output phases take little time.
    3. The museum visitor waits and watches the exhibit … waits around for the exhibit to receive their input and to produce the “output” (analogous to waiting around for a computer printout).

    That leaves out a few details that I think are somewhat obvious. One perhaps not so obvious but perhaps very important detail: the system could notify the visitor when their “input” is being processed (by any number of means: a large display at the exhibit could show “who’s up next” and/or the vistor’s mobile device could notify the visitor on a special webpage or via text message. Furthermore, if the visitors are queueing sufficient inputs, the system could recycle input from previous hours/days/weeks and (optionally) notify those visitors whose input is being processed (again and again, in some cases).

  2. Pingback: Results for week beginning 2012-10-29 « Iron Blogger Berlin

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.