Advent of Computing - Episode 95 - Aspen Movie Map

Episode Date: November 14, 2022

So far I've strayed away from hypermedia in my larger hypertext coverage. This episode helps to fix that. Today we are looking at Aspen Movie Map, a project from 1978 that created a virtual Aspen, Colorado. Why would you want to digitize an entire city? Why did DARPA fund a trip to Aspen? And how does this link up with hypermedia? All this and more will be answered.  

LaserDisc was a technological marvel. Upon its release in 1978, the older VHS format, well, it became totally obsolete. LaserDisc could do everything that older tape-based formats could, and much more. Not only could the same analog signals be stored on LaserDisc, it was also random access. You could skip tracks, you could freeze frames, you could jump around the disc to your heart's content. But Laserdisc had a bit of a hard time winning in the consumer market. It seems like it just couldn't get a good foothold, so even with a better option around, VHS stayed in use for years. But LaserDisc still had its applications. You see, it was a more

fully featured format. It was a better way to store and access analog imaging. One of the first applications of this new disc wasn't home video. It was part of a DARPA-funded project at MIT. home video. It was part of a DARPA-funded project at MIT. This project, Aspen Movie Map, was an attempt to create a new way to train soldiers. It turned out that Laserdisc was the perfect medium for the task. At least, it was the best option in 1978. But how do reflective discs translate into better military outcomes? Well, it all has to do with some fancy programming, a bunch of cameras, and a strange amendment added to the military spending budget. Welcome back to Advent of Computing. I'm your host, Sean Haas, and this is episode 95, Aspen Movie Map. I know, it's something of a boring title, but we've escaped spook month, so it's back to serious matters.

This episode, I'm finally returning to the hypertext thread. I should have probably done this sooner, but I've been trying to spread things out a little bit. I swear there may still yet be a method to my madness. Anyway, today I'm trying to correct a deficiency in my coverage. Hypertext is a really flexible technology. Maybe it should just be called an idea, really, because it can be applied to darn near anything. The core of hypertext is the ability to add context to data via its connections to other data. That's it. That's probably the most succinct way to explain it. The data in question can be anything.

If we're going with a very traditional sense, it's usually text, hence why hypertext is the most common way to describe the technology. However, hyper doesn't have to be restricted to only text. We can see this all the way back at the beginning of this ideology. Vannevar Bush's Mimex didn't link text per se, it linked frames of microfilm. Those are just analog photographic frames, so they can hold anything. Even before Bush, we get things like edge-notch cards, which could be used to construct links

between simple sheets of cardstock. Paper as a medium is notorious for being able to hold anything you want, not just text. Engelbart even implemented simple image handling in NLS as early as 1969. That's digital hypermedia. We have a video of Hyper doing more than text. We can go watch it in the demo. Now, the more generalized term here that I've been using, and we should all use, is Hypermedia. Because you can apply the power of the link to any kind of media. There's nothing stopping you from linking together images, at least in theory. In practice, things get more complicated once you jump out of the

text-only world. Computers are really textual beasts by necessity. But what complications does hypermedia specifically face? To dig into that question, we need a case study. And what better place to study than at the very beginning? we need a case study. And what better place to study than at the very beginning? This episode, we're going to be examining Aspen Movie Map. This was a project conceived of at MIT in the late 70s. Its goal was to produce an interactive and navigable map of Aspen, Colorado. Already, there are some questions there. Why Aspen? Why did the project happen at MIT and not at a lab in Colorado? And how does an interactive map connect up to, well, data connections?

This is a bit of a rambling story, so let me lay out a quick roadmap. First, we're going to look at the origins of the project in general. Strangely enough, this will take us into the bowels of the U.S. Congress and even deeper into shadowy operations. From there, we'll move towards the technical implementation and examine how the pieces came together. We'll close with a discussion of the larger technology in play and the more interesting features of the movie map. But before we get into the episode proper, I have to give the traditional plug for Notes on Computer History. If you haven't heard already, this is a community journal that I'm trying to get off the ground. And right now I'm looking for authors.

And that doesn't have to be someone who has any experience as a technical writer or an academic writer. I really just want to get anyone who's interested in writing about the history of computing involved. If that sounds like you, which if you're listening to the show, then it probably is, then get in touch with me. You can find information on how to submit at history.computer, or you can just email me directly and I'll get you in touch with someone to help out. Now, with that said, let's get into the episode. To start off, I'm going to walk straight into a minefield here. One of the main reasons for Aspen Movie Map's success, and the reason it got funded at all, has to do with a 1976 hostage rescue operation carried out by the Israeli Defense Force. Now, this is not a political podcast. This is a tech history podcast.

So we're only going to be looking at the technical aspects here. To get into the larger Israeli-Palestinian conflict would be entirely out of scope for the show and out of my area of expertise. I just want to focus on one part of this operation and how that connects directly to the story at hand. In 1976, a plane leaving Tel Aviv was hijacked by members of the Popular Front of the Liberation of Palestine. Their plan was to negotiate a prisoner exchange with the Israeli government in order to free a number of PFLP members. The hostages were eventually flown to Entebbe, Uganda, where they were held in an abandoned airport. Non-Israeli prisoners were released, but all Israeli citizens plus the flight crew would remain detained in the airport pending the prisoner swap.

Negotiations didn't go very well. They broke down almost immediately, and perhaps that's unsurprising. This is where Operation Entebbe starts. In lieu of a prisoner swap, the IDF planned to raid the airport and free the hostages within using deadly force. But this was a risky proposal. The raid was planned to be at night in order to mask the approach. No one wants to be in unfamiliar and hostile territory in the dark. It's already spooky enough walking to the bathroom at night.

So entering into a combat scenario without any light, well, that's a recipe for disaster. A more ironclad plan had to be hatched. Luckily for the IDF, there was plenty of military intelligence to draw on. The non-Israeli hostages that had been released were willing to provide the IDF with details on the situation on the ground. We're talking number of guards, armament, number of hostages, and where in the airport the hostages were being kept. That was a start, but a more important piece came through a strange coincidence. It turns out that the particular airport in Entebbe had been built by an Israeli contracting firm. How does that help? Well, this meant that the IDF knew the entire layout of the airport.

That could help with planning the raid and also in training. This is where we get something truly novel. Working with the very people that had built the original airport, the IDF built a partial mock-up of the building. This was basically a full-scale model of the parts of the airport they expected to be operating in. Troops were able to train virtually in the same environment that they would be dropped into. This helped to make the operation successful. And this would also draw the attention of some of the spooks in the US government. Now, there's a small gap in the exact chain of custody here.

Probably because this is some high-level intelligence kind of stuff. I guess either someone working in intelligence or some diplomat was the first person in the states to hear about the Entebbe operation. News of the operation soon filtered into the Department of Defense, and from there it went to DARPA, the Defense Advanced Research Projects Agency. DARPA, earlier known as ARPA, holds a very special place in the history of computing. It was through ARPA funding and planning that the earliest nationwide network, the ARPA holds a very special place in the history of computing. It was through ARPA funding and planning that the earliest nationwide network, the ARPANET, was formed. ARPA also provided funding

for Doug Engelbart's Augmentation Research Center. So, both early internet technology and early hypertext was developed thanks to ARPA grants. That's something really, really important to keep in mind here. The thing is, this funding didn't come from pure benevolence. The D was added to ARPA in 1972 and emphasizes where the agency's bread is buttered. DARPA is the research wing of the Department of Defense. In other words, this is the lab for the U.S. military. Just to drive that point home, the name DOD itself is a bit of a gross euphemism. It was formed in 1947 to replace the U.S. Department of War, since we were no longer technically in a state of war. Defense is really just half of the department's interests. Now, we've talked about why DARPA funded early networking previously on

the podcast. It comes down to command and control structures, especially ways to maintain control of military resources during a nuclear attack. That means that this networking technology that we all benefit from today was directly related to military operations, even though ARPANET was used for much more than the military. The Engelbart connection here is a little more complicated. DARPA's own website states that Engelbart's research was funded because the DoD was trying to make more user-friendly computer interfaces.

There were forces within DARPA back in the day that were interested in fostering improvements to computing in general. This was primarily spearheaded by one JCR Licklider, who I keep saying I'll eventually cover. I swear I will. Licklider was also instrumental in securing funding for the ARPANET. But the Augmentation Research Center was less directly tied to a specific military application, which would cause some problems down the line. Technically speaking, ARPA has always

operated with a lot of autonomy from the DoD. It's not supposed to just be a military research lab. I like that line. It's reassuring, but I'm a bit of a pessimist. I don't trust it all that much. The document that established ARPA, DoD Directive 510.15, expressly states that ARPA reports directly to the Secretary of Defense. Projects can be delegated to ARPA by the Secretary of Defense. But to be fair, ARPA can also pursue their own projects and contracts. It's all a bit of a morass, like any government control or funding documents are, and my pessimism does creep into this. The point is, ARPA can do more than military research, despite being expressly part of the US

war machine. Or perhaps the US peace machine, depending on what time we're talking. That's all well and good, at least to some. In 1973, we get one of the more boring events in this story. It's not another hostage situation or a high-tech project with covert goals. It's a budgetary amendment. Specifically, the Mansfield Amendment of 1973. This is another part of the story that's... Well, it seems a little out of place.

Senator Mike Mansfield was a relatively anti-war kind of guy, something I can get behind. He was one of the first members of Congress to speak out against the Vietnam War. But then we have his budgetary amendments, which were, at least to my ear, pretty hawkish. There were two of these amendments that passed, one in 1969 and one in 1973. Each limited budget appropriations at parts of the DoD. The 69th Amendment stated that the DoD could only fund research with direct military applications. The 73 version did the same for DARPA. In light of the actual research that DARPA was funding at

the time, well, this seems like an awful decision meant to drive the US further into warfare. The agency was supporting important developments in computing that weren't necessarily connected to military outcomes. That's a good thing. I mean, if you want to get granular here, DARPA funded the development of the computer mouse. Sure, that could have been some gear in a larger weapons system. If you want to get granular here, DARPA funded the development of the computer mouse.

Sure, that could have been some gear in a larger weapon system. But for the most part, a mouse is just a mouse. It's something we all use today. It was revolutionary and it was partly funded by the feds. The 73 Amendment was forcing DARPA to be more tightly connected to the DOD, which I think was a mistake. This would lead to DARPA cutting funding for Engelbart's lab, as well as a number of other projects that weren't directly tied to violent outcomes. The agency was being pushed into a smaller, more bellicose box. These cuts would have just occurred a few years prior to when news of Entembe hit the DoD. I think it should be clear why the operation excited these spooks so much. Imagine being

able to have troops specifically trained for a mission. Imagine knowing the lay of the land before a single shot was ever fired. Imagine the opportunity to spot issues in a plan before any boots were on the ground. As cool as the lead-up to Operation Entebbe was, it did have issues. This just wasn't a repeatable process. It only happened thanks to some really lucky circumstances. thanks to some really lucky circumstances, the stars had really aligned for the IDF. That kind of stellar event can't be counted on to happen very often. The DoD didn't want a model airport. They wanted a more general solution. The implication from what I've read is that the Mansfield Amendment made it easier for the DoD to get DARPA on board. Mansfield Amendment made it easier for the DOD to get DARPA on board. But you see, every good story comes in threes. We need to add one more piece before we get to the hypermedia world.

Our trifecta was completed by a new technology, the Laserdisc. That's disc spelled with a C. That's disc spelled with a C. Laser disc at the time called discovision was first demonstrated in 1972. Now, for our purposes, we can just think of a laser disc as a bigger and kind of worse CD. There are some details that we'll get to, but let's just use that as a baseline description. get to, but let's just use that as a baseline description. The disc itself is a big reflective platter that's a foot wide. Pretty hard to miss or really mistake for anything else. It's also an optical medium. The laser part of the name kind of gives that away. It's read by reflecting a laser off the disc's surface. These discs are an interesting transitionary medium. LaserDisc offers a combination of analog and digital-like features. First off, LaserDisc was originally used to store analog video data. From what I understand, the actual signal was almost the same to that of a VHS or Betamax tape.

We're talking composite TV signals, more or less. That means that Laserdisc was at least operating in the same domain as existing analog technology. Where things deviate comes down to the tricks that could be pulled with the new medium. Laserdiscs were a fully random access media, meaning you could read any part of the disc at any time. A read from one location should, at least in theory, take the same amount of time as a read from any other location. This immediately makes laser disc way better than older sequential video media.

No more fast-forwarding or rewinding, you could now select a part to play. And it does get better. Laserdisc stored its video as discrete frames. In other words, still images. Every disc could hold upwards of 50,000 images to a side. You could take the boring route and use those frames to construct a video, or you could use a disc as bulk image storage. One easy application here would be archiving documents.

You could use a laser disc as a supercharged version of microfilm. You could also go further. You see, a new medium introduces new opportunity. There had to be all new devices for using this medium. Early on, companies behind Laserdisc, MCA, and Philips produced players that could be externally controlled. AKA, you could patch one of these into a computer. Think of it like a means of exposing a more powerful remote control. Instead of pressing a button to select a frame, a computer could issue a command directly to the Laserdisc player.

Now, why would that matter? That comes down to the state of digital multimedia in the 70s. I can summarize it in one word here. Primitive. Digital cameras existed, kind of. There were examples in a lab off at Bell, and there were kits to build rudimentary digital cameras for computers, but we're talking hundreds of pixels per image. Graphics displays also existed, but they were very low resolution. Digital video would be created in this decade, but even then it would require large amounts of storage. There just wasn't really a way to create, store, and reproduce good quality images on a computer yet. The whole toolchain was left lacking. A computer-controlled Laserdisc player

represented one way to display realistic images using a computer. Compared to the tech we have today, Laserdisc does kind of suck, but for the time, it was pretty good. I think this sets the stage nicely for the next step in our tale. We have the inciting incident, a little bit of pressure, and some new technology to play with. So how does this lead us into hypermedia? The actual start of the Aspen movie map is at MIT in 1977, or maybe 1978, but we'll get there.

Around that time, MIT got their hands on an honest-to-goodness Laserdisc player. The lab where the story takes place was the Architecture Media Group, aka ArcMac. Michael Nymark was one of the students working in the lab at the time. The new disc was a big deal. The MITers wanted to do something with it. Their first crack at the format was called Slyathon. It almost sounds like there should be an echo. More importantly, there's almost no information about this that survives. Apparently it was a custom disc full

of images supplied by ArcMac. Production was a little strange, at this point they had to send in photos to be pressed onto the disc, but that didn't stop them. As Nymark explained in a 2006 article, there was something special on the B-side of this slide-a-thon disc. Quote, In early 1978, ArcMac received one of the first 25 prototype video disc players from the MCA Corporation, and with it, a contract to master three discs of its own. That spring, an energetic MIT undergraduate named Peter Clay proposed mapping the hallways of MIT. End quote. The initial setup here is crude and cobbled together in a way that I find really, really fun. Clay had fashioned a

quote-unquote mapping cart from a normal wheeled cart and a 16mm film camera. In some tellings, the camera simply strapped into a wheelchair. Now, the shutter of the camera was rigged to trigger at even intervals as the cart moved. This trigger mechanism was controlled by a fifth wheel that Clay applied to the normally four-wheeled cart or wheelchair. That ensured that a frame would be captured at even spatial intervals instead of even time intervals. A slight distinction, but one that will matter. Also, just a note on the date discrepancy here. Nymark's recollections state that things kicked off in 1978, but the funding statement for later movie map projects say that grant funding began in October of 77.

I didn't think that would be backdated. That wouldn't make much sense, but I'm not sure. Either way, we're operating at the end of the 70s here. Other researchers at ArcMac were pretty impressed with Clay's little mapping project. Now, we don't know how in-depth the project was. It may have just been a selection of slides taken by the jerry-rigged cart. Whatever the case, the idea showed promise. It's also unclear how exactly DARPA became involved. We just don't have the fine connective tissue here. MIT was already a hotbed for federally funded research.

It was kind of the traditional place for that kind of work. So it's no stretch to imagine that news of the camera cart reached the fed boys pretty quick. I'm kind of sad about this lack of detail because we know exactly where the funding came from. It's the Cybernetic Technology Division, contract number MDA90378C0039. But we don't have the original contract. I think it would be a target for Freedom of Information searches, but it's not really worth the months of waiting to figure out this small mystery. It's probably just going to be a memo saying, hey, fund it. Give them the cash. Anyway, in retrospect, we can see why DARPA would be interested. Clay's project was a very primitive example of what we would call surrogate travel. Sounds so nice when you put it that way, doesn't it? It sounds like watching a travel vlogger or something.

However, surrogate travel in this sense is a much more nuts and bolts affair. I mean, we can kind of look at the training and operation in Tebe as a very rudimentary form of surrogate travel. Troops were able to pretend they were traveling to a distant airport without actually going to location. But that's still all physical. For real surrogate travel, if we can call it real, you need to simulate travel with added benefits. You can think of surrogate travel as almost virtual reality. Instead of, say, visiting an airport in Entebbe, you could just sit in an office and navigate a virtualized version of the on-the-ground scenario. And if you've already visualized the locale, then why not go a little further? Why not enrich the experience with added data? This kind of technologically-minded travel was pretty exciting for the DoD.

In theory, this kind of technology could be used for training. It could be a repeatable Entebbe. However, the technology was only a glimmer in the eye of some MIT students. It needed funding, time, and talent to get off the ground. Hence why DoD was willing to shell out money for it. In 78, all the pieces were starting to come together. A group was forming at Arcmath. Among them were the aforementioned Clay and Nymark, as well as another student named Bob Moll. These are the three that left a pretty good paper trail for us to draw on. The technology, the Laserdisc, was almost in place.

And most importantly of all, there was money, there was funding. To get us into the project proper, I want to start with the rig. I think this is a nice starting place because, well, it's where the data comes from. You can't really have surrogate travel without some kind of imaging technology. The core of the mapping project came down to a scaled-up version of Clay's camera cart. This involved a jeep with a stabilized platform mounted on its roof. Four 16mm cameras were mounted on top of that platform. This way, as the Jeep moved down the road, the cameras wouldn't bump or shake. They would remain more or less on a smooth trajectory. This was all controlled by a fifth

wheel that drug behind the Jeep. The wheel was wired up to the camera rig so that every 10 feet the cameras would capture a frame. As the camera Jeep toddled along the road, it would shoot four shots, forward, left, right, and backwards, every 10 feet. This is kind of a low-tech solution, but it did work pretty well. This platform allowed for the imaging of any road you wanted. All you had to do was drive. Now, the venue. The team chose Aspen, Colorado as their target. The main reason just came down to the fact that the students wanted to go on a trip to Aspen. Can't really blame him for that. Neimark explains that one possible factor was that his sister lived in Aspen at the time. As far as other cover stories go, he states,

quote, the other two reasons were that Robert Moll, another MIT researcher, grew up in Colorado and had professional photography experience around Aspen, and that the nascent Aspen Design Conference would be a befitting venue for presenting the project when it was completed. Whoops, did I forget reason number one? Simply because it was Aspen, an intensely beautiful mountain town with a single traffic light and a lively local community. Why fib? Aspen was a cool place, and we all wanted to go. Why not spend those sweet, sweet DARPA bucks on a nice little trip? But this wouldn't be all fun and games. This was part of serious research. The main goal of this outing was to collect imaging of downtown Aspen, which entailed running the camera

jeep through every street in town. On the surface, that might sound simple, but there are some interesting complications to this task. So, if we've made it this far, this is the part where we actually need to address the hypermedia aspects of the movie map. The grand plan here was to make a navigable space from a lot of smaller images. On their own, each image is worth, what, about a thousand words, give or take? A single image can be useful, but only for so far. Likewise, tens of thousands of images can be useful, but only up to a point. How would you go about trying to extract information from thousands upon thousands of discrete frames of film? You'd probably want to group them together to try to add some kind of context.

The solution you tend to arrive at is some type of hypermedia treatment. In the case of the movie map, these hyperlinks were a way to represent spatial context. Images would need to be linked to images that were taken nearby in order to present a path of travel. That's all pretty easy to do if you're just dealing with a straight line. Adding in turns introduces a fun complication. This network of images has to be almost randomly accessible, but structured in some way that makes spatial sense. Linkages between images added spatial information, so everything had to be really carefully lined up. You wouldn't want to take a turn in the middle of a block. There's nowhere for you to go.

In other words, the links needed to reflect the reality of the actual roads. This introduces a bit of an interesting problem when it comes to turns. Let's assume that all roads at an intersection are two-way streets. That means you have eight different ways you could turn at each intersection. Add in another four possibilities for straight routes, and you get a comfy 12 possible routes that could go through that intersection. So every time you approach a turn on your surrogate trip, every time you approach a turn on your surrogate trip, the movie map has to be prepared for 12 possible outcomes depending on your angle of attack and your reaction. One early lesson that

the map team learned was that small discontinuities from frame to frame were actually a big problem. Not only did you have to link to nearby images, you had to make sure those images looked somewhat similar. You don't want to jump from a view in front of a cafe to City Hall. First of all, that's pretty jarring. It's not very pretty. Second, it doesn't provide meaningful spatial information. It only lets you know you've moved. How far? What direction? No clue. By the same token, you want each shot to have similar lighting conditions, since abrupt changes can be disorienting. It just disrupts the flow and brings you out of any immersion that may have been building. Here's where it gets weird in a funny

sort of way. Aspen, Colorado is, quite famously in fact, outside. The entire city is exposed to the sun and Earth's atmosphere all day long. There are these fun things called shadows that are cast depending on the angle of the sun. In order to minimize lighting changes, the Aspen team had to collect images during the middle of the day, between 11am and 2pm. Everything from the filming route to the time different parts of Aspen were filmed had to be planned out very carefully. The result of this preparation was a smooth dataset. Images were all similar enough that continuity could be maintained along paths. I think we need to look at this as more than just a technical choice. The whole

shadow continuity thing isn't just a very specific problem to Aspen Movie Map. This is a larger problem with hypermedia in general. So let's go back to basics for a second. In a hypertext system, a link simply encodes an abstract connection. It can mean whatever you want. Classically, links have been explained as a way to organize related pieces of data. You might have a chunk of text about the IBM PC that links out to an article about IBM the company. That particular link doesn't hold much information on its own, but it implies certain things. It implies that IBM, in fact, had something to do with the PC.

There's also an implied hierarchy in this data. The link itself doesn't say anything besides, oh, these two chunks of text are connected. These two documents are linked. We fill in the rest via context. That's kind of the beauty of the link. It's a regimented system that can be used to express something as squishy as the human idea of relational data. This is a really powerful tool, but it only works if the context is clear. If you don't have this context, then a link loses its meaning. It's like trying to read Wikipedia in a language you don't understand. You can see all the usual hypertext trappings. You can follow links connecting one page to another. But you

can't really glean any information by just following links. You need to understand why the link is there. That's the only way to get a link's potential. Back to Aspen. In the movie map, you aren't following traditional point-and-click kind of links. The final program simulates a drive through the roads of the city. The linkage is handled behind the scenes, so context is really all you have to go off of. You have the context that you're traveling, that you're in control of a moving vehicle. You also have the context of the image itself. Since frames are taken every 10 feet, there's overlap from frame to frame. It depends on which direction you're looking at,

but there will be visual context here. And that's it. That's all the context you get. context here. And that's it. That's all the context you get. The movie map never provides huge chunks of text explaining what you're doing. There is documentation, but that's a separate thing. That's not on screen all the time. There's no readout that says, oh, you are at the intersection of Main Street and First Street. If you move forward, you will be entering the next block and approaching Second Street. If you go backwards, you will be entering the next block and approaching 2nd street. If you go backwards, you will be leaving the city center. That's not only laughable, it would ruin the whole experience. Aspen Movie Map wasn't meant as some simple hypermedia system. It was a program that used hypermedia for a larger means. My point here is that on the surface, the program may not look like hypermedia, it may not look like hyper-anything, but it carries all the trappings and issues that older

hypertext systems contained. So with that, I think it's time we actually turn to the program itself. Once Aspen had been thoroughly imaged, everything was pressed onto a set of laser disks. There were two core disks that made the system tick. A straight path disk and a turn disk. We'll get back to these in a minute. That was the bulk of the data the system used. Everything else came down to some special hardware and the actual computer side of things. The magic box that brought everything together

was something called a compositor. This is a pretty straightforward device. It has a set of video inputs, a video output, and some control lines. An external signal tells the compositor how to mix each of its inputs to form a final output. This can be something as simple as pass through the video from input 1, but it can also be a lot more complex, allowing specific regions of different video feeds to be overlaid on top of other video feeds. These are neat little machines, but their usefulness really comes down to what you feed into them. In the case of ArcMac, their compositor was set up with three inputs, two for different Laserdisc players and one directly from a computer.

The Laserdisc players were, well, where all the required images were streaming from. The computer input was used to display a simple interface. That's the output side, and also kind of the input side. The primary input mechanism for the movie map was a touchscreen. Once again, this is where we see how a specific implementation of hypermedia can differ from the norm. The general idea was that Aspen Movie Map would let a user simulate driving through the town of Aspen. Simple. That gives us only a few controls to think about. Speed and steering. The main part of the interface simply provides a button to stop the virtual car, buttons to the left and to the right, and a speed slider. It also shows which direction you're traveling in, and there are buttons to look to the left and look to the right. That's all overlaid on the bottom part of the screen. You could also steer around

Aspen using a joystick, but that's not as flashy. If you've heard my other hypertext episodes, then you might know where I'm going. There are weird design considerations with touchscreens. At least, this is true when it comes to old-school non-movable touchscreens. Handheld screens are a totally different thing, so let's act like they never existed. These vertical interfaces aren't ergonomic. Specifically, they cause something called gorilla arm. Our human arms aren't good at staying extended, especially if we have to keep them extended forward and clicking little buttons. If you use this kind of interface for too long, your arm will get tired. It may even start to ache. That makes for an interface that triggers a fun human response in our little lizard brain.

in response in our little lizard brain. This thing hurts. I need to get away. That's not a good outcome, so mounted touchscreens are best used in short bursts or in conjunction with another input method. Aspen Movie Map deals with this issue in a natural way. In general, your virtual car is on autopilot. At least, kinda. Once you adjust the speed and direction, it will coast as far as it can go. If you hit an intersection you can't blow straight through, then you stop. So, you aren't constantly holding your arms forward. Instead, you only need to prod at the screen on occasion. Most of the time, you can sit back and watch your surrogate travel. Thus, Gorilla Arm can be avoided or at least minimized. The big thing was being able to maximize the usefulness

of a touchscreen without running into its ergonomic issues. I think the interface does that handily. We're going to be sticking with this human factor theme for a little longer because it's very important. The next consideration comes down to speed of execution. This is another case where human factors direct technical implementation. You can also say that at your next meeting to earn some cool programmer points. So how much do you think input can lag before we notice? Put another way, how slow can a response be without breaking our immersion? There's actually a good deal of

research into this specific question. Humans can perceive any delay in input longer than 0.1 seconds. At least, that's the rough estimate. It's a pretty low threshold. You want a computer to respond to your input within 0.1 seconds after you click a button or type a key. So here's a fun scenario to think about as we traverse Aspen. What happens when we turn a corner? In theory, that's a simple operation, right? When you approach a turn, you're being fed images from the straight-route laser disc. When you take the actual turn, then you'd just be shown a set of images from the turn's laser disc. Once the turn was done, you'd be back to part of the initial disc.

But that doesn't work. ArcMac realized that the simple solution was too slow. It was too laggy. Now, I can't find hard numbers on the selection speed of a laser disk. That's going to be dependent on a lot of factors, a big one of which is the disk player itself. That said, we can spitball some basics here. The time it takes to select a given frame on a disc will have to do with the speed the disc is spinning at, how fast the reed head can move, and how far the head has to move. The worst case scenario would be that you're viewing a frame at the outer edge of the disc and then jump to a frame on the innermost track.

Or, you know, going from the innermost track to the outermost. Same thing. That's the furthest jump possible. For maximum selection speed, you want to move the head as little as possible. If you're just blindly selecting chunks from the disc, then you might get lucky and you might not have to move that much, or you might have to jump over the entire disk to get to the next frame. Reads are random and relatively fast, but there's still a slightly variable latency here. It's small,

but it's gotta be more than.1 seconds. So the ArcMac team did something really smart, which initially seems counterintuitive. They paired up turns and placed them back to back. When you enter an intersection, you only have two possible turns you can take at most. You can turn left or you can turn right. On the turn disk, those routes are placed next to each other. The trick is that one of the turns is in reverse sequence. So if you look at the frames on the disc, first you'd see the frames for, say, the left turn that were stored backwards, and immediately followed by the frames for the right turn stored, you know, in the proper orientation. As you approach a turn, the turn disc is seeked to the middle of the proper pair of turns. The head is hovering right between the two options. If you

turn right, the disc plays forward to display that turn. If you turn left, it just plays in reverse. plays in reverse. The response time here is almost zero. It's almost instantaneous. The laser disc player just has to start reading from where the head is already located. The only real latency is issuing a command to read and telling the compositor to switch inputs. That's it. This is the kind of issue that doesn't show up as much in hypertext because, once again, context is just different. You might get annoyed if you click a link and have to wait for the next page to load up, but you're still in that experience. The lag threshold here is a lot higher because you're not controlling something happening in real time. But if you're executing a virtual turn and everything just stopped for a second, well, that's another story.

That will take you out of the experience. Instead of wondering what's around the turn, you're now wondering why you have to wait to make that turn. That pretty much covers the realistic part of Aspen Movie Map. At least, realistic in quotes. That pretty much covers the realistic part of Aspen Movie Map. At least, realistic in quotes. You can pretend to drive around Aspen. You can take turns.

You can look side to side. All the usual driving stuff we know and love. This feature set alone is enough for a digital rendition of Operation Entebbe. But ArcMac took things a step further. This is where we break away from the boring, real-world vision and jump into something more complex, and I think more compelling. A few years back, I ran an episode on BBC's Doomsday Project. Created in the 80s, this project was broadly similar to Aspen Movie Map. Doomsday used a set of laser discs connected up to a computer and a compositor in order to display data about the United Kingdom. This included maps,

images, and general survey data. Something interesting about Doomsday that I don't remember giving much lip service to were its virtual spaces. There was this whole virtual gallery that could be used to navigate and view parts of the Doomsday dataset. This gallery wasn't a real space. It was a 3D model that had been rendered out as film frames on a laser disc. It didn't represent an actual place. It more served as an analog to a menu. If you really think about it, then this is one way that Doomsday was similar to good old Microsoft's SAM. Now, I can't tell if Aspen Movie Map inspired Doomsday directly. I don't think it did, but there are a lot of similarities here. Both used the same medium, both used compositors to overlay images and interface widgets, and both contained geographical data.

Going into this episode, I just kind of assumed there'd be a lot of crossover. But there actually isn't as much as I first thought. The two projects have more superficial similarities than actual connections. However, there is something interesting going on with this 3D rendered stuff. Like I said, Doomsday has this fully virtual 3D space for selecting data. The movie map has a 3D representation of the real world. During the development of Aspen Movie Map, a grad student named Walter Binder headed up an ambitious part of the project. I mean, the whole thing is ambitious, but Binder's contribution just seems like so much work to me.

Binder's thesis project was to create a 3D model of Aspen. He also wrote the software to make that 3D model, so props. Now, to be fair, Aspen at the time wasn't a very big town. I think he even describes it as a 10x15 block grid, so, you know, 150 blocks of buildings to model. No biggie, right? Binder actually explains the why to this project pretty succinctly. He has a whole section in his thesis just called Why Animation? Binder describes the medium this way, quote,

Perhaps the most obvious reason to employ animation is because it allows you to see what you normally cannot see, either because of some physical or practical limitation, or because you want to represent something which normally can't be seen. End quote. In the case of Movie Map, the 3D animations were used to present the actual shape of structures in the city. This wasn't just done as a way to flex some programming prowess and earn a PhD. Bender explains that there's more specific reason to model Aspen. It removes clutter and facilitates repeatable navigation. This is a little subtle, but it all comes back

to the discontinuity problem that I keep bringing up. One thing that ArcMac couldn't stop was traffic. Both the shod and wheeled kind in this case. So as you navigate digital Aspen, you get these weird jumping cars and pedestrians. It's not a huge deal, maybe a little annoying, but there's actually a hidden problem here. Bender doesn't give the problem a succinct name, but I'm going to call it false landmarks. In his thesis, Binter presents an interesting scenario. The whole point of movie map is to actually learn how to navigate a real space, to get familiar with an area. You want a user of movie map to be able to go to Aspen and find their way around. Humans navigate by landmarks. You might know how to get

to City Hall because, oh yeah, it's near that big church steeple which you can see from blocks away. So if you were heading to City Hall, you wouldn't be looking for its address per se, you might be looking for that big church steeple on the skyline. A surrogate travel program should be a way for you to form those landmark connections without leaving a desk. But what if you pick up on the wrong kind of landmarks? Bender's example is that, apparently, on the movie map discs, there was a white car leaving the parking lot of a certain department store. So every time you were getting near that store, you'd see the same white car. Within the virtual world, this is a workable landmark. But it doesn't translate into real-life Aspen. There's not a greeter car waiting for you.

The same thing might happen with more semi-permanent things. Maybe there's a dumpster in front of a restaurant in the movie map images, but the dumpster was only actually parked there for a week. Knowing the location of that dumpster wouldn't help you navigate the real world of Aspen, Colorado. Creating an animated version of the town gave Bender a chance to select which parts of images were important, and which weren't. Put in more fancy terms, he was able to get a higher signal-to-noise ratio. This worked best for things like the car landmark example.

Bender took facade images of some buildings, the side view captured by the film car, and then used them to spice up his 3D model. The actual models are just polygons with very little detail, so adding a picture on top of that really helps. What's neat is that Bender was able to pick and choose which facades to include, which shots were good, and basically which landmarks would be interesting. That let him shape the entire environment to be much more clean. This meant that Bender's 3D model had almost no navigational noise. The shots with the white car could just be removed. Simply don't use those shots for facade images. So while the 3D model might be missing a lot of little details, it does provide the cleanest view of Aspen possible.

The final model was rendered out and added to the main MovieMap dataset. This meant that users could navigate photographically or drop down to the 3D-modeled streets. The whole signal-to-noise thing is cool and all, but there's another trick that Bender's 3D model enabled. To explain this next part, we need to talk about a strange aspect of the movie map interface. The program also included traditional maps of Aspen. We're talking top-down views. Now, this is part of the system that we don't have really good detail on. In earlier papers, it's explained that the map existed. Later papers and some photos show a map displayed on a

second CRT. The more traditional map here was photographic. ArcMap had stitched together a full map from aerial photography of the town. This would have made a wonderful aid to navigation, since, you know, it's a map. Maps are useful. But the other feature here is that users could pick a location on the map and have their simulated car drive there automatically. So you could just totally sit back and let the movie map play in something like a demo mode. The single screen setup I get. It's just a screen that switches over to a map at the press of some button somewhere. But the dual screen stuff, that had to be more complicated. I'd imagine a third laser disc player was involved, but I just don't have information on that. All the charts

show two players working together. So this is just something later that we don't have the same kind of really good documentary evidence on. Anyway, Binder's 3D model was used to provide a rendered view of the city from above, or what's called a simulated aerial view. This allowed the team to choose whatever angle or projection they wanted. Instead of stitching and stretching photos taken from a plane, they could just plug in some parameters and get their aerial map. We can kind of get the best of both worlds today with fast image processing and satellite imaging. But it's just not the same. You don't have enough data from pictures alone to really get the lay of the land, so to speak.

You end up with these odd contorted images. Using a 3D model, Bender was able to get much more mileage here. able to get much more mileage here. A neat aside is that Bender's renders were also used for full simulated flyovers of Aspen. There was a section of the program that allowed users to take certain aerial paths over the town. There's like a sentence of information about this, but I just think it's cool. Now, the final thing I want to discuss is how Aspen Movie Map went further than just fancy surrogate travel. So far, everything we've seen is in service of navigating a virtual landscape. Up to this point, we could just say that Movie Map was a digitized operation in Tembe, and that'd be broadly accurate. However, ArcMAC was working

in a medium that gave them more freedom than physical buildings ever could. That's the glory of hypermedia. Links and connections can be used to pull together anything you want. Aspen MovieMap is really densely packed with data. Doomsday 86, a project that's been working to preserve the aforementioned Project Doomsday, gives a well-detailed rundown of what the movie map disks contained. See, I told you there was some crossover here. So let's start with one of the larger added datasets. An entire second set of street-level imaging.

It turns out that ArcMac imaged all of Aspen twice. The first set was taken in the summer and a second in the winter. The whole project already sounds exhausting, but you have to remember, the entire effort was doubled. From what I've seen, it looks like you had the choice between viewing Aspen with foliage or with snow. But it's still a neat added feature. The wintertime scenario does change the look of the city quite a bit. There's also crossover with another augmented dataset, as the team called it. with another augmented dataset, as the team called it. Besides the camera jeep images,

the disks also included registered images of certain buildings. This was part of a larger cultural dataset. This dataset included these registered photos for some structures, plus earlier historic photos. The screenshots of this look pretty neat. You have old-timey photos of a building next to modern photos, both taken from the same angle. That was further supplemented with scans of some old documents and small text passages about the history and culture in Aspen. Now, you'd be tempted to think that this cultural data was just a small portion thrown in

for fun, more a demo than a project, but that's wrong. Doomsday 86 gives a full count of images for each section of the movie map. We're looking at just under 130,000 images here just for the cultural dataset. That's actually quite a bit more than the traveling disks. This presents something really, really fascinating, at least in my hypermedia-addled brain. This data is, of course, connected up and given context via links. From what I've read, it's not super clear how these links were implemented, just that they were there and used to access the data in a reasonable way. This isn't just a giant slideshow. There are contextual connections. Here's the cool part that makes the movie map so special, though. This is going to be one of those caveat sections, but I think Aspen Movie

Map may have been one of the first digital encyclopedias. Or, to be extra accurate, a very early computerized encyclopedia, you know, since Laserdisc is still mostly analog. Historically speaking, hypermedia is a very personal format. And as we may think, Vannevar Bush does give lip service to sharing linked data, but at the end of the day, links are forged by the end user. You as a user generate a series of connections that can be shared, but are mainly your working notes. This can be with existing texts, but more often than not, it will be with a text generated by the user. This becomes more pronounced as the medium matures. Ted Nelson explains hypermedia as a format of totally free expression. But the bottom

line is that the entity expressing things is usually the end user. It's a very democratic medium in that sense. We see the same thing when we look at big extant systems like Engelbart's NLS. There's always this abstract idea that vast hordes of knowledge could be organized with hypertext, but that's kind of in the background. User-created organization is always the most in-your-face application of the technology. So, in a very conceptual sense, Aspen Movie Map is unique for the time. It used Laserdiscs to present a truly huge amount of data that was pre-linked to form something like an encyclopedia.

Thus, the main query becomes, are there earlier hypermedia systems with this level of pre-linked data? And if not, then why? This may be answerable. One possible predecessor would have been Zog, another system I've covered on the show. That hypertech system was developed in 1972 and evolved over the years. In the 80s, it was deployed on the USS Carl Vinson, an aircraft carrier. In that capacity, ZOG was used as a diagnostic and control tool. It also contained manuals and documents to help with the ship's operation. Earlier, it was used for medical applications. So that's approaching a digital encyclopedia,

but it's still a little fuzzy. It's unclear how much data we're talking about here, but it's probably on the order of a bookshelf. There's also the fact that Zog was initially intended as a souped-up data entry tool. That's kind of the dirty secret behind most early hypertext systems. Their main interface was a very advanced text or database editor. So, I don't know, I more think of Zog as traditional plus, if that makes any sense. It accepts user inputs and manages user-generated data, but also has this facility for reference data. NLS had something similar going on at some points. The system hosted its own documentation as hypermedia.

You could traverse these documents using pre-made links, but that was still an added feature to the larger parts of the system. Aspen MovieMap, by contrast, doesn't have data authoring tools at all. It's read-only. It's all about accessing and traversing data. The program is interactive, but not in the data generation kind of way. I know I'm veering into philosophical territory at the end here, but I think there's one more useful idea to put in our noggins. How do most people use the modern web? I mean, excluding things like social media, since that's a totally different can of worms. How do we engage with, say, Google or Wikipedia?

By and large, I'd categorize the usual use case as passive interactivity. We spend most of the time surfing the net, not so much adding to it. In that sense, Aspen Movie Map is an interesting omen of things to come. Alright, that brings us to the end of today's episode. On first glance, Aspen Movie Map may look like, well, a movie. But hopefully you now agree that under the hood, it's a pretty cool application of hypermedia. agree that under the hood, it's a pretty cool application of hypermedia. The forces that combine to make the movie map possible are strange, to say the least. The pressure of the Mansfield Amendment, plus the success of Operation Entembe, and the irrefutable power of the Laserdisc. Those all seem unconnected, but they made the perfect backdrop to digitize Aspen. Like I said, it's a weird story, but weirder things have happened, I guess. As we end here, I'd like to reiterate my main hypermedia conclusion this episode.

There have been huge changes in what hypermedia means between NLS and now. The current web is an amazing mass communication medium. It's a repository for most, and almost all, human knowledge. And the bulk of its use is a read-only type of affair. That's a massive shift from the kind of personalized nature of early hypertext. How did that change happen? That's a really big question that I think comes down to a slow evolution. Investigating these intermediary projects, like Aspen Movie Map, give us some insight into how this evolution was unfolding.

Thanks for listening to Advent of Computing. I'll be back in two weeks' time with another piece of computing's past. And hey, if you like the show, there are a few ways you can support it. If you know someone else who'd be interested in the podcast, then please take a minute to share it with them. You can also rate and review the show on Apple Podcasts. And if you want to be a super fan, you can support the show directly through adverting of computing merch or signing up as a patron on Patreon. Patrons get early access to episodes, polls for the direction of the show, and bonus content. I'm actually prepping for the next bonus episode right now, so it's a good time to sign on. You can find links to everything on my website, adventofcomputing.com. If you have

any comments or suggestions for a future episode, then shoot me a tweet. I'm at adventofcomp on Twitter. And as always, have a great rest of your day.