Why the Internet of Things needs Object Orientated Ontology

: The Internet of Things (IoT) is a network of connected devices with inputs and outputs operating in, and on, the physical world. The network is simultaneously fed by, and feeds into, data streams flowing across digital-physical boundaries, connecting sensors, servers, actuators, devices, and people. ‘ Things ’ of all types, lightbulbs, doorbells, kettles and cars, discretely-but-visibly do their jobs. Meanwhile in the unseen digital domain, where data swirls imperceptible to humans, the atmosphere is thick with the rapidly-moving data packets and content that constitute inter-machine chatter. Contrasting the visible calm in the physical world with obscured bedlam in the digital otherworld sets the scene for the argument we present in this paper. Applying Object Orientated Ontology, IoT designers may reimagine data, devices, and users, as equally significant actants in a flat ontology. In this paper, we exemplify our arguments by creating a Design Fiction around a reimagined ‘ smart kettle ’ .


Introduction
In his manifesto for networked objects, Bleeker (2006) prepared us for objects developing a form of agency.Over a decade later and the growth of the Internet of Things (IoT) continues to invoke a variety of unique design challenges across a wide range of different application domains.As the IoT pervades more widely we are becoming increasingly entangled within the heterogeneous network of interconnected objects or things that are readable, recognizable, locatable, addressable, and/or controllable via the Internet (Coulton 2015).While Human-Centred Design (HCD) predates the Internet it has become the de facto modus operandi of many IoT designers.HCD has been positively applied for personal devices such as the mobile phone and helped to produce a myriad of products that are efficient and rewarding to use.A side effect of the methods that make up this design paradigm is to obscure underlying complexities from users.In doing so virtually all traces of the often intricate and entangled mechanisms that underpin function are made to disappear.In most circumstances the obfuscation of inner workings is welcome, and even necessary, in order to design 2 products which are functional and desirable.Arthur C. Clarke's widely cited '3 rd law' -"any sufficiently advanced technology is indistinguishable from magic" -echoes the same sentiment.Disguising the mechanisms by which devices work as a product of the quest to make technologies appear magical, has become increasingly problematic in the era of the IoT.Proactively shrouding the details of how connected things perform in concert with the other nodes on the network, even if the obfuscation contributes towards some notion of HCD-inspired usability, disempowers the user, and we argue, unintentionally reduces the acceptability of IoT devices.These factors, combined with IoT's increasing heterogeneity, ubiquity and pervasiveness, have arguably contributed to the growing concerns related to security, privacy and trust in the IoT.

Shifting Perspectives: Appliances, Apps, and Objects
In recent years HCD has come to dominate design discourses in respect of the creation of new products and services, particularly computing technologies.When Don Norman, often considered the architect of HCD, published an article entitled "Human Centered Design Considered Harmful", it caused consternation to such an extent Norman felt compelled to compose a clarification.The original article tried to move HCD practice closer toward "products and services that truly fit human needs".Pointing out how that had not always been the case, Norman argues that HCD had been "accepted by interface and application designers automatically, without thought, let alone criticism".
Treating ideas dogmatically like this can be dangerous.In this instance Norman's response to the dogma was to import some ideas from activity theory.He succinctly uses error messages to hint at both the problem he had observed and his proposed solution "… there should not be any error messages.All messages should contain explanations and offer alternate ways of proceeding from the message itself" (Norman 2005).In other words, any element that has been designed should positively contribute to the activity that is being performed.
The thrust of Norman's critique was based on his observation that while HCD led to improvements in measurable usability and understandability of certain tasks within software systems, this had not led to the systems necessarily becoming less 'complicated'.This is because some systems are inevitably complex and often designers adopting HCD methods manage this complexity through simplification of the information provided by the user.Ironically, in advocating for 'Information Appliances' to combat the increasing complexity of human-computer interactions, Norman promoted 'simplicity' as a desirable in the first place (1998).Discussing Information Appliances, Norman argued that creating hardware and software that can perform lots of different functions can confuse the user.Instead he proposed focusing on simpler hardware and software, devices that perform fewer functions, but do those things aptly and appropriately.He put forward three HCD axioms for designing Information Appliances that achieve these aims (Norman, 1998): • Simplicity The complexity of the appliance is that of the task, not the tool.The technology is invisible.• Versatility Appliances are designed to allow and encourage novel, creative, interaction.
• Pleasurability Products should be pleasurable, fun, enjoyable.A joy to use and a joy to own.
Today, Information Appliances have become ubiquitous in the form of smartphone software apps.These apps focus on very specific tasks, an approach that has superseded the previous paradigm of files and folders inherited from desktop platforms.The continuing adoption of IoT has made Norman's axioms relevant to a vast array of newly network-connected devices, objects and services.
The drive for simplicity means that both apps and devices in the emerging IoT space often mask their background data gathering and sharing activities as this is not necessary to complete the task being undertaken by the human using them.But as Norman tells us, the focus of the simplicity axiom should be on making the complex more understandable, not 'masking complexity ' (2005).We suggest that the tension between these two interpretations of the simplicity axiom is an unavoidable property of HCD.This tension comes about because focusing on human actants alone does not acknowledge a 'thing perspective'.Of the multiplicity of things around us each may have a different viewpoint, furthermore, ontologically speaking, each thing may have a different viewpoint on what it is to have a viewpoint!Relating this 'thing perspective' to activities, tasks, and HCD, any given thing may have additional tasks to complete beyond those that the human is concerned with.In other words, while the 'tool' may be facilitating the task of the human, it is also performing its own task, which may be quite different to the task that the human is concerned with.This situation, although not new, has been made more apparent because things are becoming networked and increasingly are designed around their ability to communicate and interact with one another.
If we consider one example IoT device, the smart thermostat, as the human user sees it, the thermostat's role is to allow more convenient control of their heating system.Meanwhile for the thermostat itself the primary consideration is to have the appearance of providing simple convenience to the user while gathering and uploading information on these activities to its manufacturer.Although this task might be revealed in the operator manual or within a privacy agreement, the prevalence of the thermostat's primary consideration in its day to day operation is obscured from the human using the device.Hence the IoT is not only a network of devices but also of errands, enterprise, data, value, and contrasting ontologies of what it means 'to be'.While this is an interesting intellectual discussion, these intricacies of the IoT have a real impact on the world.For instance, the comparatively high price of connected devices when compared to their unconnected counterparts may provide some explanation for slow adoption of domestic IoT devices in spite of their manufacturers' attempts to boost sales (Titcomb 2016).However, consumers' concerns about privacy, opaque data collection, and what lies behind manufacturers motivations for promoting IoT casts a shadow over the perceived acceptability of IoT devices, and hinders widespread adoption (a future adoption that has been widely lauded as heralding economic and social benefits).
With the aim of promoting the design of IoT objects whose underlying activities are more understandable and transparent within the diversity of the network's activities, we propose the consideration of networks and IoT devices in terms of 'constellations'.Describing IoT as a constellation we suggest that the appearance, utility, significance, and 'meaning' of network-nodes varies significantly depending on the observer's perspective (Benjamin 1999).However, considering constellations does not simply mean considering multiple human perspectives, nor ascribing an anthropic view to objects, but rather proposing that each object is just a single actant among a larger ecology of 'stuff'.For the users of IoT devices the view of their constellation is obscured by HCD: they cannot even see the other objects.The point at issue in this paper is the question of how designers working with IoT products and services can appropriately 'design for constellations'.We turn to a branch of contemporary philosophy known as 'Object Orientated Ontology' (OOO) to shed light on this issue.We invoke OOO not to understand existing design practice but to provide a platform for performing future design practice.
OOO is a strand of 'speculative realism' which takes its name from symposium held in 2007 which brought together the four principle thinkers in this area, Quentin Meillassoux, Ray Brassier, Ian Hamilton Grant, and Graham Harman.What unites these four, who disagree on many other related ideas, is a common rejection of 'correlationism'.Correlationism takes the view that things are only 4 real insofar as they are sensible to a human subject, hence by rejecting correlationism agency can, theoretically, be assigned to non-human actants.Harman, and his discussion about OOO, provides us with ideas that can be used to reframe design in an IoT context.Harman starts by challenging Heidegger's consideration of tools, a perspective which makes defining 'things', in and of themselves, almost impossible as Heidegger defines them through their purpose to the human (either as 'present-at-hand' or 'ready-to-hand').Harman's counterpoint to this view suggests that objects (things) are not merely defined through human use but through any use, including object to object situations.
As ontology is the study of the nature of being then, then an Object Orientated Ontology puts objects at the centre of being.We humans are but one of the many things, and we have no special status.In OOO's terms, all conceivable entities (including humans) are 'objects', 'things' or 'stuff'.All entities are deserving of equal consideration.Hence OOO is termed a 'flat ontology', a model for being where no object is more significant than any other object.OOO is not hierarchical.OOO has parallels to DiSalvo and Lukens' non-anthropocentric design ( 2011), but as their design aims are to mitigate factors that could limit the continuance of human life, that approach still effectively preserves the human as the central actor.OOO and speculative realism, however, is open to obvious critique: it is arguably impossible that we, as humans, can ever free ourselves of all anthropocentric bias.
"What speculative realism thinks of as its novel philosophical insights-that humans are no exception to things, that there should be no distinction between human and nonhuman 'actants,' and that the subject-object hierarchy in philosophy should be abolished-become the philosophical cheerleaders for a contemporary culture that denounces the idea that human beings can-even should-actively reshape the world in their own interests."(Charlesworth, 2012).
Put differently, the critique is that OOO provides a convenient way of absolving oneself of responsibility and avoiding action.The ongoing debates around the virtues of speculative realism, along with sceptical counter arguments such as that above, have some considerable substance.However, it is not the purpose of this research to provide a justification, or indeed endorsement, of OOO.Rather our task is to consider how the OOO thesis might be used as a way of directing design practice for the IoT in light of the challenges facing HCD-imbued IoT constellations.To do this we draw inspiration from the work of video game designer Ian Bogost who proposes his own formulation of OOO, called Alien Phenomenology, which allows him to practically engage with ontology using video game design.This approach transcends the metaphysical nature of ontology and allows direct experimentation with ontology.This is achieved through a 'material' engagement with the philosophy, an engagement made possible through the design and crafting of virtual worlds which, for Bogost, manifest as video games.
"If a physician is someone who practices medicine, perhaps a metaphysician ought be someone who practices ontology.Just as one would likely not trust a doctor who had only read and written journal articles about medicine to explain the particular curiosities of one's body, so one ought not trust a metaphysician who had only read and written books about the nature of the universe."(Bogost, 2012, p96) This framing simplifies using OOO in design practice as it provides us with an answer to the question 'if ontology studies the nature of being how do you practice ontology?'And by extension, an answer to the question 'how could one perform ontology without being a God?' For Bogost, the answer is to become demurgic through the practice of designing a video game.Video games work well for this task because they are models of alternate realities.Their creators 'play God' by defining the rules and schematic for 'being' in that world.In this way artificially constructed video game worlds are ontological sandboxes.Nominally abstracting Bogost's logic slightly, we suggest that the speculative design method, Design Fiction, is a similarly appropriate tool for applying, performing, and rehearsing OOO inspired design strategies.As with video games, Design Fiction practitioners are world builders (Coulton et al. 2017).Rather than building a virtual world in software, Design Fictions build their world using assemblages of artefacts.These assemblages create a space for the design concept, and the world that the design exists within, to be prototyped.It is using Design Fiction in this way that we provide one example of how OOO design could be applied in an IoT context.

Polly, the Smart Kettle
Our decision to build a Design Fiction world around a kettle (as opposed to some other object) was driven by two factors.First we were motivated to build upon the trope of mundane domestic devices as exemplars of IoT use cases, e.g. the much talked about smart refrigerator (Arthur 2014).Second there are several existing smart kettles available in the consumer market which exhibit some of the concerns discussed earlier relating to how HCD approaches can become problematic in IoT contexts.For example, in the FAQ for the iKettle 2.0 the manufacturers address the question 'How do I know how much water is in the kettle?' with the answer 'You can check how much water is the kettle via the app'.While this is true, on occasions when the user may want to simply boil the kettle without the app, this 'feature' becomes a hindrance.From our own research with the same kettle it appears to never communicate with the outside internet as the app only works when connected to the home network, however this information is not clearly communicated by the product's user interface or its documentation.Without data analysis tools, the product nor its documentation articulate to the user what role the kettle plays in its IoT constellation.The Design Fiction presented here is centered around a smart IoT kettle, the product is named Polly.In the following paragraphs, we describe the process of designing Polly and building the fictional world that the kettle exists within.This reflective account of our Design Fiction world building process serves to articulate how OOO may augment HCD for the design of IoT devices and suggests how Design Fiction can be used to practice OOO.
In the development of this Design Fiction we produced several artefacts to help us conceive of the world where Polly makes sense.These include a press release describing the product and its history, product packaging, and user interfaces.Between these artefacts the texture and detail of Polly's world emerge, in which the kettle becomes 'situated'.The press release we created describes many of the kettle's features, these include intelligent notifications, synchronization with social media feeds, automatic updates, voice activation, usage tracking, location-based boiling, 'JustRight' smart fill level.Beyond revealing features, the press release also tells us more about the world that Polly exists within, for example the product was originally crowdfunded before subsequently being bought out by Amazon's IoT division (figure 1).Finally, the press release also reveals that Polly is accredited by a government IoT regulator named "OfIoT" and utilizes an alternative to current standards for transferring data over the internet named "Minimum Necessary Datagram Protocol" (figures 1 and 4).Early in the design process we had provisionally chosen to go ahead with the name Boilr (taking cultural cues from the many digital services which drop the 'e' from their name, e.g.Flickr, Blendr, Tumblr).Although we went so far as to develop a series of branding ideas for Boilr, eventually we back-tracked and renamed our kettle Polly.The move was driven by a realization that it is increasingly common for smart IoT products to be sold with a designed-in anthropomorphic quality.
Examples include Amazon's Alexa, Microsoft's Cortana, and Apple's Siri.An early version of what eventually became the 'Polly' logo can be seen on the Boilr logo comparison sheet (figure 2).
'Polly' was chosen specifically to make reference to the English language nursery rhyme Polly Put The Kettle On.Familiar to many and perhaps benefitting from 'cognitive ease', 'Put the kettle on' is leveraged as a 'tag line' for the product (figures 3 and 4).Beyond the wider contextual considerations for Polly's fictional world, we also had to consider the physical design of the kettle.We elected to use a commercially available 'stove top' kettle as Polly's foundation.Using such a minimalist design gave us an entirely blank canvas upon which our speculative designs could be sketched with minimal interference based on aesthetic prejudice.The plain appearance of our base kettle allowed us to easily superimpose the fictional user interface elements (figures 5 and 6).With the texture and detail of the world that Polly is situated within established we designed two features that specifically exemplify and articulate our thesis respect to IoT design, OOO and HCD.To reiterate, an for concern is that HCD principles in their pursuit of interface simplicity and usability, may simultaneously cloak a device's role and position with the eclectic constellations of the IoT.These two features are easily summarized.The first feature is a timeline inspired by the ubiquitous timelines we see on social networks and live news websites.Polly's timeline reports all data transactions that the kettle is involved in (i.e.every time the kettle communicates across the network, that communication appears as an entry in the timeline).The second feature is related to the first.Using a simple graphical display, Polly shows the user the relative volume of data that it sends to the Internet, from the Internet, and that is transferred within the kettle's local network (i.e. a user's home).Any given IoT constellation has differing purposes depending on what kind of 'thing' you are.A substantive value-add, in the eyes of product manufacturers and cloud platform providers, is the ability to collect large quantities of data via the physical manifestation of their IoT products.This is exemplified by products such as the Nest thermostat and insurance company owned driving trackers in automobiles.In both cases the corporations produce the devices to collect data, which in turn allows them to provide services tailored to individual customers.Our assumption when building Polly's fictional world was that in the future the pervasiveness and ubiquity of data collecting devices will grow hand in hand with IoT adoption (Sterling 2014).Presumably IoT kettles will collect some sort of data too.While data collection does not impair Nest's ability to be a thermostat nor would reduce Polly's ability to boil water, that does not mean that sharing information in this way does not impact upon the acceptability of these products.The visibility of the data shared by these devices today is at best opaque and at worst absent.In this way shielding the user from the data transactions, a possible effect of HCD methods, predisposes users towards a lack of trust in the device and its associated cloud services.We may liken this to an autonomous car that would chose an optimized route to its destination.Although optimized travel is desirable, if the car was unable to reveal precisely what that route was, it would not be surprising to feel somewhat mistrustful of it.Figure 5 shows a Polly timeline with several events taking place over a period of several hours on 15 th April 2017.Each event is coded one or more of 4 icons.A 'home' icon is used if the data transaction is between the kettle and another device on the local network.Two cloud icons, one with an up arrow and one with a down arrow, indicate if data is going to (up) or coming from (down) the Internet.Finally, a 'gear' icon is used to denote whether this specific data transaction is having a direct effect on the operations or configuration of the kettle or other networked devices.From the timeline, we can tell that Polly was dormant for over 4 hours since the 'daily cloud pingback', which uploads usage data to the cloud and downloads configuration, security, and update data from the cloud.Because this activity involves upload, download and configuration it includes those three icons.Next we can tell that the kettle is picked up from its base, refilled to 58% full, at this point it the software inside Polly anticipates (based on being refilled and previous user behavior patterns), that it will be boiled soon.We can see that removing the kettle from the base and refilling it result in immediate sharing of data to the cloud.The anticipation event however does not share data to the cloud, but does share data with the home's smart meter and other appliances to inform them of an impending power-consumption spike.Next, we see an incoming boil request, initiated from within the home, hence no upload or download, this is swiftly followed by a 'PPTKO' event ('Polly Put The Kettle On'), which is logged to the cloud.By interacting with the timeline details could be revealed showing precisely what data was sent or received, where it was sent or received from, and what purpose it plays in the constellation.Polly uploads so much data is not, in fact, important to the paper and is a piece of information that will remain in the interior of the Design Fiction world.The world we have built for Polly to exist in, within which we have prototyped two features inspired by concerns to do with HCD and opportunities presented by OOO, serves as a first step to explore how thinking in terms of a flat ontology can be beneficial for the design of the IoT.

Conclusions and Future Research
In this paper we frame IoT in terms of constellations, highlight some effects of HCD methods which are problematic for IoT constellations, introduce OOO as a response to these issues, and finally provide an example Design Fiction to demonstrate how these ideas may become concrete design practice.Our contribution is not an end, but an invitation for further exploration.Our hope with this paper is to help lay foundations for new design discourses that are fit for the design challenges we face in the 21 st century.As we have shown in this paper, there is a strong argument for why designers working to create Internet of Things devices need to look beyond the traditions of Human Centred Design.Object Orientated Ontology, as we have shown rhetorically and through practice, is a powerful tool for responding to these challenges, and ultimately, designing beyond them.

Figure 1 .
Figure 1.Extracts from the press release about the Polly smart kettle.The press release primarily provides texture and detail to the world that Polly exists within so as to provide a tangible space to prototype the OOO-inspired design concepts.

Figure 2 .
Figure 2. Early logo designs for 'Boilr' before the product was renamed 'Polly'.The logo eventually used for Polly is visible to the bottom right of this image.

Figure 3 .
Figure 3. App promo images for smartphone and smartwatch platforms, both featuring the tag line 'Put the kettle on'.

Figure 4 .
Figure 4. Shipping box featuring the product's tagline, as well as a number of logos from Polly's 'world'.

Figure 5 .
Figure 5. Timeline feature showing a verbatim account of all networked communication Polly takes place in.

Figure 6 .
Figure 6.Timeline feature showing a verbatim account of all networked communication Polly takes place in.

Figure 6
Figure 6 depicts a volumetric representation of the data uploaded from Polly, downloaded to Polly, and moving to or from Polly around the local network.This display differs from the timeline in that we cannot tell from it why data is moving around.However, what we can tell is the relative amount of data this smart kettle consumes and gives off, as well as the relative volume of those external transactions in relation to any 'chatter' with other devices on the local network.Both displays are intended to be used in conjunction with each other such that Polly is quite transparent about to what it communicates, for what purpose, and what -in terms of volume -the significance of that communication is.We might infer from these two displays that Polly 'gets' much less from the cloud than it 'gives'.Our Design Fiction does not explicitly communicate why this is the case.It could be that Polly's voice recognition software relies on the cloud, hence large audio files are uploaded frequently.It could be that because Polly appears to log almost every event it detects with its cloud provider (figure5) and thus over time the volume of data builds up.Potentially Polly could have been compromised, and the large upload volume is because Polly is part of a botnet.The 'truth' of why Polly uploads so much data is not, in fact, important to the paper and is a piece of information that will remain in the interior of the Design Fiction world.The world we have built for Polly to exist in, within which we have prototyped two features inspired by concerns to do with HCD and opportunities presented by OOO, serves as a first step to explore how thinking in terms of a flat ontology can be beneficial for the design of the IoT.