Interfacial Relations

Reconceiving the computer-generated render as an interface for human interaction rather than a static object


arely does an urban redevelopment project not now use computer-generated images (CGIs) to visualise what the project will look like when complete. Over the past five years, CGIs have become commonplace as a means to market urban redevelopments. From advertisements found on bus stops and on building site hoardings (fig 1), to elaborate websites and exhibitions at global real-estate fairs, digital visualisations of developments not-yet-built are ubiquitous. Indeed, it could be argued that they are now one of the most pervasive ways in which visions of future urban spaces are expressed.

To date, however, they have been given relatively little attention as a new form of visualising the urban. When they have been examined, their digitality has been understood only as enhancing the ability of images to represent places – in this case, places not yet built – in ever more seductive and persuasive ways.

While it is without doubt the case that digital visualisations have some similarities with non-digital marketing images – and indeed with much longer traditions of representing designs for urban spaces – this paper will nonetheless argue that such CGIs are distinctive. They thus deserve more attention, and attention of a particular kind.

This paper does not explore the ‘effect’ of these images as they appear on temporary hoardings around building sites or on billboards advertising new developments, however. Rather than approach them from their materialisation in cities, we instead approach these CGIs from their circulation through networks; and as a consequence, we no longer want to call them ‘images’ but rather ‘interfaces’.

This paper does not explore the ‘effect’ of these images as they appear on temporary hoardings around building sites or on billboards advertising new developments, however. Rather than approach them from their materialisation in cities, we instead approach these CGIs from their circulation through networks; and as a consequence, we no longer want to call them ‘images’ but rather ‘interfaces’.

By starting with their network, this paper engages with the appearance of these visualisations by focusing less on what they show and more on how they are made to show it. For they are made to show it as they circulate around a network of offices and computer screens; they are worked on by architects, visualisers, project managers, the client, advertising executives and others; and the visualisation’s digital file thus constantly encounters various software programs, hardware devices and human bodies. It is the importance of these encounters that makes us think of these CGIs less as images and more as interfaces, and the following section of the paper details this conceptual claim.

By starting with their network, this paper engages with the appearance of these visualisations by focusing less on what they show and more on how they are made to show it

The arguments presented here are based on a case study of a large-scale urban redevelopment project which has taken the production of CGIs very seriously indeed. The €4.18 billion project covers a 31ha site in Doha, Qatar, and is currently called Msheireb Downtown. The design of Msheireb Downtown began in 2008; construction started in 2010 and is scheduled to finish in 2016. The developer – the architects’ client – is Msheireb Properties, a company owned by the Qatar Foundation.1 The concept masterplan was produced by AECOM, and AECOM, with Arup and London architects Allies and Morrison, drew up the detailed masterplan. There are a further range of sitewide and executive consultants with specific responsibilities, co-ordinated by the Master Development Consultants (MDC) team, and including Executive Consultants (EC), Executive Architects (EA) and landscape architects among others. Nine design architects (DAs) were chosen to design the hundred or so buildings on the site. A partner at Allies and Morrison was appointed as the Architectural Language Advisor (ALA) to the project, and has been a particularly enthusiastic advocate of the project’s CGIs as a means of cohering the project’s different components into, as he said, ‘something one wants on the cover of a magazine’.

Here, then, we have a developer of a large-scale urban redevelopment project investing significant time and money in creating a suite of CGIs that will picture ‘how that place will look and feel’ (MDC manager) when it is finished.2 The investment in CGIs as part of this project is at an unusually high level; but their evident importance to this project makes it a valuable case study for thinking about how to conceptualise them (and for understanding why they have become so common in contemporary urban development). Drawing on existing workplace ethnographies of design professionals,3 our methods were to observe the creation of these images by both architects and visualisers, and to observe their discussion at two Design Review meetings in Doha; to interview architects, visualisers and representatives of the client about their use of CGIs; and to gather examples of where CGIs were used as part of the project.

The final section will argue that, given the sort of images they are, scholarship concerned with architecture and urban design should understand these CGIs not only as persuasive marketing images, but also as problematic interfacial sites created by many different kinds of work

The aim of this paper is to conceptualise these CGIs as interfaces, and it will draw on evidence from our ethnography to substantiate its claims. The next section begins this task by examining the concepts of network and interface. The third section explores three interfaces that we argue are particularly significant for understanding the nature of these CGIs. The final section will argue that, given the sort of images they are, scholarship concerned with architecture and urban design should understand these CGIs not only as persuasive marketing images, but also as problematic interfacial sites created by many different kinds of work.

Conceptualising CGIs: network and interface

The CGIs that visualise new urban development projects have, as already noted, received little scholarly attention. The few studies that do address them concentrate on their affective power as visual images.4

Figure 2. A hoarding on the edge of the Downtown Doha construction site, November 2012

It is certainly the case that the CGIs created for Msheireb Downtown were concerned to create a seductive ‘affect’.5 In the first instance, CGIs were developed by the masterplanners as means of persuading Msheireb Properties and the Qatar Foundation to invest in the redevelopment project. As the MDC manager described them, initially there were ‘around twenty images … more describing the mood of the whole development. So it was not about “that’s the building, that’s this building”, they were showing more “that’s the life on the street, this is what you’ll feel by taking the journey through the development”’. A Special Design Review meeting in 2012 finalised 42 such images, and they have been appearing at real estate fairs and on the developer’s website and promotional literature since then, as well as on hoardings surrounding the building site that is currently Msheireb Downtown (see fig 2).

However, as one of us sat down with architects and visualisers at their office computer screens and asked them to tell us about these 42 images, it became apparent that they were just a tiny fraction of the total number of images made as part of this project. Not only had the production of those 42 entailed the creation of vast numbers of earlier versions – both of the 42 and of other CGIs that might have become one of the selected 42 – but all sorts of other digital visualisations of Msheireb Downtown had also been created as part of the design process.

The creation of all these CGIs had involved a large number of people in many different places: the architects; the visualisers, of course; and the CGI may well have visited render farms in China too. The ALA also commented on the CGIs. When the ALA was satisfied, the CGI would be taken to Design Review meetings in Doha, where (along with many other images, material samples and models) it would have been discussed with the client, the MDC, the EC, the ALA, other consultants and (sometimes) the DAs, as part of the ongoing process of designing the development.6 This iterative process accounts for the huge numbers of CGIs created; a printout of the file names of all the CGIs generated for just one building in Msheireb Downtown by Allies and Morrison ran to 60 pages.

As well as the sheer numbers of CGIs generated, it should also be evident from the above account that the CGIs are highly mobile. And their mobility continues even after ‘final’ versions have been agreed (the 42 agreed in November 2012 were being revised a year later to reflect design changes). The ‘finished’ CGI as a digital file goes to all sorts of other places and in the process it gets converted into different media. So, it appears on the pages of promotional books and on the websites of the developer, to advertise their project (Msheireb Properties has a website, a YouTube channel and a Facebook page). The developer has also used the image in other promotional media: on billboards, as smaller posters and part of interactive models at real-estate fairs, and as framed prints in their offices. It may also travel to the websites of the architect and the visualiser and in order to advertise their skills. Already it is obvious why CGIs are popular with developers: they are seductive images; their content can be easily altered; and they can be displayed in many ways via various media.

Latour notes that “the notion of network is of use whenever action is to be redistributed”. And indeed, the CGIs of Msheireb Downtown move because work needs to be done on them: they have to look more accurate, or more attractive, for example. Thus they move in order to be acted upon, to be modified

As they are created, then, these CGIs travel extensively through a network of different offices, servers and screens. As many commentators have remarked, ‘network’ is a term with multiple meanings.7 Here, we follow an Actor Network Theory (ANT) approach. Latour notes that ‘the notion of network is of use whenever action is to be redistributed ’.8 And indeed, as we have just described, the CGIs of Msheireb Downtown move because work needs to be done on them: they have to look more accurate, or more attractive, for example. Thus they move in order to be acted upon, to be modified. And as they move, they constitute two specific forms of network spatiality.9

The first is the circulation of these CGIs through a network in what Law describes as Euclidean space.10 In this network, these images move in physical space, as digital files, through the material infrastructure of the internet and a wide range of associated technologies such as cables, computers, servers, printers and screens. This movement is crucial to track, as it speaks directly to the skewed global distribution of this kind of creative expertise; as others have also pointed out, creative expertise is located in specific cities of the Global North,11 and, bar trips to render farms, until they were taken to the client in Doha the images we studied circulated only between Europe and the USA.

The CGIs were versions of the views, and as such they were highly mutable mobiles as they travelled through their network, their code and the media which visualised them constantly changing

This paper pays particular attention to the second sort of network space identified by Law, however, which is less an effect of the CGIs’ mobility and more of the action needed to maintain their integrity as an object. The claim that ‘objects are an effect of stable arrays of networks or relations’ is conventional in ANT;12 ‘an object … remains an object while everything stays in place and the relations between it and its neighbouring objects remain steady’. 13 Although this paper has so far suggested that the object that moves is ‘the CGI’, in fact the object that held steady was not ‘the CGI’, or its software code. As the paper has already implied, code was constantly changed as a CGI was worked on; and the media through which the code generated a visible image were also multiple (other softwares, various display screens, printers, inks, projectors, papers, frames, books …). To be precise, what held steady was the view that a CGI was to visualise. All of the 42 CGIs which won the client’s approval were views of streets and public places. The ALA initiated their creation by specifying on a plan of the development which ‘views’ he wanted to see visualised in a CGI. The CGIs were versions of the views, and as such they were highly mutable mobiles as they travelled through their network, their code and the media which visualised them constantly changing. Hence this paper’s attentiveness, less to what a CGI looks like at any one of its many stages, and more to what it ‘needs to subsist through a complex ecology of tributaries, allies, accomplices, and helpers’.14

What also became evident early on in our fieldwork was that this ‘ecology’ was not only complex but also somewhat unstable. Relations among various ‘allies, accomplices, and helpers’ were not always ‘steady’, and this also contributed to the mutability of the CGIs. Latour suggests that those allies, accomplices, and helpers become particularly noticeable in moments of crisis:

Take any object: At first, it looks contained within itself with well-delineated edges and limits; then something happens, a strike, an accident, a catastrophe, and suddenly you discover swarms of entities that seem to have been there all along but were not visible before and that appear in retrospect necessary for its sustenance.15

Our research did not encounter any ‘strikes, accidents or catastrophes’ (though several of our interviewees recalled working through the night to complete CGIs for Special Design Review meetings). The specific concept this paper uses to examine the ecology of the CGIs’ ‘swarms of entities’, therefore, is the interface. An interface is the intersection between two objects or systems. In digital studies, use of the term is often restricted to the relation between a human and a digital device, or, to be more specific, to contact between eyes, hands, screens, mice (or graphics tablets), keyboards (or gaming control pads) and the software driving the hardware (fig 4). An interface is thus ‘a point of contact at which different bodily or machinic systems meet’.16 We draw on Galloway’s elaboration of the term here.17 Galloway describes interfaces as ‘zones of activity’,18 which can be ‘manifest (as screens or keyboards), but also latent within software as the mediation between internal and external levels’.19 Interfaces, then, are where the action happens in a CGI’s network. Importantly though – and this addresses both Law’s concern that ANT approaches to networks pay too much attention to things being made stable, as well as avoiding Latour’s need for catastrophe to make an object’s allies visible – Galloway insists that interfaces are never quite as smooth as they so often look and feel. An interface, he insists, is ‘an autonomous zone of interaction, orthogonal to the human sensorium, concerned as much with unworkability and obfuscation as with connectivity and transparency’.20 Rather than events such as accidents or catastrophes, then, in this paper frictional interfaces are the sites where the CGIs’ allies, accomplices, and helpers become evident.

The paper now turns to three such sites.

The interfaciality of the CGI

This section emphasises not only the work being done to create the CGIs at three specific interfaces by humans, softwares and hardwares, but also different kinds and degrees of unworkability and the actions taken to mitigate that friction. These three types of interface – ‘intrafacial’, ‘designed’ and ‘annotated’ – are addressed in turn in the three subsections that follow.


One of the most fundamental interfaces in the Msheireb Downtown project was that between different software packages and different software files. Galloway’s term for the interface where different software components interact is the intraface. A CGI file is based on a digital 3D model imported from CAD software, and it also migrates from a visualisation software into Photoshop: the points of contact where these different softwares interact with each other and with other softwares (for example, a computer’s operating system) are all intrafaces.

Intrafaciality within a software package usually runs smoothly. Intrafaciality between files, software packages and operating systems can be more problematic. The Msheireb Downtown project had a particular level of complexity because all the different CGIs files created by different architects and visualisers had to be compatible with each other

Intrafaciality within a software package usually runs smoothly. Intrafaciality between files, software packages and operating systems can be more problematic. The Msheireb Downtown project had a particular level of complexity, however, because all the different CGIs files created by different architects and visualisers had to be compatible with each other. This was because the CAD models and associated visualisations of individual buildings made in each DA’s office had to be integrated into a single file in order to create the ‘views’ specified by the ALA.

Early on, then, the EC produced a pdf of guidelines that all the 3ds Max models created as part of the design process were obliged to follow. Its aim was ‘to deliver consistent electronic deliverables’. The document ordered visualisers to use the co-ordinate template provided by the EC; specified acceptable file formats; described the required conventions for naming each file, each material and each layer within the 3ds Max model; noted the geometry to be used (for example, ‘all objects will have wielded [sic] vertices’, ‘no double geometry is allowed’); and insisted on the inclusion of ‘all native package files’ in the deliverable. These guidelines were a crucial member of the ‘swarm of entities’ that held the CGIs together as objects. Without these guidelines, the CGI views – which were built from multiple distinct, CAD models – would not have been possible. Here, then, we can see that the work that creates a CGI is not only the work that is done on the CGI file itself, but also the work that is done to ensure that it can move through its network and be acted on elsewhere.


The CGIs are also of course looked at by people. In fact, the need for CGIs to be appropriate for specific viewers was a recurring theme as we discussed CGIs with architects, visualisers and various employees at Msheireb Properties. It became very clear that they were all aware that CGIs could – and indeed should – be put to work in very different ways at different points in their circulation and modification. As a visualiser commented, ‘you can change [digital] content a lot more easily than you can change a physical thing, and you can tell multiple different stories with different options depending on who you are talking to’.

As the paper has already noted, it was the masterplanners – Allies and Morrison and AECOM – who initiated the process of creating CGIs for Msheireb Downtown very early on in the project, when they were ‘pitching’ to Msheireb Properties to take the project on. CGIs were understood as a crucial means for describing to the client what sort of place the proposed plans would create: ‘you need the image. It’s a sales pitch in a funny way’ (MDC manager). There was also widespread agreement among the visualisers and architects we interviewed that leading the pitch for Msheireb Downtown with photo-realistic CGIs was especially important for a project in the Middle East, because clients there were often not experienced in interpreting the plans, sections and elevations with which architects would usually explicate their designs. In that context, you ‘almost have to make CGIs before you have a scheme’ (AECOM manager). 21 After an initial presentation which included a separate presentation from each of four architects was rejected by the client because of its incoherence, the sorts of images designed for the client focused much more on the overall ‘look’ of the project, and showed ‘all the buildings, all the environment built, cars, people, bicycles, you know’ (visualiser). Once the client agreed to invest in the project, this sort of image was then used to present portions of the development to the most senior figures at Msheireb Properties at Design Review and Special Design Review meetings.

While, as has been noted, a set of 42 CGIs are being used to publicise the development, in spring 2013 a completely new set of CGIs was commissioned specifically to market the development to investors. The Development Manager at Msheireb Properties was clear that, to lease office space, for example, different sorts of visualisations were required:

the leasing team are very particular on what they want. So you’ll see of all these office buildings, there’s really four shots that they’re interested in seeing and that is a shot of the main entrance. A shot of within the lobby. A shot internally on one of the standard floors looking out if there’s a feature like the Baraha they’re going to show that. And they also want a hero shot of the building possibly showing, you know, two facades or two sides of the building that they can put on the cover of the brochure. And then obviously within the brochure there’ll be some other images of sitewide attractions and different facilities that they believe will help market the building or the project.

Even among CGIs used for ‘marketing’, then, different visualisations are used for different sorts of selling.However, marketing these new buildings – whether to Msheireb Properties or to potential leasers of office space – is only one of the uses to which CGIs were put as part of the Msheireb Downtown project by architects, visualisers, the MDC and the client. The client was sent less polished CGIs by architects to demonstrate that a certain design task had been finished and to request payment, for example. And the architects themselves worked with digital visualisations as part of their design process. Many CGIs were created by the architects and masterplanners themselves as a means of developing designs for buildings, streets and squares. Relatively basic, pre-Photoshop CGIs can be quickly changed, which also allows architects to experiment with different volumes and materials. As one DA said, CGIs (made in SketchUp in this case) are a ‘quicker means of showing the massing, changing massing. We used to have a top floor overhang; when we removed it, what did it look like?’ Sometimes these basic CGIs were also shown to the client to see if a new idea was worth pursuing. Different kinds of CGIs were also used by the EC to co-ordinate the various contributions from different architects into integrated streets and squares. Using 3ds Max models from each DA, the EC produced around 300 basic CGIs ‘to describe every corner of the project’; these ‘massing studies’ showed buildings as simplified white blocks because their purpose was to ensure that all the different volumes and shapes cohered to produce a good urban design.

The Msheireb Downtown CGIs, then, exemplify Kress’s argument that digital forms of communication are very often tailored to the specific context of their use. 22 Their interface is designed to engage with specific actors, in particular circumstances. A consequence of this designed interface, however, travelling through a network of diverse actors, is that different allies of the CGIs disagreed over specific CGIs. Throughout the Msheireb Downtown project, there were tensions between architects, masterplanners, ALA, client and visualisers, who all wanted different kinds of images which would do different things by looking different. The client rejected CGIs that didn’t look adequately Qatari, and this was just one example of how the different actors in the CGIs’ network had different views on the images. Neither the DAs nor the ALA liked the marketing ‘hero shot’; the architects tended to be much more fascinated by what one called ‘the backstreet world’. Both the DAs and the masterplanners were also uncomfortable with the sorts of CGIs made for the client, both as part of the pitch and as part of the design process. They are ‘one sided’, according to an AECOM interviewee: good at ‘engaging people’ but not so useful for design work because they often show ‘things that lead to inappropriate discussions’. Another architect explained, ‘people tend not to look at the architecture but at the image and make decisions based on liking or not liking the image’. And a visualiser pointed to another tension, between his desire to produce a beautiful, well-composed image and the architects’ desire to show the details of their buildings, which led to his views on how the image should look being ‘slightly hijacked’.

This subsection has suggested, then, that it is not only the intrafaciality of these CGIs that creates frictional interfaces as the digital files circulate through, and are read by, their network of different actors. So too does the fact that DAs, EAs, masterplanners, visualisers, the client and the ALA are all hoping for something different from them. Indeed, a lot of the disagreement about the CGIs was between groups with different interests, which were expressed through distinct forms of visual imagery: the architects wanted CGIs that showed their buildings in the best light, for example, while the visualisers preferred striking images of the development’s public spaces that would demonstrate their creative expertise. Once again, however, action occurred that minimised these frictions between the (different) CGIs’ (different) allies. In particular, a clear decision-making hierarchy emerged as the project developed, supported by an infrastructure for sharing commentary on, and decisions about, specific images.


The importance of ‘consistent electronic deliverables’ to the CGIs, in terms of their technical specifications, has been discussed. The CGIs were also all contributing, as has already been noted, to creating a sense of ‘how that place will look and feel’; they thus all also had to be ‘of similar style and similar quality’ (MDC manager). It has been suggested, however, that their ‘style’ could also be contentious. This subsection emphasises the specific ways in which these different opinions about the CGIs were articulated in a form that could travel through their network, to distribute action on the CGIs elsewhere.

CGIs undergo a near-constant process of drafting and redrafting. Architects want their buildings to look right; visualisers want the CGI views to look striking; the ALA wants them to have ‘magic moments’; the client wants them to look distinctively Qatari. These various allies of the CGIs all look at versions of the CGIs at various points in their production, as printouts, as projections and on computer screens. As part of that looking, they also make comments about how the CGIs need to be modified. Comments are made verbally, in architects’ and visualisers’ offices, at Design Review meetings, in other face-to-face meetings and over the phone. There is also lots of discussion in front of screens by both visualisers and architects. Many of these comments are about the accuracy of the CGI in relation to agreed design, but others are much more subjective, remarking on the aesthetic feel, or quality, of the image. One architect suggested these conversations around a screen were the most effective form of communication between architects and visualisers, a claim which favours working with local collaborators.23 And this points towards a particular problem faced by the Msheireb Downtown project: many of the comments about CGIs could not be made between people having a conversation in front of a screen, because the person to whom the comments were directed was located in a different place in the network. Hence, comments on a CGI had to travel with the CGI, from location to location, from DA to visualiser, or from ALA to MDC, or from client to DA.

So that encounter between image and human viewer had to be converted into something that could travel with the CGI, to communicate the work that had to be done on it to others. Various forms of annotation were employed to achieve this transfer. Word documents and spreadsheets were created, listing the actions required or completed on specific files; pdf files of the images were annotated on screens and then saved as new files to be sent on; while the ALA preferred to print out copies of the pdf files, scribble his comments on them, and then scan the printouts for onward circulation (see fig 4). These various textual devices acted as inscriptions of the viewings of the CGIs by various actors in the network, carrying their reactions to, and instructions about, the CGIs to other actors elsewhere, initiating more actions.

Figure 4. A printout of a CGI marked up for revision by the Architectural Language Advisor

This was how a lot of the friction described in the prevous subsection was articulated, as annotations from the ALA conflicted with what visualisers thought was best, or as visualisers’ comments trumped those of the DA. Another difficulty was how to circulate large numbers of both images and comments among so many people efficiently. It was difficult to know if a DA or visualiser had the latest version of a CGI when they were being circulated and downloaded in lots of different places.

Once again, work was done to lubricate these frictions. The project’s EC set up a cloud storage facility to ensure that everyone had access to the latest versions of files. More importantly, a clear hierarchy was established which reflected, and enacted, whose comments mattered most. As one DA explained, ‘there was a hierarchy to the comments … [the client’s were the most important … [the MDC manager’s] were kind of the second most important. And, you know, [laughing] then there was sort of [the ALA] was somewhere way up there. And, you know, my comments were sort of, you know, scraping the ground somewhere.’ Indeed, the DAs particularly resented their views being ignored, and so the EA eventually began to respond to the architects’ frustration by acknowledging their comments even when they were ‘subjective’ (EA) and had been overridden by the EA’s overview of the project. However, the EA also ensured that the client/MDC/ALA decisions were implemented by sending ‘the master comments’ direct to DAs, who could not then ignore them.

However, these efforts to co-ordinate and prioritise the actions required on the CGIs were not entirely adequate, and this was because of the translation required from a visual encounter with a CGI to a written description of that encounter. There was something about the annotation interface between certain actors and the CGIs that did not in fact travel very well. In particular, the ALA’s suggestions for ways to create more ‘poetic’ images – his requests, visible in fig 3, for ‘atmosphere’, ‘more magic’ and ‘MM’s (magic moments) – proved difficult for visualisers and architects to understand. One DA told us, ‘[the in-house visualiser] just kept looking at me going, “I don’t understand. What does he mean more magic? He wants like a man flipping cards? I don’t know!”’

This visualiser’s puzzlement exemplifies the value of the concept of the ‘interface’ for understanding what sort of things these CGIs are, as they travel between Europe, the USA and the Gulf. As a 3ds Max or Photoshop file is run in specific offices – whether the office of an architect or a visualiser, or the client – it visualises a specific view of the unbuilt Msheireb Downtown project. It does so by integrating a number of different software elements; by having specific anticipated viewers shape its content; and by encountering particular viewers. At all of those various interfaces, work is done both to create the image but also to smooth its further circulation through the frictions inherent in its network of allies, accomplices and helpers.


It was evident at an early stage in our study of the CGIs associated with the Msheireb Downtown project that such CGIs are highly mobile. This suggested that they should be conceptualised as circulating through a network of relations, and this paper has sketched that network, which is enacted as digital files circulate between architects, visualisers, Executive Consultants, Master Development Consultants, the Architectural Language Advisor and the client Msheireb Properties. The geometry that the paper has used to map that network is that of the interface: that is, the network has been understood as a series of encounters between human and non-human actors – ‘allies, accomplices and helpers’, to quote Latour again – where work is done both to create the CGI and to smooth the friction inherent in all interfaces. The paper has identified three of these interfaces as particularly important in understanding what sort of objects these CGIs are, as they circulate among diverse and dispersed allies. It has emphasised the intraface, where for example separate 3ds Max files (standardised by the EC’s guidelines) are integrated, thus allowing the EC to modify individual designs in relation to one another. It has stressed the multiple ways in which CGIs are used by different ‘allies’, and the way those allies design specific uses into how the CGIs look. And it has examined the necessity for traces of interactions with CGIs to travel as annotations through the network. At all of these interfaces, work is done. Work is done to create a digital visualisation of a view of Msheireb Downtown; and work is also done to make that work possible by managing the frictions created by the interfaces between software, hardware and various humans.

This paper has emphasised in particular those frictions in the circulation of CGIs. CGIs designed for one context may not go down well in another; the immense size of the intrafacial CGI files can cause computer systems to crash as they move from a large server or hard drive to a smaller one; annotations from encounters with CGIs do not always travel effectively. These CGIs must therefore be conceptualised as being as complex and crafted as the frictional, interfacial relations between the various entities in their network. Hence our claim that they are better understood as interfaces rather than images.

Galloway points out that it is very difficult to see friction at interfaces. Interfaces are designed to be invisible and unremarkable.24 The best touch screens, for example, are so responsive to fingers that they are no longer noticed when they are used; which means that, as Galloway notes, if the work done at an interface to make it work is effective, then, paradoxically, it appears as if no work is taking place. As a consequence, interfaces cast what he calls ‘the glow of unwork’.25 The beautiful surfaces of the CGIs that appear in urban spaces, selling new urban developments, are thus created not only by efforts to visualise seductive places, but also by that ‘glow of unwork’. As this paper’s introduction noted, other scholars have already criticised the seductive allure of CGIs as images. Here, this paper takes a different critical tack, and attempts to resist the ‘glow of unwork’ precisely by reconceptualising the smooth surface of surface of CGIs as a site of (net)work.26 Rather than take these CGIs at, literally, their face value – that is, rather than focus on their materialisations as images – this paper advocates approaching them as digital files created by, and therefore materialising, a (net)work of interfaces. This paper proposes to critical urban scholarship that that network – and specifically its frictional interfaces – should be what is seen when these CGIs are examined. The glow of unwork should not dazzle us; instead it should alert us to the work done to create it.