February 4, 2014 by clured

A Neatline-ified Gettysburg Address

Launch the Exhibit

This is a project that I’ve been hacking away at for some time, but only found the time (and motivation) to get it polished up and out the door over the weekend – a digital edition of the “Nicolay copy” of the Gettysburg Address, with each of the ~250 words in the manuscript individually traced out in Neatline and wired up with a plain-text transcription of the text on the right side of the screen. I’ve tinkered around with similar interfaces in the past, but this time I wanted to play around with different approaches to formalizing the connection between the digitally-typeset words in the text and the handwritten words in the manuscript. Your eyes tend to dart back and forth between the image and the text, and it’s easy to lose your place – how to reduce that cognitive friction?

To chip away at this, I wrote a little sub-plugin for Neatline called WordLines, which automatically overlays a little visual guideline (under the hood, a d3-wrapped SVG element) on top of the page that connects each pair of words in the two viewports when the cursor hovers on either of the instantiations. So, when the mouse passes over words in the transcription, lines are automatically drawn to the corresponding locations on the image; and vice versa. From a technical standpoint, this turns out to be quite easy – just get the pixel offsets for the element in the transcription and the vector annotation on the map (for the latter, OpenLayers does the heavy lifting with helpers like getViewPortPxFromLonLat, which maps spatial coordinates to document-space pixel pairs), and then draw a line connecting the two points. The one hitch, though, is that this involves placing a large SVG element directly on top of the page content, which, by default, will cover all of the underlying elements (shapes on the map, words in the text) and block them from receiving the cursor events that drive the rest of the UI – including, very problematically, the mouseleave event that garbage-collects old lines and prevents them from getting stuck on the screen.

The work-around is to put pointer-events: none; on the SVG container, which causes the browser to treat it as a purely visual veneer over the page – cursor events drop through to the underlying content elements, and everything else behaves normally. This is just barely and only very recently cross-browser, but I’m not sure if there’s actually any other way to accomplish this, given the full set of constraints.

Modeling intuitions about scale

Originally, I had planned to just leave it at that, but, as is almost always the case with these projects, I ended up learning lots of interesting things along the way, and I ended up going back and adding in another set of annotations that make note of some of the more historically noteworthy aspects of the manuscript. Namely, I was interested in the different types of paper used for the two different pages (Lincoln probably wrote the first page in Washington before departing, the second page after arriving in Gettysburg) and the matching fold creases on the pages, which some historians have pointed to as evidence that the Nicolay copy was perhaps the actual “reading copy” that Lincoln used when delivering the speech, since eyewitness accounts describe Lincoln pulling a folded piece of paper out of his coat pocket.

The other candidate is the Hay draft, which includes lots of changes and corrections in Lincoln’s hand, giving it the appearance of working draft that was prepared just before the event. One problem with the Hays draft, though, is its size – it’s written on larger paper and has just a single fold down the center, which would seem to make it an unlikely thing to tuck into coat pocket. When I read about this, I realized that I had paid almost no attention to the physical size of the manuscript. On the screen, it’s either extremely small or almost infinitely large – a tiny speck when you zoom far back, and an endless plane of beige-and-black when you zoom in. But, in this case, size turns out to be of great historical significance – the Nicolay copy is smaller than the Hays copy, especially when folded along the set of matching creases clearly visible on the pages.

So, how big is it? This involved a bit of guesswork. The resource page for the manuscript on the Library of Congress website doesn’t include dimensions, and direct Google searches didn’t turn up an easy answer, so I started poking around the internet to see if I could find other Lincoln manuscripts written on the “Executive Stationery” used for the first page. I rooted up a couple of documents for sale by rare book sellers, and in both cases the dimensions are listed at about 5 inches in width and 7-8 inches in height, meaning that the Nicolay copy – assuming the stationery was more or less standardized – would have folded down to a roughly 5 x 2.5-inch rectangle, which seems reasonably pocket-sized. (Again, this is amateur historical conjecture – if I’m wrong, please let me know!)

I sketched out little ruler annotations labeling the width of the page and the height of the fold segment, but, zooming around the exhibit, I realized that I still didn’t any intuitive sense of the size of the thing. Raw numerical measurements, even when you’re beat across the head with them, become surprisingly abstract in the a-physical, point-of-reference-less netherlands of deeply-zooming digital landscapes. I dug out a ruler and zoomed the exhibit back until the first page occupied five real-world inches, and then held my hand up to the screen, imagining the sheet of paper in my hand. And then I thought – why not just bake some kind of visual reference directly into the exhibit? I hunted down a CC-licensed SVG illustration of a handprint, and, using the size of my own hand as a reference, used Neatline’s import-SVG feature to position the outline in the whitespace to the right of the first page of the manuscript:

January 21, 2014 by clured

Lazy-loaded Backbone models

Imagine you’re building some kind of travel application and you have a Backbone model called City, with fields like name, latitude, longitude, and population, which are just run-of-the-mill, static values tucked away in a database row off on the server. Then, you realize that you also want to display the current weather forecast for each city – you need, in other words, to do something like:

city.get('weather')

Which is rather more difficult. The weather changes constantly – the only way to get it is to query against an API endpoint on the server, which, let’s say, dials out to a third-party service that returns a little 2-3 sentence summary forecast for a given location. It’s not the kind of thing that you can bake into the database – it has to be fetched on-the-fly, at runtime. Obviously, this is the exception, not the rule – in almost all cases, Backbone models will have a one-to-one correspondence with rows or documents in a database. Once in a while, though, there are situations in which models on the front end need to have “dynamic” or “compiled” fields that have to be filled in by AJAX requests in real-time, a pattern for which Backbone doesn’t really provide much guidance.

We ran into this problem recently with Neatline, in the process of reworking the interaction between records in Neatline exhibits with items in the underlying Omeka collection. If you haven’t had a chance to play around with Neatline, a “record” is the basic unit of content in a Neatline exhibit – a piece of vector geometry on an interactive map, an image thumbnail, a plotting on a timeline, a clickable waypoint, a georectified historical map, etc. Records can either be free-floating, unaffiliated little atoms of content, confined to a single exhibit (usually cosmetic elements like arrows or text captions that don’t need to have any kind of formal metadata description), or they can be linked back to items in the Omeka collection. Once a record has been associated with an item, it becomes a kind of proxy or alias for the item, a visual avatar responsible for presenting the item’s metadata in the exhibit. Think of it as an elaborate hyperlink that gives the Omeka item a spatial or temporal anchoring inside of a specific environment – one Omeka item could have ten customized instantiations inside of ten different Neatline exhibits.

The Neatline record, then, needs to be able to access the compiled metadata output of its parent item in the same way that it would access any of its own, locally-defined attributes. So, in other words, this:

record.get('item')

Needs to work in basically the same way as:

record.get('title')

Where title is just a standard-issue VARCHAR column on the neatline_records table. The difficulty, of course, is that there is no item field, at least not in the same way. Items are a hodgepodge of differently-structured components – individual metadata attributes (all stored separately as entity-attribute-value triples in the database), file attachments, images, and custom content threaded in by plugins. When it comes time to display an item, Omeka gathers up the pieces and glues them together into a final chunk of HTML, a process that, depending on where you draw the boundaries, involves many hundreds or thousands of lines of PHP. The item is an artifact generated by the application code, a customizable “view” on a bucket of related bits of information – not something that can just be selected straightforwardly from the database. This flexibility is what makes Omeka so powerful – it lets you represent almost any conceivable type of object.

But how to map all of it into a single Backbone model field?

Failed attempts

We’ve taken quite a few swings at this over the course of the last couple years. An obvious solution is just to fill in the item metadata at query-time on the server, right before pushing the results back to the client. So, query once to load the Neatline records and then walk through the results, calling some kind of loadItem() method that would render the item template and set the compiled HTML strings on the Neatline record objects. This is attractively simple, but it buckles under any kind of load – compiling the metadata output for each item involves touching the database at least once to gather up the element text triples (and often as many as three or four times, depending on the type of information requested by the templates), meaning that the Neatline API will generate at least one additional query for each record in the result set linked to an Omeka item. So, if a query matches 100 item-backed Neatline records, the MySQL server would get hammered with 101 queries, at minimum, and in practice more like 201 or 301, which slows things down pretty quickly.

In previous versions, we got around this by pre-compiling the item metadata and storing a copy of it directly inside the neatline_records table, thus making it immediately available at query-time. This was one of those good-on-paper ideas that dies by a thousand little cuts when it comes time to actually implement it. For starters, what happens if the user changes the template used to generate the metadata? All of the pre-compiled HTML snippets stored on the Neatline records suddenly become obsolete. This wasn’t a huge problem – you could always just click a button to re-import all of the item-backed records, which had the effect of re-rendering the templates. Still, an annoyance. More problematic was the whole set of obscure bugs that cropped up when trying to render the item templates inside of background processes, which Neatline uses when importing large collections of items into exhibits to keep the web request from timing out. For example, Omeka’s template rendering system depends on global variables (stuff like WEB_ROOT) that don’t get bootstrapped when code is run outside of the web container, which has the effect of mangling URLs in the templates, and so forth an so on.

Omeka as an API, not just a codebase

Then, a couple months ago, Jeremy had a great idea – why not wait until the item metadata is actually needed in the user interface, and then AJAX in the content from Omeka on an as-needed basis? Fundamentally, the insight here is to treat Omeka as an API, not just a codebase – circling back to the original example, the Neatline record becomes the City model, the item metadata snippets become the weather forecasts, and Omeka becomes the API that delivers them. Instead of trying to freeze away static snapshots of the item metadata, embrace the fact that the items are living resources that change over time (as metadata is updated, files added and removed, plugins installed and uninstalled) and turn Neatline into a client that pulls in final, presentational metadata produced by Omeka.

This turns out to be a really concise and low-code solution to the problem, but the implementation involves some interesting patterns to essentially trick Backbone models into supporting asynchronous getters – calls to the get method that need to spawn off an AJAX request to fetch the attribute value. First, though, I had to run the basic piping to get the data in place – I started by adding a little REST API endpoint on the server the emitted the metadata for a given item as a raw HTML string, and then added a simple method to the Neatline record Backbone model that pings the endpoint and sets the response on the model under an item key:

Once fetchItem has been called, the item metadata is fully hydrated on the model and ready to be accessed with regular get('item') calls. The problem, though, is that the extra step – needing to call fetchItem – breaks Backbone’s conventions for getting/setting data. Who’s responsible for calling fetchItem, and when? The model can’t really do it automatically in the constructor, which, for a collection of 100 records, would hammer the server with 100 simultaneous AJAX requests (eager loading!). But passing the buck to the calling code breaks things at various points downstream. For example, Neatline uses a library called Rivets to automatically bind Backbone models to Underscore templates, and Rivets assumes that the model attributes are all accessible from the get-go by way of the default get method. So, once again, this:

record.get('item')

Needs to behave in exactly the same way as:

record.get('title')

Even though the item value is actually being AJAX-in from Omeka, instead of just being read off of the internal attributes object.

Backbone.Mutators to the rescue

To do this, I used a library called Backbone.Mutators, which makes it possible to define custom getters and setters for individual attributes on a Backbone model – by folding a small bit of custom logic into a getter for the item field, it’s possible to automate the call to fetchItem in a way that preserves the basic get/set pattern:

Basically, the getter just checks to see if the item key on the internal attributes object is undefined (which is only the case the first time the key is accessed, before any data has been loaded), and, if so, calls fetchItem, which fires off the request for the metadata. A few milliseconds later, the request comes back and the response gets set on the model under the item key, which, in turns, triggers a change:item event on the model. If the record is bound to a template, this will cause Rivets to automatically re-get the item key, which calls the custom getter again. This time, though, the newly-loaded metadata set by the first call to fetchItem is returned, but fetchItem isn’t called (ever) again, since the item metadata is already set.

In practice, this means that there will be a short blip when a record is first bound to a template while the initial request is in flight, but, once it finishes, any subscriptions to the item key will automatically synchronize, and the item metadata will be available immediately for the rest of the lifecycle of the model instance.

Conclusion: An omeka-html action context or API format?

I can imagine a number of other situations in which it would useful to use Omeka as an API that emits the final, synthesized HTML metadata output for Omeka items – the item “show” pages, essentially, but just the item metadata HTML snippets, without the surrounding HTML document and theme markup. Neatline does this by grafting on a simple little Neatline-controlled API endpoint (essentially, /neatline/items/5) that renders an item.php partial template and spits back the HTML. I wonder, though, if it could be useful to actually bake some kind of omeka-html action context or API format into the Omeka core – something like /api/items/5?format=html.

The JSON API added in version 2.1 is ideal when you need to pluck out specific little chunks of data from the items for programmatic use, but less useful when you just want to show the item metadata. The API consumer could always pass the JSON representation of an item through some kind of templating system that would render it as HTML, but that just duplicates the same logic already implemented (no doubt much more robustly) in the Omeka core.

January 15, 2014 by clured

Neatline release-apalooza: Neatline 2.2.0, Neatscape, Astrolabe

[Cross-posted from scholarslab.org]

Today we’re excited to announce the release of Neatline 2.2.0! This is a big update that ships out a cluster of features and fixes that address a couple of rough spots identified by users over the course of the last couple months. 2.2.0 focuses on improvements in two areas – first, we’ve overhauled the workflows that connect Neatline records with Omeka items to make them more intuitive, flexible, and feature-rich, with the goal of making the overall integration between the two environments feel more seamless and low-friction. Second, we’ve added a system of interactive documentation to the editor that builds reference materials and tutorials directly into the interface, which should make it easier for new users to find their way around.

We’re also pushing out maintenance releases of the two extensions, NeatlineSimile and NeatlineWaypoints, which add compatibility for Neatline 2.2 and deal with a couple of minor bugs. As always, grab the code from the Omeka addons repository:

Neatline 2.2.0 | NeatlineSimile 2.0.1 | NeatlineWaypoints 2.0.2

What’s more, we’re also making release candidates available for two new Omeka themes designed to showcase Neatline exhibits: Astrolabe and Neatscape. Loyal readers may recall that a while back, we ran a theme naming contest, and we’re finally making good on our word! These are just release candidates, but we wanted to get them out in the open for testing and feedback before cutting off stable releases. Give them a spin, and be sure to file a ticket on the respective issue trackers (Astrolabe and Neatscape) if you find quirks or need new features.

Some highlights in Neatline 2.2:

Adds a new interface for linking Neatline records to Omeka items that makes it possible to browse the entire collection of items, run full-text searches, and instantaneously preview the Omeka content (metadata, images, etc.) as it will appear in the public Neatline exhibit.
Frees up the “Title” and “Body” fields for modification on Neatline records linked to Omeka items. Previously, these fields were automatically populated with the item content imported from Omeka, making it impossible to add custom information not contained in the Omeka metadata. Now, Neatline leaves these fields open for editing and displays them above the content synced in from Omeka, making it possible (though not required) to add exhibit-specific headings and text descriptions for imported items.
Makes it possible to import raw data from the Dublin Core “Coverage” field. When Omeka items are imported into Neatline exhibits, existing values in the Dublin Core “Coverage” field (either KML or WKT strings) are now automatically imported into Neatline and displayed on the map. Previously, this only worked if the coverage on the item was created with the Neatline Features plugin. With this functionality in place, it’s much easier to bulk-import existing spatial data sets – use the CSV Import plugin to populate a collection of items, and then push the new items to a Neatline exhibit.
Adds interactive documentation to the editor that builds reference materials for each individual control directly into the interface. Now, the heading for each input is followed by a little “?” button that, when clicked, overlays a document with information about what the control does, how to use it, and how it interacts with other functionality. The goal is to make the editor effectively self-documenting, so that it’s unnecessary to find separate documentation and toggle back and forth between different tabs as you work.

Last semester was a busy one for Neatline – we were supporting twelve classes here at UVa that are using Neatline for research assignments, and had the good fortune to collaborate with a number of folks at Harvard, Stanford, Northeastern, Duke, Indiana, and elsewhere who were using Neatline or gearing up for upcoming projects in the new year. We’ve also got a couple of exciting ideas brewing here in the lab for new, Neatline-powered projects – keep an eye on this space over the course of the next couple months.

As always, don’t hesitate to file bug reports on the issue tracker, post questions to the forums, or contact us directly. Happy new year!

December 11, 2013 by clured

Neighborhoods of San Francisco

View the Exhibit

Built on the Stamen Toner layer.

Back in October, about a month after moving from Scholars’ Lab HQ in Virginia out to Menlo Park (my partner started a PhD program at Stanford), I drove up the peninsula to San Francisco on a Saturday morning and set out on a long, rambling, 10-mile trek along the northwest shoulder of the city. It was a fantastic day – I walked west through Golden Gate Park, north along the Richmond beach, past the Cliff House, into the fog over Lincoln Park, through the mansions in Sea Cliff, past the abandoned artillery nests on the coast of the Presidio, and finally out onto the Golden Gate bridge. From there, I headed south through the trails in the Presidio, into Richmond, and eventually back to where I started, near the top right corner of the park.

From the middle of the Golden Gate Bridge, you can look out to the east over a large swath of the city – the skyscrapers of the financial district, the new span of the Bay Bridge hanging over Treasure Island, Alcatraz, and the faded outline of the East Bay, the Berkeley campus a little smudge at the base of the ridgeline. But, scanning my eyes over the rest of the city, I realized that I had very little sense of what I was actually looking at. I could attach labels onto all the touristy landmarks, but I didn’t have any kind of intuitive mental geography of the place – the names of all the little hills and neighborhoods, what connects to what, how to string the pieces of the city together into workable routes and itineraries.

So, over the course of the next few weeks, I slowly cobbled together a Neatline exhibit that plots out each of the neighborhoods in the city – 87 of them, by my count, although it’s somewhat a matter of interpretation as to how they should be sliced and diced. Working mainly from this image as reference, I started by tracing rough outlines of the boundaries (using Neatline’s standard-issue “Draw Polygon” tool) on top of Stamen’s Toner layer. Then, once the borders were in place, I used Neatline’s SVG import tool to place vector-geometry text labels on top of each of the individual neighborhoods, inspired by other spatial-wordcloud experiments like this and this.

Adventures in geospatial typesetting

This was great fun, and, interestingly, it ended up overlapping in unexpected ways with the interactive typesetting projects that I was playing with earlier in the semester. The process of positioning the labels becomes a kind of textual jigsaw puzzle, a game of trying to wrangle the raw, geometric instantiations of words into a coherent organizational scheme – except, this time, against the backdrop of actual geospatial coordinates and locations, not the abstract, featureless voids of the poetry experiments. Often, this is pretty straightforward – Noe Valley and the Inner Mission, for example, just get tagged as such:

In other places, though, the names of the neighborhoods overlap with one another in ways that make it possible to find interesting “economies” in how the words can be laid out on the map – when adjacent neighborhoods share the same words, it’s sometimes possible to essentially atomize the names into their component parts, and then rebuild them according to their own spatial logic, in a sense, by visually stringing together the pieces on the map. Take Richmond, for example, which is divided into three side-by-side segments: Outer Richmond, Central Richmond, and Inner Richmond. Instead of cluttering things up by repeating “Richmond” for each of the three sections, I just dragged out a single, all-encompassing “Richmond” across the entire width of the three sub-neighborhoods, and the blocked in the three modifiers as smaller words on top of the corresponding sections:

This worked much the same way for the Sunset and Parkside neighborhoods, which share the same cleanly partitioned spatial organization:

With the exception of the “middle” portion of Parkside, which is just the un-prefixed “Parkside,” meaning that the center piece doesn’t get a separate modifier:

In other cases, though, it gets much trickier, and much more interesting. Take the little cluster of neighborhoods at the southwest corner of the Presidio, the big park at the base of the Golden Gate Bridge. It’s a hodgepodge of repeated names, but in a much more scrambled and overlapping way – Presidio, Presidio Heights, Pacific Heights, Lower Pacific Heights. In this case, I had to take a bit more care to place the little black arrows in ways that didn’t connote incorrect linkages among the names. For example, the relationship between Presidio and Presidio Heights moves in just one direction – Presidio Heights (labelled with just “Heights” on the map) needs to “inherit” the “Presidio” modifier from the Presidio, but not the other way around, since the Presidio ceases to be the Presidio when “Heights” is tacked onto it:

To encode these relationships, I settled on a rule of thumb that the arrows would always be contained inside the neighborhoods that they modify. So, the arrow pointing from “Presidio” to “Heights” is fully contained inside of the geographic boundaries of Presidio Heights, in the sense that it pulls “Presidio” downward into the “Heights,” without also pushing “Heights” back in the other direction (which would effectively mislabel the Presidio). Likewise the link between “Pacific” and “Heights” is contained within the Pacific Heights outline, since otherwise Presidio Heights would be implicitly but incorrectly prefixed by “Pacific.”

Anyway, this is all completely useless as actual cartographic practice, but great fun as a kind of abstract étude of information design. It’s also incredibly useful as a mnemonic device – after untold hours in Palo Alto coffee shops sketching out all the outlines and positioning the labels, they’re all thoroughly burned into my mind. This is an interesting aspect of digital mapping projects that doesn’t get a lot of attention – we tend to focus on the final products, the public-facing visualizations and interactions (for good and obvious reasons), but much less on the process that goes into creating them, the personal acquisition of knowledge that takes place when you force yourself to spend dozens or hundreds of hours painstakingly positioning and repositioning things on maps. It gives you an incredible sense of cognitive intimacy with the space, the ability to load a little chunk of the world into working memory and reason about it in really complex and interesting ways.

October 11, 2013 by clured

“The Song of Wandering Aengus”

Click here to view the exhibit.

One last little experiment with Neatline-powered interactive typesettings – this time with the ending of Yeats’ endlessly recitable “The Song of Wandering Aengus,” which, like many great poems, seems to somehow signify the entire world and nothing really in particular. I chose to use just the last three lines so that it would be possible to play with a more dramatic type of geometric nesting that, with more content, would quickly run up against the technical limitation that I mentioned in Wednesday’s post about “A Coat” – the vector geometry used to form the letters starts to degrade as the Javascript environment runs out of decimal precision at around 40 levels of zoom, making it impossible to continue the downward beyond a certain point.

With just three lines, though, I was able to place each consecutive line completely inside of one of the dots above an “i” in the previous line. So, the “silver apples of the moon” are inscribed into the dot over the “i” in the “till” of “till time and times are done,” and the “golden apples of the moon” are then contained by the dot on the “i” in “silver.” Since the nested lines are placed literally inside the shaded boundaries of letters (as opposed to the empty spaces delineated by the “holes” in letters, as was the case with the first two experiments), the color of the text has to alternate in order to be legible against the changing color of the backdrop. What I didn’t expect (although in retrospect I guess it’s obvious) is that this shift in the color palette completely modulates the visual temperature of the whole environment – the backdrop swerves from bright white to solid black back and then back to white over the course of the three lines, with the last transition mapping onto the night-to-day, moon-to-sun thematic movement in the final couplet.

Interestingly, this effect was almost thwarted by another unexpected quirk in the underlying technologies, although I managed to maneuver around it with a little hack in the exhibit theme. The problem was this – it turns out that OpenLayers will actually stop rendering an SVG geometry ones the dimension of the viewport shrinks down below a certain ratio relative to the overall size of the shape. So, in this case, as the camera descends down into the black landscape of the dot over the first “i,” the black background supplied by the vector shape would suddenly drop away, as if the camera were falling through the surface, which of course had the effect of making the second-to-last line – typeset in white – suddenly invisible against the default-white background of the exhibit.

I thought this was a showstopper, but then I realized that I could programmatically “fake” the black background by directly flipping the CSS background color on the exhibit container. So, I just fired up the Javascript console, inspected the zoom attribute on the OpenLayers instance to get the zoom thresholds where the color changes needed to happen, and then dropped a little chunk of custom code into the exhibit theme that manifests the style change in response to the zoom events triggered by the map:

Weird, but effective. Whenever I work on projects like these I’m fascinated by the wrinkles that arise in the interaction between what you want to do and what the technology allows you to do. It’s very different from analog scholarship or art practice, where you have a more complete mastery over the field of play – you have a much more direct and unmediated control over the sound of your words, the shape of a line in a physical sketch, the pressure of a brush stroke. With digital objects, though, you’re building on top of almost unimaginably huge stacks of technology – the millions of man-hours of work that it took to create the vast ecosystem of Javascript and PHP libraries that Neatline depends on, the whole set of lower-level technologies that shape the underlying browser rendering engines and Javascript runtimes, which in turn are implemented in still lower-level languages, which eventually brush up against the dizzying rabbit hole of physical hardware engineering, which to my mind is about as close to magic as anything that people have produced.

That kind of deep, massively-distributed collaboration can definitely exist offscreen (eg., all of intellectual history, in a sense), but it’s more loosely coupled, and certainly less fragile – if I write an essay about Yeats, Yeats can’t break in the way that a code dependency literally can (will). At first this really bothered me, but I’ve come to peace with it – digital work is by definition a relinquishing of control, a give-and-take with the machine, a negotiation about what’s possible.