A Discussion on Tech in Toronto: part iii | Tech(nologists) and Design
//Sidewalk Labs' project to build the Quayside community "from the internet up"
By Aisling O’Carroll
NOTE: This is a multi-part series to be released online over the next few months. See the other parts here.
TECH(NOLOGISTS) AND DESIGN
In an interview with Dezeen in June 2018, Rohit Aggarwala, head of Urban Systems at Sidewalk Labs, explained that technologists’ ability to apply digital technology to “more and more issues, more and more problems, and more and more opportunities,” and their ability to fast-track that process, are qualities that qualify them to be responsible for designing cities.(1)
In your opinion, are technologists qualified to design cities? What are the opportunities and/or risks associated with applying technology to, and collecting data from, “more and more issues”?
James Chan (JC) | It’s important to note that the possible contributions from a technologist’s point of view don’t have to be necessarily technical—often the biggest difference they can make is just a different way of seeing things, a different way of approaching problems, and a different way of working with other disciplines toward a solution. If anything, we need more designers to design cities. There are countless little things that escape the eyes of engineers and planners—think of the buttons at pedestrian crosswalks that are inaccessible in winter after the snowplows cover them in a mound of snow, or curbs at bus stops that don’t line up with the height of the doors, or sidewalks that clearly diverge from desire lines where people naturally want to walk—where a focus on user-centred design can make a huge difference in the day-to-day quality of life for citizens. The “build with, not for” mantra from the civic tech and design world is a particularly important mindset that should be more widely adopted within government.
Mariana Valverde (MV) | That statement demonstrates a woefully inadequate understanding of government—but it also misrepresents tech companies’ mission and mandate, which is to invent gadgets and software and make profits out of that.
Designing an app or a gadget is simply not relevant experience for designing cities. Cities are economic and social and political entities of great complexity. Computers are complex too, of course, but to say that a computer scientist or app developer has some special insight into urban governance and city problems is astoundingly hubristic. The reverse is also true: I know a great deal about city governance, and so I am very familiar, among other things, with the complexities of zoning and zoning appeals in Toronto—but I would never imagine that this qualifies me to comment on the architecture of the internet or the best way to use sensors to speed up traffic.
AnnaLisa Meyboom (AM) | I believe the design of cities needs to be a messy, collaborative, and democratic process. As such, technologists cannot do this alone but rather should play an active role along with citizens, their democratically elected representatives, and the experts on the many aspects of the city. This is a less efficient process, yes, but to circumvent this process means someone is assuming they already know what needs to be done—more autocratic political environments, for example, don’t have this inefficiency in their process. But if we have a democratically elected municipal government, do they have the right to pass over this responsibility to technologists who bypass the processes which have been developed by the citizenry over time in the name of efficiency?
Furthermore the question arises—for what reason do we need to fast track the process of city building? Is the goal of city building to be done quickly? Is there a necessity to be efficient? On the other hand, quick trials of new technologies that could provide benefit to the city’s inhabitants are a great way to combine technology, efficiency, and meaningful citizen input. The question is then, what is a scale and level of permanence that is suitable to do these trials—is the Sidewalk Labs experiment appropriate for this type of trial?
What may give the technology companies an advantage in the realm of city building is more likely to be their appetite for risk. Many cities in North America today tend to be very conservative in their appetite for taking risks and, as such, they also do not make radical changes or reap larger rewards that may result from the more radical ventures. One exception is New York City, where Mayor Bloomberg took significant risks during his time in office, many of which were successful and have been well documented. (2) San Francisco and Amsterdam (see Amsterdam Innovation Motor) have also recently experimented with urban technologies and had positive results. (3)
Adam Vaughan (AV) | What will be gained by ignoring data? The reality is that the data is coming, the technology will be developed somewhere, and the impact on the public is going to happen with or without Sidewalk Labs. Why not try to lead the debate rather than have the results wash over the city by default? With an eye on the climate change debate I am a little worried to scandalize science quite so quickly.
Efficiency, however, has always been a double-edged sword. Cities benefit as much from slow planning and development and well as they do from quick and fast solutions. Convenience is as important as efficiency. It’s just as true that many small-scale projects can sometimes out-perform larger, one-size-fits-all enterprises. It is always a balance and rarely just an assessment based on looking at the balance sheet. Often, city building is best done slowly.
Chris Green (CG) | The rapid escalation of the rate of technological change in the last few years has led not only to an increase in technological capability and sophistication, but to a lower barrier of entry both in terms of affordability and access to the required skill sets. Programming, for example, has arguably become more accessible to a wider spectrum of users from software engineers to interaction designers to a rich hobbyist community, resulting in code being used to tackle new kinds of creative and complex challenges, including ones with a focus on cities. In this way, as programming and technology become more accessible they enable a wider audience of not only technologists but also the public to engage with the realm of city building.
previous: part ii | Design
next: part iv) Trust in the City *coming soon
(1) Rohit Aggarwala, responding to a question from Eleanor Gibson on what qualifies technologists to be responsible for designing cities:
“One is [technologists] see how digital technology can be applied to more and more issues, more and more problems, and more and more opportunities.
When you think about everything from Uber to bike share, and now dockless bike share, and everything about traffic systems, there are ways to apply technological advancement to those systems that technologists are much faster to identify than people like me.
The other thing is there is a wonderful kind of impatience that is constantly asking the question: “well why can’t we change that faster, why can’t we try that out this quarter rather than over the next five years?” That’s really important because in the world of urban policy, planning, and architecture, we think in these multi-year and multi-decade type tracks.
It has to be tempered often by the reminder that the city is really not a set of systems that just need to be optimised, it’s a set of people, it’s a set of habits, it’s a set of understandings, it’s a set of social constructs, which the technologist’s background often undervalues.”
Rohit Aggarwala, interview by Eleanor Gibson, Dezeen, June 4, 2018, https://www.dezeen.com/2018/06/04/alphabet-sidewalk-labs-toronto-future-city-interview-rohit-aggarwala/#disqus_thread.
(2) Janette Sadik-Khan and Seth Solomonow, Streetfight: Handbook for an Urban Revolution (New York: Penguin, 2017).
(3) Tuan-Yee Ching and Joseph Ferreira, “Smart Cities: Concepts, Perceptions and Lessons for Planners,” in Planning Support Systems and Smart Cities, eds. Stan Geertman et al. (New York: Springer, 2017), 152–54.