Author Archives: clured

by

Neighborhoods of San Francisco

View the Exhibit

neighborhoods-of-san-francisco

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 western 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 ridge line. 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:

noe-valley-inner-mission

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:

richmond

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

sunset

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:

parkside

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:

presidio

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.

by

“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.

by

More fun with interactive typesetting: “A Coat,” by Yeats

Click here to view the exhibit.

After spending the weekend tinkering around with an interactive typesetting of a couplet from Macbeth that tried to model reading as a process of zooming downward towards the end of the phrase, I became curious about experimenting with the opposite analogy – reading as an upward movement, an climb from the bottom (the beginning) to the top (the end), with each word circumscribing everything that comes before it. Really, this is just the flip side of the same coin. Meaning certainly flows “downhill” in a phrase – each word is informed by the previous word. But it also flows back “uphill” – each word casts new meaning onto what comes before it. What would it would feel like to visualize that?

This time I decided to work with “A Coat,” Yeats’ wonderful little ode to simplicity (he renounces what he thinks to be the stylistic affectation of his work from the 1890’s, and announces an intention to write “naked[ly]“). Originally, I planned to exactly invert the layout of the Macbeth couplet – start with the “I” at the bottom of the stack, and work upwards towards the end with “naked,” which, in the final frame, would geometrically contain each of the preceding words. I started to do this, but quickly ran into an interesting computational obstacle, which actually cropped up in the Shakespeare example as well.

Trip Kirkpatrick noticed the problem:

Indeed, the last two words – “way” and “comes” – are pixelated and malformed:

way

comes

This wasn’t on purpose – I couldn’t figure out why it was happening when I was working on the exhibit, but decided against trying to fix it, half out of laziness and half because the visual effect had some satisfying affinities with the content of the line, especially when paired with the “descending” motif – a plunge down to hell, where order disintegrates, smooth lines are forbidden, etc. Anyway – after thinking it over, I’m pretty sure I know what’s going on, although I’m not certain. At the extremely deep zoom levels (far beyond anything you’d ever need for a regular map), I think that OpenLayers is actually losing the floating point precision that it needs to accurately plot the SVG paths for the letters – the computer is running out of decimal places, essentially.

I squeaked by with the Macbeth couplet, but this turned out to be a showstopper for the Yeats, since I was effectively trying to plot geometry about four and a half times deeper – 45 words versus 11. At that depth, the text becomes completely illegible, so I had to find a way to squeeze more content into fewer zoom levels. In the end, I managed to fit it all in by positioning each line into a geometric “notch” formed by the ascenders of two letters on the following line, which more or less preserves the philosophical rationale of the exhibit (each bit of text “envelops” the previous, if somewhat less completely than before) while limiting the zooming to just ten magnification contexts, one for each line.

heel

To scan the poem, just zoom out by clicking on the “minus” button (or scrolling the mouse wheel or pinching the screen, if applicable), or click on the lines in the reference text at the top left to auto-focus on a particular part of the poem.

by

Experimental typesetting with Neatline and Shakespeare

Click here to view the exhibit.

I’ve always been fascinated by the geometric structure of text – the fact that literature is encoded as physical, space-occupying symbols that can be described, measured, and manipulated just like any other two-dimensional shapes. There’s something counter-intuitive about this. When I look at a letter or a word, I see particles of sound and meaning, transcendental cognitive forms, not things that could be straightforwardly described as a chunks of vector geometry. And there’s definitely a truth to this – I do think that texts have a kind of extra-physical cognitive essence that’s independent of their visual instantiations on pages or screens, and that it’s usually this common denominator that’s most interesting when we talk about literature with other people. And yet, in the context of any individual reading, the physical structure of documents – the set of pragmatic decisions that go into the design, layout, and formatting of text on the page – can have subtle but significant effects on how a text feels, on the imaginative dreamscape that surrounds it in your mind when you think back on it days or weeks or years after the fact.

This is definitely true, for example, at the level of some-thing like font selection, which encodes a kind of “meaning metadata” about the text – where it comes from, who it’s intended for, how serious it imagines itself to be, etc. But I think it also holds at the level of more incidental, pseudo-random aspects of typesetting. For example, how does the vertical line traced out by the right margin of a paragraph or stanza color the reader’s affective reaction to the literary content? Does a jagged, unjustified border make the text feel more tumultuous and Dionysian? Would the same text, printed with a justified margin, become more emotionally controlled and orderly? I think of cases like Whitman’s long lines, which often have to be prematurely broken at the right edge of the page, resulting in a kind of clumpy, disorganized visual gestalt. I doubt that Whitman intended this, in the strong sense of the word (although I don’t know that he didn’t), but it has a kind of symbolic affinity with the poetry itself – sprawling, organic, uncontainable. When I think of Whitman, the image that appears in my mind consists largely of this. I wonder what it would be like to read an “unbroken” Leaves of Grass, printed on paper wide enough to accommodate the lines? Would it become more metaphysical, detached, ironical? Or would it be just the same?

Anyway, this kind of speculation fascinates me. I’ve been thinking a lot recently about experimental modes of digital typesetting that would be completely impossible on the analog page – new ways of presenting text on screens to evoke certain feelings or model intuitions about the structure of language. As a quick experiment, I decided to use Neatline to try to capture a certain aspect of my experience of reading Shakespeare. I’ve always been interested in the notion of language as kind of progressive enveloping of words – they’re printed side-by-side on the page as equals, but the meaning of a syntagm grows out of the ordering of the tokens. Each exists in the context of the last and casts meaning onto the next; each word is contained, in a sense, inside the sum of its predecessors. I was taken by this idea when I read Saussure and company in college, because it seemed to map onto my own experience of reading poetry – the sensation of scanning a line always felt more like a descent than a left-to-right movement, a shift from the surface (the beginning) to the center (the end).

To play with this, I built a Neatline exhibit that typesets a single Shakespearean couplet in a kind of recursive, fractal, Prezi-like layout in which each successive word is “physically” embedded inside of one of the letters of the previous word. Reading the couplet literally becomes a matter of magnification, zooming, burrowing downwards towards the end of the syntagm. To scan the fragment, either pan and zoom the environment manually, as you would a regular, Google-like slippy map, or click on the words in the reference text at the bottom of the screen to automatically focus on individual slices of the text.

by

Neatline 2.1.0

[Cross-posted from scholarslab.org]

We’re pleased to announce the release of Neatline 2.1.0! This is a fairly large maintenance release that adds new features, patches up some minor bugs, and ships some improvements to the UI in the editing environment. Some of the highlights:

  • A “fullscreen” mode (re-added from the 1.x releases), which makes it possible to link to a page that just displays a Neatline exhibit in isolation, scaled to the size of the screen, without any of the regular Omeka site navigation. Among other things, this makes it much easier to embed a Neatline exhibit as an iframe on other websites (eg, a WordPress blog) – just set the src attribute on the iframe equal to the URL for the fullscreen exhibit view. Eg:

    Thanks coryduclos, colonusgroup, and martiniusDE for letting us know that this was a pain point.

  • A series of UI improvements to the editing environment that should make the exhibit-creation workflow a bit smoother. We bumped up the size of the “New Record” button, padded out the list of records, and made the “X” buttons used to close record forms a bit larger and easier-to-click. Also, in the record edit form, the “Save” and “Delete” buttons are now stuck into place at the bottom of the panel, meaning that you don’t have to scroll down to the bottom of the form every time you save. Much easier!

    neatline-2.1

  • Fixes for a handful of small bugs, mostly cosmetic or involving uncommon edge cases. Notably, 2.1.0 fixes a problem that was causing item imports to fail when the Omeka installation was using the Amazon S3 storage adapter, as we do for our faculty-project installations here at UVa.

Check out the release notes on GitHub for the full list of changes, and grab the new code from the Omeka add-ons repository. And, as always, be sure to send comments, concerns, bug reports, and feature requests in our direction.

In other Neatline-related news, be sure to check out Katherine Jentleson’s Neatline-enhanced essay “‘Not as rewarding as the North’: Holger Cahill’s Southern Folk Art Expedition,” which just won the Smithsonian’s Archives of American Art Graduate Research Essay Prize. I met Katherine at a workshop at Duke back in the spring, and it’s been a real pleasure to learn about how she’s using Neatline in her work!