MENU

Blog

A selection of content I recommend, bunch of articles I wrote or just fun stuff.
In other words, this is my small contribution to the web.

qwq.001

IFTTT: Cultural practices, algorithmic literacy and power relations in an oversimplified end-user programming interface

If this then that. These four words constitute a very simple sentence, conceptually powerful yet obviously lacunar. Reading it naturally invites the reader, or even forces him, to think about causality, to build intellectual connections between two events or to attempt at imagining potential relationships between things. In fact, causality is basic to human thought. Unsurprisingly then, it is also basic to computer software programming and is very much embedded in the concept of function, as Derek Robinson states: “A function is an abstract replica of causality. It’s what it is to be a simple, deterministic machine: the same input must always map to the same output. This intuition is at the heart of logic” (2006, p.105) Launched in early 2011, the web-based service IFTTT – a contraction of the above sentence – is built essentially around this elementary type of statement. By allowing users to create so called recipes – customised connections between popular web-services, applications, and connected devices – IFTTT takes advantage of the conceptual compatibility of a multitude of existing technologies and lets the users playfully arrange them according to their specific needs, almost as effortlessly as a child would clip Lego® blocks together. Behind the extreme simplicity of its user interface lies an immensely more complicated web of technologies (Kelly, 2010), servers and algorithms. As an example among thousands of possibilities, IFTTT allows in less than ten mouse clicks to setup a complex process which automatically adjusts the lighting of the user’s apartment to the weather of the day. Therefore, as easy as it may feel, creating such recipe is in fact a highly technological practice, indirectly involving thousands of lines of code. For software studies, IFTTT is undoubtedly an interesting service since it can be approached from many angles: its extensive technical affordances, its impact on cultural practices, its particular business model, its playfulness, its metaphoric communication or even its communitarian dimension. Indeed, dozens of research questions can be proposed in regards to this tool. It especially promises to be a great object of analysis in the context of the ongoing debates about algorithmic literacy and algorithmic rhetoric. Hence, the primary focus of this paper will be to answer the following question: to what extent does the simplicity of the interface and features of IFTTT grant its users a form of algorithmic literacy and change the way they perceive their daily activities? Insights and results will be obtained by performing a material object analysis of the platform’s key features and a close reading of its interface’s text s as well as a selection of relevant recipes and paratexts. On the other hand, I will investigate how the operative logic of the platform and the concept of end-user programming blur the boundaries between disparate services and contribute in developing the technological eco-system many authors, and notably Kevin Kelly, have described. Drawing on these first sections, I will discuss how large internet and media companies take advantage of IFTTT, and thus, how the platform may reinforce existing power structure more than it empowers its individual users.

On IFTTT’s homepage, the mission of the web-service is baldly exposed through a catchy slogan: “Put the internet to work for you” (www.ifttt.com 2015). This appealing statement conveys a strong sense of user empowerment and implies a shift in power relations. The minimalistic design of the page and its unequivocal “Sign up” call to action instantly set the stage of a straight forward and goal oriented platform. At this early point, I suggest jumping into the “About” section of the website, which is accessible through the footer navigation, to get a clearer description of the service. Once again, the information is presented in a concise, simple and user-friendly way. The page introduces the concept of recipes in the following terms: “Recipes are simple connections between products and apps. […] Do Recipes run with just a tap and enable you to create your own personalized Button, Camera, and Notepad. […] IF Recipes run automatically in the background. Create powerful connections with one simple statement — if this then that.” (www.ifttt.com 2015) In this research, I will mostly focus on IF Recipes, which were introduced first and constitute the essence of the service. Do Recipes were added in February 2015 and although they’ve been quickly adopted since then, they seem conceptually less interesting to analyse in the context of this paper, since they require systematic user inputs. In software literature, the recipe is an often used metaphor to define an algorithm: “a precise recipe that specifies the exact sequence of steps required to solve a problem” (MacCormick, 2011, p.3). Scrolling down further, an example of recipe is displayed: “If I post a picture on Instagram, save the photo to Dropbox” (www.ifttt.com 2015). The recipe is visually represented by two contiguous rectangles distinguishable by their colour, each containing the icon of the application or service used by the recipe, as swell as the word “if” – respectively “then” – preceding the icon. Interestingly, it is assumed that the visitor of the page uses or at least knows the applications constituting the recipe, since no further explanation is given about them. In terms of wording, the use of the first person in the recipe’s description creates a greater sense of appropriation. It automatically converts the visitor into a virtual user, and lets him imagine as he reads, the outcome of the recipe in his context. After completing the short registration process, a list of recommended recipes are prompted to the user with the same visual and textual structure as the example presented in the “About” section. Dozens of recognisable icons or pictograms of popular applications mash up in couples. The prevalence of icons on the IFTTT interface surely plays an important role on the perception of the user, as Van den Boomen states: “We could then say that computer icons do their work by representing an ontologized stable state, while depresenting the procedural complexity”. (p.256) Furthermore, applications which were probably previously perceived as independent stand-alone and heterogeneous services, now appear as components of various connected pairs, giving the impression that the IFTTT platform acts on a higher level than the applications it connects. This characteristic surely demonstrates that IFTTT better meets the definition of platform as proposed in a blogpost by Andreessen than the definition of software, or product: “A “platform” is a system that can be programmed and therefore customized by outside developers — users — and in that way, adapted to countless needs and niches that the platform’s original developers could not have possibly contemplated, much less had time to accommodate.” (2007) Looking into the title of suggested recipes, very obvious elements of rhetoric typically associated with algorithms emerge and shape the user’s perception of the platform’s usefulness. Recipes titles claim to bring automation, efficiency, productivity, archiving, list making or rationalisation to all kinds of daily situations by using words such as “automatically backup”, “quickly organise” or “immediately keep”. Furthermore, most recipe’s titles are formulated in the imperative mood, emphasising on the power and control the platform claims to afford to the user, as stated in its slogan. Applications appear subordinated by the user to perform the desired action. While some of the recipes can be identified as work-related, an environment where increased productivity has long been established as a desirable aspiration, some others relate to personal or social activities for which it is less the case. As an example, the recipe called “Tweet Happy New Year!” automates the act of sending wishes under pre-established parameters, thus removing the spontaneity of this social behaviour. The “Channel” and the “Browse” sections of the platform allow the user to get a more structured and comprehensive idea of the typologies of recipes made available. As defined by IFTTT, “Channels are the basic building blocks of Recipes. Each Channel has its own Triggers and actions.” (ifttt.com 2015) As of June 2015, IFTTT counted 188 channels organised in 14 sub-sections.

Creating an IFTTT recipe only takes a few mouse-clicks and relies on a step by step procedure, again highly facilitated by the visual design and textual elements of the interface. First, the user access to a page where the general formula “if this then that” is displayed in oversized text. Through the use of the hyperlink visual convention in which blue and underlined text is clickable, the user is invited to click on the word “this” to select a trigger channel. The trigger defines which event or occurrence will initiate the running of the recipe. Depending on the chosen channel and its functionalities, a list of related triggers are proposed, accompanied by a brief description. As already mentioned, many channels involve services which are mobile-only. Consequently, the user is invited to switch to his mobile device to continue the process, making the download and installation of the IFTTT mobile application a mandatory step to use most of the service’s functionalities. “iOS location” is one these mobile-only channel for example, and it entails three different location-based triggers: “You enter or exit an area, This Trigger fires every time you enter or exit an area you specify.” (www.ifttt.com 2015) Some triggers require to be more precisely refined and customised with additional parameters. There again, the platform guides and helps the user with extra comments on how to complete the step. However open this customisation may seem, it remains possible only in a pre-established fashion. Once the trigger is defined, the second part of the recipe – the “that” component also called the “action” – can be set. Simply put, the action is the intended output of the recipe, its result. Following the same process as for the trigger, a list of channels is presented to the user through their representative icon. Once selected, the available actions (specific to the chosen channel) are displayed. Although it isn’t always the case, actions can often be composed with pieces of data extracted from the trigger, the so called “ingredients”. At first, handling ingredients appear slightly more technical than the previous steps and require a form of computer programming literacy. Ingredients indeed are named after less intuitive identifiers. As an example, ingredients available to compose an automatic e-mail from a Twitter trigger are “FirstLinkUrl”, “LinkToTweet”, “UserImageUrl”, “TweetEmbedCode” or “LocationMapUrl”. Once the action has been defined, the recipe can be saved and activated. From then on, the action will be executed automatically every time it will be triggered. Of course, the user can at anytime access his recipes, modify them or turn them off. Undoubtedly, the creation process of a recipe is strikingly simple compared to the complexity of the effective code it relies on. This apparent simplicity is the result of a great deal of expertise in interface design and the respect of rules of cognitive fluency which result in user’s adoption, as Jory Mackay similarly explains in an online post in the case of the design of Apple’s first iPod: “Simple things have a low psychological barrier of entry. We’re able to use them without any training at all.” (2015) The simplicity of the interface also allows and even fosters a playful use and a sense of experimentation. As such, recipes can be designed in a quite performative and comical state of mind as Rube Goldberg machines (Jones, 2011), in which causality and initial purpose of technologies are redefined.By selecting a channel, the user gets access to a list of pre-made service-specific recipes. Importantly, the user is invited to connect the channel, thus allowing IFTTT to indirectly access his data and information in regard to that particular service. It is also worth noticing that most of these channels are mobile applications or mobile services which require a smartphone or a connected device to be used. The “Browse” section of the platform filters recipes thematically by presenting them as “Collections” addressing all kinds of users, use-cases and cultural practices. “Recipes for your Wedding”, “Recipes for Baseball Fans”, “Recipes for a Healthy Lifestyle”, “Recipes for Following the News”, “Recipes for the Internet of Things” and “Recipes for Small Business Owners” are some noteworthy examples of “Collections”. Visually, these “Collections” are represented by colourful artworks with simplistic designs, somehow reminiscing child book iconography. Thus, a playful identity naturally emerges from this presentation undermining the technological dimension of the recipes. By presenting to the novice user very variated examples of recipes, the platform tends to demonstrate that all kinds of daily practices can be automated and thus fosters another perception of these activities. More importantly, IFTTT recipes are user-generated and correspond to actual ways users have perceived the platform and made sense of its affordances. By giving credits to the creator of the recipe and displaying popularity metrics such as the amount of times the recipe has been used, IFTTT builds a dynamic community which actively searches for new daily situations to automate. Moreover, a special “Top Chefs” page ranks the best contributors, therefore gamifying the act of creating recipes. This first look at the IFTTT platform so far has shown how its particular design and textual elements help creating a familiar and non-intimidating framework for recipes. Furthermore, the observations made on existing recipes highlight how productivity and efficiency have become common concerns in modern daily activities. In the next section, I will investigate how the interface lets the user create his own recipe, and the steps required to do so which should allow me later on to draw parallels with the discussion around algorithmic literacy.

How does the practice of creating an IFTTT recipe relate to computer programming and what are the limitations of the platform? In a blogpost published in the early stage of IFTTT, its founders Linden Tibbets and Jesse Tane describe the service in interesting ways: “essentially it’s event-driven programming for the masses” (2010). Event driven programming is the logic behind most computer programs and uses a vocabulary and key characteristics which are highly similar to the structure of recipes on the IFTTT platform. Triggers and actions are indeed terms IFTTT borrow to this programming paradigm. Notably, event driven programming relies on the process of an event loop, which is the piece of code that constantly runs in the background of the program to check if any event has occurred. Typical examples of event driven programs (EDP) are the graphical user interfaces (GUI) such as the Windows operating system, word processors or spreadsheets. Furthermore in their blogpost, the founders argue that “IFTTT isn’t a programming language or app building tool, but rather a much simpler solution. Digital duct tape if you will. […] You can leave the hard work of creating the individual tools to the engineers and designers”. (Tibbets and Tane 2010) IFTTT can perfectly be associated with the concept of end-user programming or end-user development as defined by Lieberman and al.: “End-User Development can be defined as a set of methods, techniques, and tools that allow users of software systems, who are acting as non-professional software developers, at some point to create, modify or extend a software artifact.” (2010, p.2). In No code required: giving users tools to transform the web, Cypher and al. have extensively described the phenomenon of end-user programming and explained its origin. Moreover, they’ve highlighted its increasing pervasiveness through case studies of several platforms which allow similar functionalities as IFTTT. (2010) They argue that “for as long as there have been computers to program, there have been attempts to make programming easier, less technical, and available to a broader audience. […] although most computer users do not know how to program, they would appreciate having some of the power of programming, if only it could be obtained with little effort.” (p.3) The fact that programming capabilities can be almost effortlessly obtained thanks to end-user programming approaches and optimised user interfaces has been intensely criticised by several authors who point out the risks and limits of this type of practice and strongly recommend to invest time and effort in understanding computer languages and algorithms, especially in the domain of education: “we must learn how to make the software, or risk becoming the software. It is not too difficult or too late to learn the code behind the things we use”. (Rushkoff, 2010, p.128). The fact that IFTTT offers the capability to create high level functionalities without having to deal with low level programming resonates with Rushkoff’s warning and raises further questions such as what should count for real algorithmic literacy and how the next generations should be thought to use and perceive computers and softwares, in order to avoid remaining “surface users”. In a recent study, Csernoch and Biró have similarly outlined this issue and argued that most computers users have been tricked by software development companies into thinking that “by using the GUI and its accompanying wizards [they] would be able to solve problems.” (2015, p.551) Furthermore, they demonstrate that educational systems have also followed the same misconception and have therefore become inefficient in transmitting a fundamental understanding of computer science by favouring “Surface-approach metacognitive processes” which are “not sufficient for problem solving, and consequently, developing digital competency, digital literacy, and algorithmic skills”. (2015, p.552) On a similar note, British politician Michael Gove argued that by encouraging rigorous computer science courses, the UK education system could create a fertile ground for talented and innovative minds: “instead of children bored out of their minds being taught how to use Word and Excel by bored teachers, we could have 11 year-olds able to write simple 2D computer animations using an MIT tool called Scratch”. (2012) Another danger identified by Rushkoff is that people increasingly rely on algorithm’s automation process without understanding them, a phenomenon often referred as blackboxing. As he states: ”these are technologies that carry on long after we’ve created them, making future decisions without us.” (2010, p.138) This issue is relevant when looking at IFTTT, since the platforms precisely aims at independently taking over some tasks in the name of its user. However pessimistic and paranoid this vision of end-user programming may seem, it does provide interesting counter arguments to the multitude of services of this kind and to the companies who advocate their benefits. It also rightly argues that by relying on graphical user interfaces, end-user programmers act within inflexible boundaries and limit their custom programs to pre-existing functions, thus somehow narrowcasting the possibilities: “We learn what our computers already do instead of what we can make them do.” (Rushkoff, 2010, p.137) Surely IFTTT users can’t make up new actions or triggers by themselves. However, it isn’t the initial purpose of the service and it doesn’t pretends to be an interface to create new functionalities. Rather, as previously explained, it aims at automating and making a more personalised and productive use of existing functions and applications. In summary, the reliance on GUI, the limitations and the code opacity are evidences that IFTTT can’t fully count as a programming language or as a form of algorithmic literacy stricto sensu. But it is probably more insightful to look at what IFTTT does than at what it doesn’t. Indeed, it still provides users with a powerful conceptual framework of pre-established relationships between services and enables an unprecedented modularity, letting another form of innovation emerge: “you can take two things in the digital world and combine them in ways the original creators never imagined”. (Tibbets and Tane 2010)

As we have seen, IFTTT itself does nothing new. And it couldn’t do anything at all if it wasn’t for the multiple existing technologies it relies on. As previously explained, the building blocks of IFTTT are other services, all independent and self-sufficient. Before being an IFTTT user, one does need to be a user of the services (channels) which compose the platform. On a lower level, these services themselves rely on other technologies. This modularity is essentially a conceptual structure of all softwares as Manovitch explains: “Structural computer programming […] involves writing small and self-sufficient modules […]. These elements are assembled into larger-scale objects but they continue to maintain their separate identity. The objects themselves can be combined into even larger objects – again, without losing their independence.” (2001, p.52) The result of this layered structure is an inevitable technological interdependence on a higher level, which is a known characteristic of most technologies and is particularly applicable to new media and softwares. Combining technologies require technical standards, and compatibility can only be achieved when technologies are designed to communicate together. In the case of IFTTT, the standard is nothing less than the World Wide Web, which is by essence “completely modular. It consists from numerous Web pages, each in its turn consisting from separate media elements. Every element can be always accessed on its own.” (Manovitch, 2001, p.51) Fourteen years after this statement of Manovitch, the internet landscape has considerably evolved and surely doesn’t limits itself to Web pages, but it has undoubtedly kept its modular structure, and applied it to always more services and more importantly to mobile technologies. Moreover, the web has evolved into a complex eco-system, and innovation on the web today is almost always linked to third parties. In a 2009 study, Yu and Woodard have investigated the raise of personalised applications called mashups (a concept similar to IFTTT recipes, but demanding a higher programming skill set) and the growing importance of application programming interfaces (API) which allow them to emerge. (2009) An API is a set of commands and function of a particular service or operating system, usually well documented into a library, which can be used by an external programmer without having to write the entire code from scratch. Simply put, an API provides shortcuts for programmers. Thus, IFTTT can be seen as an end-user API, a shortcut to shortcuts. Through a quantitative and visual approach of the use of APIs, the research of Yu and Woodard has demonstrated the “structural richness of this network” and how some popular APIs were at the core of a majority of mashups: “by far the most popular of the platform APIs is Google Maps, which was used by 48% of the mashups in our sample.” (2009, p.146) As of June 2015, the website ProgrammableWeb.com, a leading source of information about APIs, lists a total number of 13’622 APIs. (www.programmableweb.com 2015) In relation to this number, the 181 channels available on IFTTT now appear as a very small percentage of the web’s existing service. This important gap shows how much more possibilities programmers still have compared to end-user programmers on IFTTT. While IFTTT developers are constantly working in including new channels for end-users, their resources are limited and they can’t realistically keep up with the speed at which APIs of new services are created across the web. To solve this equation, IFTTT has recently announced that third party developers could soon create channels by themselves, allowing for more diversity and use-cases. However promising this sounds, it will surely raise questions about the quality and reliability of the code behind the platform. Indeed, APIs are not all created equal in quality and so could it be for channels if their implementation on IFTTT were to be outsourced. What naturally emerge from these considerations is the importance, or even the necessity of a strong and reliable code at the basis of the programmable web. Since more and more technologies rely on each other, keeping the system healthy and viable comes down to having strong foundations. And the more layers of technology are added to the society providing simplicity at the top of the users pyramid, the more reliably the lower layers must be built. In a TED talk addressing a similar question, namely the technology behind the Google search engine, George Whitesides argues that Google “makes the claim that it makes accessible all of the world’s information. But the point is that that extraordinary simple idea rests on layers of simplicity each compounded into a complexity that is itself simple, in the sense that it is completely reliable.” (2010) Kevin Kelly brings this global vision of technologies as part of a greater a whole to an even larger dimension in the now famous What Technology Wants? (2010) Coining the concept of “Technium” (p.12) as a “super-organism”, a web of all these things together that requires each-other, Kelly argues that only “when all the required conditions generated by previous technologies are in place, the next technology can arise” (p.152). This deterministic and slightly biased view fits to how the technology of IFTTT can’t be separated from the technologies of its constituents services. This organic vision of technology appear problematic for the society if we consider who the stakeholders behind all these technologies are. For a service, a connected device or a mobile application, having an IFTTT channel holds obvious potential consequences in terms of commercial growth. Indeed, a channel creates traffic and visibility, it increases usage and somehow even automates the user’s loyalty. While the platforms argues, through the official slogan “put the internet to work for you” (www.ifttt.com 2015), that the tool gives power and control back to the user, the previous chapters of this paper have hinted that the real power may not really be in the end-user’s hands. Rather, by offering only a selection of existing services, and obviously the most popular ones, the platform involuntarily reinforces existing power structures. Mass media companies such as The New York Times have IFTTT channels and suggest specific recipes which logically aim at increasing media consumption. Comparing the 50 most popular recipes with the recipes prominently advertised on the platform reveals a shift towards promoted content and advertising models. As the number of channels will keep growing, IFTTT will likely have to make a decision in terms of commercial neutrality to keep its end-users at the centre of the platform.

Below are titles, creator, users and likes of the 50 most implemented IFTTT recipes as of June 2015.

Reflecting on the thoughts and ideas presented in this paper, it is safe to say that IFTTT proves to be a very interesting platform for academic as well as business researches. While its end-user programming nature and its mission statement first appears as empowering users and allowing them to increase personal productivity by taking advantage of the web ecosystem, a deeper look at the interface biases reveals a slightly more nuanced picture. Of course, the platform shines by its simplicity and its cleverness in abstracting complex processes and turn them into simple statements, accessible to any user. Users have indeed proven to adopt this new language and adapt their cultural practices around it. However, the platform’s desire to be simple results also in an inevitable effect of blackboxing. Several questions may raise from this research. Among them, it is relevant to interrogate ourselves about the resilience of the programmable web. What would the discontinuation of a widely used API mean to the rest of the network and what cascading effects or systemic reactions could it trigger? Personal IFTTT recipes would stop working and inevitably affect end-users and cause potential damage. It might not be a big deal if the recipe sending the score of the latest Baseball game by e-mail malfunctioned, but it might be more impactful if a recipe handling the electric system of a user’s house were to disrupt. What appears evident is that although they might take advantage of IFTTT in the short-term, algorithmically illiterate end-users will never fully understand the tools and service they use if they remain interface dependant, and therefore they will increasingly find themselves in a weak and technologically-dependant position.


I wrote this essay in the context of the Master Programme in New Media Studies & Digital Culture
I am currently following at Utrecht University.
More specifically, this research paper was part of the Software Studies, a class given by dr. Stefan Werning.


Bibliography

Andreessen, Marc. 2007. “The Three Kinds of Platforms You Meet on the Internet”. Accessed June 24. http://pmarchive.com/three_kinds_of_platforms_you_meet_on_the_internet.html.

Csernoch, Mária, and Piroska Biró. 2015. “The Power in Digital Literacy and Algorithmic Skill.” Procedia – Social and Behavioral Sciences 174. Elsevier B.V.: 550–59. doi:10.1016/j.sbspro.2015.01.705.

Cypher, A, M Dontcheva, T Lau, and J Nichols. 2010. No Code Required: Giving Users Tools to Transform the Web. Burlington, USA: Elsevier.

Gove, Michael. 2012. “Michael Gove Speech at the BETT Show 2012.”. Accessed June 19 2015. https://www.gov.uk/government/speeches/michael-gove-speech-at-the-bett-show-2012 .

IFTTT – Put the Internet to Work for You.” 2015. Accessed June 24 2015. https://ifttt.com.

Kelly, Kevin. 2010. What Technology Wants. New York: Penguin Group. doi:10.5840/traddisc2010/201137341.

Lieberman, Henry, Fabio Paternò, Markus Klann, and Volker Wulf. 2006. End-User Development: An Emerging Paradigm. Human-Computer Interaction Series. Vol. 9. Human-Computer Interaction Series. Dordrecht: Springer Netherlands. doi:10.1007/1-4020-5386-X.

MacCormick, J. 2011. Nine algorithms that changed the future: The ingenious ideas that drive today’s computers. Princeton, NJ: Princeton University Press.

Manovich, Lev. 2001. The Language of New Media. Edited by Paperback. Cambridge, MA: MIT Press.

Jones, J. 2011. Algorithmic rhetoric and search literacy. Paper presented at the meeting of the Humanities, Arts, Sciences, and Technology Advanced Collaboratory (HASTAC), Ann Arbor, MI.

Mackay, Jory. 2015. “The Psychology of Simple.” Accessed June 20 2015. https://blog.crew.co/the-psychology-of-simple/.

Robinson, Derek. 2006. “Function.” In Software Studies – A Lexicon, edited by Matthew Fuller, 101–10. London: The MIT Press.

Rushkoff, Douglas. 2010. Program Or Be Programmed: Ten Commands for a Digital Age. illustrate. Or Books.

Tibbets, Linden, and Jessy Tane. 2010. “Ifttt the Beginning…”. Accessed June 10 2015. http://blog.ifttt.com/post/2316021241/ifttt-the-beginning.

Van den Boomen, Marianne. 2009. “Interfacing by Material Metaphors: How Your Mailbox May Fool You.” Digital Material: Tracing New Media in Everyday Life and Technology, 253–65.

Van Dijck, José. 2009. “Users like You? Theorizing Agency in User-Generated Content.” Media Culture Society 31: 42–58. doi:10.1177/0163443708098245.

Whitesides, George. 2010. “Toward a Science of Simplicity.” Accessed June 10 2015. http://www.ted.com/talks/george_whitesides_toward_a_science_of_simplicity?language=en.

Yu, Shuli, and C. Jason Woodard. 2009. “Innovation in the Programmable Web: Characterizing the Mashup Ecosystem.” Lecture Notes in Computer Science 5472 LNCS: 136–47. doi:10.1007/978-3-642-01247-1_13.

Accademic essays