City Grids and the Imageability of Software Architectures

A large number of paths may be seen as a total network, when repeating relationships are sufficiently regular and predictable. The Los Angeles grid is a good example. Almost every subject could easily put down some twenty major paths in correct relation to each other. At the same time, this very regularity made it difficult for them to distinguish one path from another.¹

I’ve thought about grids. On the one hand, in a grid with too much regularity, its parts are indistinguishable from each other (if one ignores other factors that differentiate). On the other, a path network with too many irregularities gets confusing; it is difficult to grasp the whole. And Kevin Lynch writes that people tend “to impose regularity on their surroundings.”

Unless obvious evidence refuted it, they tried to organize paths into geometrical networks, disregarding curves and non-perpendicular intersections. The lower area of Jersey City was frequently drawn as a grid, even though it is only in part. Subjects absorbed all of central Los Angeles into a repeating network, without being disturbed by the distortion at the eastern edge. Several subjects even insisted on reducing the street maze of Boston’s financial district to a checkerboard!²

Consider Ildefonso Cerdá’s³ plan for Barcelona. A very regular grid with two diagonal streets that seem to ensure a healthy irregularity, enough to give character, but retaining the benefits of the grid. (Or so I guess.) It would be interesting to read about the imageability of Barcelona. My bet is that the diagonals significantly increases the imageability.

Now to software. I tried to recall some architectures from my past. The one with the highest imageability is from a project I was in between 1994 and 1998, where we spent 11 months designing—something I am sure I won’t ever experience again. That I so easily can recall this architecture owes to its regularity. We managed to create a system that uses the same concepts throughout the system, at different levels of scale. So there were a few clear, repeating patterns. I would say that this system had high imageability.

Then another, more recent system, which was harder for me to recall, but which we were very proud of regarding its design. After thinking about it for a while, I could recall most of it. It was a web application that functioned as a “wizard,” with a sequence of pages where the user made choices. Internally, the object that collected these choices was at the core of the design, surrounded by other objects that offered different types of functionality. Although we were proud of the design, my mental picture of it is not clear, so perhaps the design was too irregular (if imageability of this kind is of any value).

In the next project we participated in, we made the mistake of cloning much of this design. This system was considerably different and the concepts used in the former didn’t work well in the new context. At a later time, we restructured it to better reflect the structure of the user interface, but I would say that this system had even lower imageability. I still can recall it pretty well, but I think it will be harder in a couple of years. The user interface was organized into four major pages accessible via tabs, a separation we reflected in the internal design. But three of the tabs was radically different from the fourth, which constituted the biggest part of the system. So there was an imbalance. All the complexity was in this fourth part, and although it operated on the information entered and managed in the first three tabs, they were really two different systems.

I’m thinking about the visible versus the invisible, about how it seems to be a good idea to support internal designs, invisible, on elements in the user interface, the visible. In his book, Lynch refers to subways as detached from the city. Subways are invisible. They cannot “be related to the rest of the environment except where they come up for air,” as Lynch writes. Later he points out that people often use subway stations, even when going by car, as “nodes,” to determine where they are.⁴

Regularities are obviously good, but is there a point where a software architectures can get too regular (as seems to be the case with city grids)? Lynch writes, somewhere, about how parts of a city must be predictable to a certain extent, and that people can tolerate irregularities. Also, several different factors help to reinforce other types of weaknesses. So what irregularities are tolerable in software design, and how can you make up for weaknesses in order to achieve high imageability?

¹ Kevin Lynch, The Image of the City. See also “Kevin Lynch’s The Image of the City and Software Architecture” and “The Semiotics of Imageability.”

² Ibid.

³ I am confused as to whether his name is Ildefons or Ildefonso, but my bet is on Ildefonso.

⁴ Reading about this, I’ve thought about “The Real Underground”, an interactive map showing how the London Underground relates to the city.