HackSpace: a Platform for Designing and Promoting Customised Interactions in Digital Ecosystems Song Xue The University of
Eduardo Araujo Oliveira
Melbourne Parkville 3010 VIC, Australia
The University of Melbourne Parkville 3010 VIC, Australia
[email protected]. edu.au
eduardo.oliveira@unimelb. edu.au
ABSTRACT
mkirley@unimelb. edu.au
of an artifact ecosystem[8], where artifacts influence the use of others. According to Chase [4], predictions say there will be 50 billion connected artifacts by 2020. Gartner Research predicts that the typical family home will contain as many as 500 networked artifacts by the same year. This means, for example, that in 2016, 5.5 million new things will get connected every day [6]. Due to the establishment of a wireless network infrastructure and the increasing number of interactive artifacts surrounding us, interaction designers have become quite good at designing desktop applications and are in a post-desktop era progressively getting better at designing mobile artifacts as well [23]. However, as the current digital technology have made us users of networks of devices rather than of individual ones [7] and as we share and connect to each other’s digital artifact in different ways than we did in the last decade [9], the design of multi-artifacts interactions should be facilitated to better support end-users directly. Multi-artifacts interaction designs are highly dependent on technical infrastructure and so delivering the simplest technology for supporting ubicomp requires manufacturers to deal with fundamental challenges such as: (i) connectivity, (ii) power management, (iii) security and (iv) complexity. To date, a large number of independent, heterogeneous and interacting sensors, systems and personal devices, which are provided by large and different software vendors, can be used to promote multi-artifacts interactions [16, 17]. Nevertheless, as the access to these digital content is fragmented, a need for our artifact to work together has grown [24]. The idea of using digital artifacts together is not new but still remain open in terms of designing, supporting and deploying interactions meaningful to ubicomp environments due to heterogeneity and interoperability challenges. Our work is then motivated by scenarios where various digital artifacts may be easily connected into a specific network by software engineers and managed by end-users directly. We are specifically interested in artifacts that can be connected to the Internet, such as displays, mobile devices, environmental sensors, digital watches, smart LED bulbs, smart Wi-Fi films and so on. The questions we address are: (i) how to create a public network of digital artifacts? (ii) how to let software engineers easily plug/insert different artifacts into the specific network of digital artifacts? (iii) how to present the available data from the digital artifacts of the network in a meaningful way to end-users? and, (iv) how to let end-
The increasing number of interactive digital artifacts, capable of communicating with each other, have created a situation where software applications no longer need to be limited by the physical boundaries of a single artifact. In order to take advantage of the potential of this situation, we introduce a platform that aims to enable and support people to design and/or customise ubiquitous computing interactions among available heterogeneous connected artifacts. The platform will help users understanding and designing multi-artifact systems that are more than the sum of its individual parts. We describe the initial evaluation and validation of the proposed platform, discuss the artifact ecosystem thinking and identify implications for future work.
Keywords digital artifacts, ubiquitous computing, smart society, human computer interaction
1.
Michael Kirley The University of Melbourne Parkville 3010 VIC, Australia
INTRODUCTION
Ubiquitous computing, in which computers will be embedded in our natural movements and interactions with our environments — both physical and social [13], has not yet reached a level corresponding to Weiser’s [25] vision [24]. The idea of such an environment of invisible computers seamlessly integrated emerged more than a decade ago in Weiser’s [25] article and its evolution has recently been accelerated by improved wireless telecommunications capabilities, open networks, continued increases in computing power, improved battery technology and by digital interactive artifacts that constantly surround us, such as: smartphones, TVs, smart watches, laptops and tablets [13, 24]. As we increasingly interact with multiple interactive artifacts — or physical devices — with overlapping capabilities during our daily activities [2], the use of an interactive artifact cannot be understood in isolation but artifacts must be understood as part Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from
[email protected].
TSAA ’16, December 06 2016, Hobart, TAS, Australia c 2016 ACM. ISBN 978-1-4503-4820-1/16/12. . . $15.00
DOI: http://dx.doi.org/10.1145/3014340.3014347
39
Figure 1: Platform conceptual design: managing digital ecosystems users make use of that specific network to design ubicomp interactions between the available artifacts? In this context, our contribution to this research is to investigate, design and develop a platform — HackSpace — to promote interaction for digital ecosystems (Figure 1). The proposed platform should allow end-users to design ubicomp systems by letting them manage distributed and heterogeneous artifacts available in a specific network. The proposed platform will be designed to meet two major measurable objectives: (1) definition and implementation of components for multi-artifacts data collection and data integration and (2) definition and implementation of an interface for presenting and processing the multi-artifacts gathered data. The next section presents related work and theoretical background. The proposed platform is then presented. The value of the platform is then demonstrated through an example case of designing an digital ecosystem. Finally, we discuss implications for design and research.
2.
artifacts together. This has always been important within ubiquitous computing, where computing is made to appear anytime and everywhere. Recently, Chen and colleagues [5] introduced AirLink, a novel technique for sharing files between multiple devices. By waving a hand from one device towards another, users can directly transfer files between them. GazeHorizon [26] enables passers-by to interact with public displays by gaze. The system uses a web camera for detecting users walking up to a display, provides interactive guidance to bootstrap use of gaze and lets users navigate displayed information using horizontal eye movement. Kawsar and Brush [9] have studied use patterns of connected devices in private homes. Related to this, [21] propose a new technique that uses data from wearable wrist sensors to perform object user identification in order for objects to perform personalized or contextual functions based on identity. Ranjan and Whitehouse [21] try to solve the object user identification problem by understanding who is actually using them. Previous research has also investigated how collaboration between users can be facilitated in multidevice environments [20, 10]. However, these researches do not allow end-users to connect artifacts to a specific network or either let them directly design multi-artifact interactions.
RELATED WORK
2.1
Multi-artifact interaction
Several studies have evaluated the concept of using multi40
2.2
Infrastructure to manage artifacts on the web
sonal life. They have asked people to map their artifact ecosystems and to describe the relationships between included artifacts. At the end of their study, this approach Many of the existing ICT solutions for collecting, integratclearly showed how the participants shared/distributed their ing and managing artifacts are proprietary solutions proactivities across different artifacts, and how artifacts had vided by large software and services vendors, such as IBM, different roles, influenced by the capabilities of the other arMicrosoft, Google, Samsung and Apple [15, 18]. Integrated tifacts in the ecosystem [2]. Later on, Ryan and colleagues sensor networks, mobile devices and people power these sys[22] presented a tool for people to map their ecosystem of tems, which are able to combine, aggregate, analyse and artifacts. Both studies contributed for understanding diginspect for deriving knowledge [15]. Typically, these soluital ecosystems as a network of users and digital artifacts, tions/products are designed as a unified, distributed and dynamically bounded by the users’ activities that interact real-time control platform, adding cloud computing, senswith each other through relationships [12]. According to ing, simulation, analysis services and applications. Sorensen and colleagues [24], there are four basic structures Other initiatives such as If This Then That (IFTTT) have of relationship between users and digital artifacts: 1) many investigated the concept of recipes to combine technologies. users interacting with many artifacts, 2) one user interactIFTTT is a Web service that helps connect other Web sering with many artifacts, 3) many users interacting with one vices to each other. On its own, IFTTT (http://ifttt.com) artifact, and 4) one user interacting with one artifact. does not do anything. Instead, it serves as the glue between The authors [24] have developed the 4C framework for other Web-based services using recipes, where two services describing, explaining, and informing interaction design in are combined to accomplish a task [19]. Many of IFTTT’s digital ecosystems. The 4C framework combines the differrecipes take advantage of Web-based application programent structural relationships of many users and many artifacts ming interfaces (APIs). APIs are “a set of methods to access with the differentiation between sequential or simultaneous data in otherwise closed systems. APIs give programmers interaction in a 2x2 matrix of four themes of communality, and developers the tools necessary to build software and collaboration, continuity and complementarity, a presented services with data and services from external sources” [14]. in Figure 2. APIs allow data from services like Instagram, Twitter, and As the 4C framework may support the ability to inform Tumblr to be used in clients and websites. specific understanding and design on the level of specific user Hub-of-All-Things (HAT - http://hubofallthings.com) is multi-disciplinary project involving numerous researchers across interface and interaction techniques, our work makes use of the framework to promote different interaction design opsix universities in the United Kingdom. The project is still tions by incorporating new artifacts and end-users into an in its infancy as it started only recently, in June 2013. The existing public digital network. More specifically, we proproject has as a primary objective the creation of multi-sided pose and present HackSpace, a platform that contributes to market platform to create new economic and business opporthe design of simultaneous interaction with multiple artitunities using IoT data generated by a “smart home”. An facts (the fourth theme of the 4C framework). This theme important feature of the HAT is that the data belongs to the is also known as ‘complementarity’, where interaction with individual. The HAT is performed by the home owner and one artifact adds to the interaction with another artifact, identifies context information to bring potential economic and these jointly make up a larger whole. and business models. There are two principles of complementarity in digital Parse (http://parse.com) is a mobile backend as a service ecosystem interaction design [24]: (i) extension, which de(MBaaS) that provides back-end tools for mobile developers scribes the case where one digital artifact directly adds to to help them to store data in the cloud, manage identity loganother one and, (ii) remote control, where complementarity ins, handle push notifications and run custom code in the is achieved by one digital artifact simply controlling another, provided infrastructure. As Web and mobile apps require a as is well known from traditional TV or sound system resimilar set of features on the backend, each of these services motes. has its own API that must be individually incorporated into By introducing HackSpace we suggest a complimentary an app, a process that can be time-consuming and compliway of promoting the design interaction in digital ecosyscated for app developers. Parse provides a bridge between tems. We focus explicitly on the interface and user experithe frontend of an application and various cloud-based backence while promoting interaction between users and digital ends via a unified API and SDK. artifacts instead of looking at ecosystems as people, prodXively (http://xively.com), Nimbit (http://nimbits.com), ThingSpeak (http:// thingspeak.com), WSO2 (http://wso2.com), ucts, activities, or groups. EveryAware (http:// everyaware.eu), EvryThng (http://evrythng.com) 3. HACKSPACE and OpenIoT (http://openiot.eu) are other examples of platforms that provides connectivity with constrained devices HackSpace was conceptualised to be a novel interactive such as sensors. The challenge, however, is that most of the platform to contribute to the minimisation of challenges such presented platforms are able to collect data from heterogeas: (i) integration of heterogeneous digital artifacts, (ii) data neous and/or proprietary wearable devices but they are still visualisation of digital artifacts available on the Web and, not able to let ordinary people to make use of them in order (iii) design and development of customised interactions beto design ubicomp interactions. tween the available heterogeneous digital artifacts. To overcome these challenges, the platform provides a 2.3 Digital ecosystems cloud computing interface and infrastructure to allow softAssuming that artifacts cannot be fully understood indiware engineers to easily connect different digital artifacts vidually, Jung and colleagues [8] empirically explored the — such as digital screens, digital watches, lights, speakrelationships between interactive artifacts in people’s perers, thermometers, among others — to a designed digital 41
Figure 2: The 4C framework of principles for interaction design in digital ecosystems. Source: [24] artifacts network. Importantly, the platform takes data privacy into account so that it protects sensitive data on users’ needs/demand. As an example, an educational institutional account that is making use of HackSpace platform may add digital artifacts to the platform network and make it available and public to any student/researcher as part of a living campus/hackathon experiment. On the other hand, other users may insert digital artifacts on the available network provided together with the proposed platform for personal use (in order to automatise their homes). Technical users can register their own artifacts and utilise the rule system to control them in any manner they want. They also decide if the provided input data should be private or public on the network. On top of the digital artifacts network where technical users can send data from different virtual and/or physical devices through the use of public interfaces available as part of the proposed platform, HackSpace was designed to help nontechnical users to make use of that network while designing interactions that meet their needs. The idea behind this, as shown in Figure 1, is to design a digital artifact ecosystem that can be managed by technical and non-technical people. The conceptual design of the platform is presented in Figure 3.
3.1
The overall architecture of the platform consists of four main parts, namely Web Application (user interface), Server, Input (artifacts) and Outputs (artifacts). The input and output artifacts can be connected and integrated into the server through a web application. Input artifacts provides various data such as temperature, humidity, noise level and etc. Output artifacts do not provide data but they receive commands from the server and execute them accordingly. These artifacts can be marked as public or private so that users can deploy customised interactions even in public places. The web application is the interface for end-users to integrate and interact with their devices. They can use an unique key to configure their own artifacts and control them to send collected data to the server and they also can design customised interactions to link and control multiple artifacts across the network by creating rules like “If This Then That” through a friendly user interface. Furthermore, every user can easily create “If This Then That” rules with logic gates such as “AND”, “OR” and “NOT” within just a few clicks. Once end-users have integrated and configured the artifacts and rules, the server will always listening and send the command to output artifacts when the rules are triggered.
3.1.1
Implementation: Minimum Viable Product (MVP)
Input
Both hardware or software artifacts can be built and/or integrated with the platform. Electronics and sensors Electronics, also known as electronic boards in this work, can be used as a way of connecting and sending sensors data such as temperature, passive infrared (PIR), humidity, NFC and microphones to the the platform (Figure 4). At present, there are various kinds of open-source electronic boards on
In this sub-section, we describe the implementation steps necessary to deploy an instance of the HackSpace platform in the nominated domain. Here, we adopt a standard software engineering methodology and detail the minimum viable product (or phased prototype). Figure 3 illustrate the high-level architecture. 42
Figure 3: Overall platform architecture. the market (i.e.: Raspberry Pi and Arduino). These boards often provide multiple digital and analog pins for connecting artifacts like sensors, servos or even appliances together. Importantly, as this is a digital platform that was designed to connect digital artifacts and users, the electronic boards need to have consistent Internet connection as well as the ability to send and to receive basic HTTP requests. Input artifacts are always sending collected data to the server through wireless Internet connection. They construct simple JSON objects, which using data names as keys and analog or digital values as values, and then send the JSON string to the server. Server will then store the JSON into a NoSQL database for later use. On the opposite, output artifacts, detailed later in this Section, are always listening to the server and waiting for commands from it. Once the board receives a recognised command, it triggers a change on its connected output devices. As part of our MVP development, one Arduino Yun was integrated with HackSpace. The Arduino Yun was sending data from three different physical sensors (temperature, humidity, luminosity) to the proposed platform in form of JSON (shown in Figure 4). Third-party API To improve the diversity of services, HackSpace can integrate other third-party APIs such as Twitter, Facebook, Instagram, and so on. In HackSpace, users are allowed to use
Figure 4: Sample data in NoSQL database.
integrated third-party APIs to enrich the services they can create. Third party input can be an customised event, for instance, tracking hashtags or counting how many “likes” a post has. As part of our MVP development, Instagram was integrated with the platform (Figure 5). End-users can track and manage #hashtags from the social media on HackSpace. This strategy helps HackSpace collecting data from users of proprietary solutions such as Nike Plus or Garmin Connect 43
Figure 5: screen.
HackSpace:
count to use the platform. Apart from that, the system forces verification on email address in order to prevent malicious uses. (ii) Artifact Management: Every registered user can integrate their owned third-party artifacts such as Arduino [1], Raspberry Pi [3] and Intel Edison [11] into HackSpace. The actual integration includes two parts. One is the integration of artifacts (electronic hardware) and the other is integration on HackSpace. Firstly, a master key and an application ID needs to be configured in the program of the input artifacts so that their requests are authenticated and directed to the right database. Secondly, users need to add the artifacts through HackSpace user interface by adding unique names for artifacts on the server. After this simple integrating process, the artifacts are ready to communicate with the system by “Get” or “Post” standard HTTP requests with the credentials mentioned above. This way, heterogeneous artifacts can interacts with each other easily as long as they have the Internet connection and support HTTP requests. Every artifact can be marked as public or private based on its owner’s choice. If an artifact is marked as public, then it means all valid users of HackSpace can access and manage the data it collects. On the contrary, if an artifact is marked as private, it can only be accessed by its owner with a valid HackSpace account. (iii) Data Management: Every user is given the ability to manage data in HackSpace even if they do not own any integrated artifacts. Details that users can get includes all the data that collected from the artifact as well as some integrated service information like weather forecasts (described in the following section). With the access of rich sensor data, users can further apply rules onto output artifacts to manage the physical environment. Rules in this specific context are defined as an expression of multiple equations or inequations with logic gates. Whereas the complicated logic behind rules will be shielded entirely from users, what they can perceive is just a simple sentence with two parts namely “IF” and “THEN”. For instance, a typical rule is like “If A or something else, then B ”. In the “If” part, users can define as many conditions with logic gates to construct a many-to-many relationship. (iv) Rule management: This is the core part of this platform. It takes the input from users and automatically controls the output to achieve ubiquitous computing. This component consists of two components: a scheduler and the rules manager. This component was developed here in a way that each user can book an exclusive hour in the platform to control the artifacts they need. In that hour, only the rules that were created by the booked user will be executed. This way, the user will be responsible for rule conflicts themselves. If the user still fails to resolve the conflicts, then the platform will only execute the latest non-conflicted rules. As a result of this, users’ booked time needs replication check before they are stored in the database. The scheduler is used to manage the execution time for each rule in the database. It will calculate the time difference between the booked time and the current time when storing rules and then it keeps a timer as a background job. When the time is up, the scheduler will call the rule manager to execute the rules for an hour. Eventually, after the job is done, the scheduler will be terminated.
‘designing interactions’
watches, for example, which shares contents with #hashtags in Social Networks. HackSpace can collect data from users in many different environments (a form of active behavior).
3.1.2
Output
Output artifacts integration is a non-trivial task because most artifacts are proprietary. In this project, as part of our MVP, small electrical components like LED lights and buzzers were used as output to replace big appliances like coffee machines, door locks or TVs. These are all basic components so that they can be integrated with electronic boards easily. Besides, another open source webpage game is used as output to attract more users. This game is running on a simple web server and it runs on a local PC, which has a monitor connected. Like described in the section above, output artifacts are continuously waiting for commands from the server.Whereas if the output artifacts support push notification, then they can receive a JSON message indicates the command; else simple HTTP requests are used as commands. Third-party API Third party APIs can serve as output as well but using a different type HTTP request. When APIs are used as an input source, we mainly used the “GET” HTTP request to query the third-party servers for information, while APIs are used as output source, “POST” HTTP requests are used to post some information on the third-party server.
3.1.3
Web Application
The web application layer is the interface for technical and non-technical users to interact with the entire platform. The interface can be explained and detailed in terms of four main features: (i) User Authentication: Users are required to create an ac-
4. 44
ANALYSIS
In this section, we report analysis obtained from our MVP implementation of HackSpace — a proof-of-concept. As part of the evaluation of our implementation, a series of small tests, performed by two researchers involved in this project, were carried out to evaluate the ability of the proposed platform to collect, integrate and manage artifacts data. Here, we limit the analysis to a scenario example focused on the management of LED lights and buzzer (outputs) based on collected data from temperature, humidity, luminosity and Instagram (inputs), through the development of rules on the platform. The specific contextual elements considers included:
still poor because the lack of cross-platform time-based job scheduler as well as rudimentary booking system.
5.
CONCLUSION
The work in understanding digital artifact ecosystems becomes important as they evolve and the relationships among artifacts become more complex. What we have done is to start an articulation of artifact ecosystems on a level in between the interaction with multiple heterogeneous artifacts and the understanding of the ecosystems in their entirety. The design and implementation of HackSpace helped us understanding the challenges and limitations while trying to design interactions that involves a large and different number of artifacts. In future work, we plan to scale-up our initial investigation to get a deeper understanding of the identified concepts with the ultimate goal of creating design guidelines for multiartifact systems and to test it with real users in a larger experiment.
• New posts in Instagram using predefined hashtags • Changes in weather conditions (temperature, humidity, luminosity) The test data was collected over a two-week period. Each weekday, the data from the temperature, humidity and luminosity sensors was collected spanning a twelve-hour period. The environmental data was collected every 30 minutes from 10:00h to 22:00h and was added to the HackSpace database. The Instagram specially defined #hashtag was monitored over 24 hours per day (automatically) during the tests period. Despite the fact that we could successfully connect, visualise, write and execute rules for the connected digital artifacts and, test the entire flow designed for this particular testing scenario on the platform, we have encountered three major challenges namely artifacts heterogeneity, various data format and scalability. Artifacts heterogeneity: It is quite challenging to integrate output artifacts because every output artifacts needs to react to commands that server sends. Either it runs an on-board server to handle RESTful API requests or it creates a separate listening thread to track incoming commands. Both methods are hard to implement and they are not generic for every output artifact. For those close-sourced artifacts, it is also hard to integrate them because their APIs are limited and we do not have full control of the communication protocol the manufacturer are using. Various data format: The heterogeneous artifacts certainly will bring various different data format. Although storing them in NoSQL is not difficult, the visualisation and data comparison while checking the rules are not trivial work. It is always hard to predict what kinds of data users will upload, so there is no guarantees for 100% precise visualisation. Meanwhile, various format will also bring trouble into the rule generator. Similar to the visualisation issue, it is hard to ensure that the rule generator will not fail to any kinds of input. Furthermore, the rule generator is relatively vulnerable because if it fails, the entire system fails to perform the function it should provide. Hence, it is hard to keep the system running without failure because the unpredictable data format. Scalability: As the number of users increases, conflicts between different user bookings are inevitable in public spaces. Assigning priorities seems to be a neat solution for this situation but implementation is a non-trivial work. Besides, the increase of users will also bring heavy burden on the scheduler because it will run many concurrent background jobs. This might cause some severe problems that bring down the server. Overall, the scalability of the rule management is
6.
REFERENCES
[1] Y. A. Badamasi. The working principle of an arduino. In Electronics, Computer and Computation (ICECCO), 2014 11th International Conference on, pages 1–4, Sept 2014. [2] S. Bødker and C. N. Klokmose. Dynamics in artifact ecologies. In Proceedings of the 7th Nordic Conference on Human-Computer Interaction: Making Sense Through Design, pages 448–457. ACM, 2012. [3] J. R. Byrne, L. Fisher, and B. Tangney. Computer science teacher reactions towards raspberry pi continuing professional development (cpd) workshops using the bridge21 model. In Computer Science Education (ICCSE), 2015 10th International Conference on, pages 267–272, July 2015. [4] J. Chase. The evolution of the internet of things. Texas Instruments, 2013. [5] K.-Y. Chen, D. Ashbrook, M. Goel, S.-H. Lee, and S. Patel. Airlink: sharing files between multiple devices using in-air gestures. In Proceedings of the 2014 ACM International Joint Conference on Pervasive and Ubiquitous Computing, pages 565–569. ACM, 2014. [6] I. Gartner. Gartner says 6.4 billion connected ”things” will be in use in 2016, up 30 percent from 2015. http://www.gartner.com/newsroom/id/3165317, 2015. [7] E. Hutchins. Cognition in the Wild. MIT press, 1995. [8] H. Jung, E. Stolterman, W. Ryan, T. Thompson, and M. Siegel. Toward a framework for ecologies of artifacts: how are digital artifacts interconnected within a personal life? In Proceedings of the 5th Nordic conference on Human-computer interaction: building bridges, pages 201–210. ACM, 2008. [9] F. Kawsar and A. Brush. Home computing unplugged: why, where and when people use different connected devices at home. In Proceedings of the 2013 ACM international joint conference on Pervasive and ubiquitous computing, pages 627–636. ACM, 2013. [10] S. Kreitmayer, Y. Rogers, R. Laney, and S. Peake. Unipad: orchestrating collaborative activities through shared tablets and an integrated wall display. In 45
[11]
[12]
[13] [14] [15]
[16]
[17]
[18]
[19]
[20]
[21]
[22]
[23]
[24]
Proceedings of the 2013 ACM international joint conference on Pervasive and ubiquitous computing, pages 801–810. ACM, 2013. F. Lan, G. Zhai, and W. Lin. Lightweight smart glass system with audio aid for visually impaired people. In TENCON 2015 - 2015 IEEE Region 10 Conference, pages 1–4, Nov 2015. T. Legovi´c. Theoretical studies of ecosystems: The network perspective: M. higashi and tp burns (editors). cambridge university press, new york, 1991, 364 pp. us $74.00. isbn 521-36138-9., 1992. K. Lyytinen and Y. Yoo. Ubiquitous computing. Communications of the ACM, 45(12):63–96, 2002. J. P. Michel. Web service APIs and libraries. American Library Association, 2013. E. A. Oliveira, M. Kirley, J. C. Fonseca, and K. Gama. Device nimbus: an intelligent middleware for smarter services for health and fitness. International Journal of Distributed Sensor Networks, 2015:8, 2015. E. A. Oliveira, M. Kirley, T. Kvan, J. Karakiewicz, and C. Vaz. Distributed and heterogeneous data analysis for smart urban planning. In International Conference on Computer-Aided Architectural Design Futures, pages 37–54. Springer, 2015. E. A. Oliveira, M. Kirley, E. Vanz, and K. Gama. Hspy: an intelligent framework for context and predictive analysis for smarter health devices. In 2014 International Conference on Information and Communication Technology Convergence (ICTC), pages 53–58. IEEE, 2014. E. A. Oliveira, F. Koch, M. Kirley, and C. V. G. dos Passos Barros. Towards a middleware for context-aware health monitoring. In Advances in Social Computing and Multiagent Systems, pages 19–30. Springer, 2015. S. Ovadia. Automate the internet with “if this then that”(ifttt). Behavioral & Social Sciences Librarian, 33(4):208–211, 2014. T. Pering, K. Lyons, R. Want, M. Murphy-Hoye, M. Baloga, P. Noll, J. Branc, and N. De Benoist. What do you bring to the table?: Investigations of a collaborative workspace. In Proceedings of the 12th ACM international conference on Ubiquitous computing, pages 183–192. ACM, 2010. J. Ranjan and K. Whitehouse. Object hallmarks: Identifying object users using wearable wrist sensors. In Proceedings of the 2015 ACM International Joint Conference on Pervasive and Ubiquitous Computing, pages 51–61. ACM, 2015. W. Ryan, E. Stolterman, H. Jung, M. Siegel, T. Thompson, and W. R. Hazlewood. Device ecology mapper: a tool for studying users’ ecosystems of interactive artifacts. In CHI’09 Extended Abstracts on Human Factors in Computing Systems, pages 4327–4332. ACM, 2009. H. Sørensen and J. Kjeldskov. Concepts of multi-artefact systems in artiface ecologies. In 7th International Conference on Advances in Computer-Human Interaction, pages 141–146, 2014. H. Sørensen, D. Raptis, J. Kjeldskov, and M. B. Skov. The 4c framework: principles of interaction in digital ecosystems. In Proceedings of the 2014 ACM
International Joint Conference on Pervasive and Ubiquitous Computing, pages 87–97. ACM, 2014. [25] M. Weiser. The computer for the 21st century. Scientific american, 265(3):94–104, 1991. [26] Y. Zhang, J. M¨ uller, M. K. Chong, A. Bulling, and H. Gellersen. Gazehorizon: enabling passers-by to interact with public displays by gaze. In Proceedings of the 2014 ACM International Joint Conference on Pervasive and Ubiquitous Computing, pages 559–563. ACM, 2014.
46
