Analyzing the Communicability of Configuration Decision Space Over Time in Collaborative Systems through a Case Study

— Some configuration settings have immediate impact on system state; others have impact over time. In collaborative systems, the timeline of impacts can be even more complex, because changes may impact not only the user who made them but also other users. In this paper, we analyze the challenges involved in specifying configuration in collaborative systems that have impact over time. To do so, we have chosen Google Inactive Account Manager (IAM) as a case study, since it offers a limited set of decisions, but that addresses different aspects that are relevant to future impact configuration. In order to generate a thorough and systematic analysis of the communicability of Google IAM’s decision space we used the Semiotic Inspection Method (SIM) and the Configurable Interaction Anticipation Challenges (CIAC), as well as the Modeling Language for Interactive Collaborative Conversations (MoLICC). Our results describe and explain some of the main issues associated to the complexity of decisions that users may take in during a configuration task.


INTRODUCTION
Digital technologies are embedded in many aspects of people's daily lives: in their work, entertainment and civic behavior.Through social computing systems people interact with other people, generate and store significant data over time, including work files, personal and professional contacts, photos, etc.A challenge in designing such systems is to represent all of the many nuanced effects that people's interaction with each other may have in the physical world.Ackerman [1] argued that the mismatch between what is required socially and what can be done technicallythe social-technical gapis a fundamental problem for collaborative systems and much of it applies in social computing contexts.
One approach to narrowing the social-technical gap is the creation of flexible systems that allow users to tailor a system to their contexts, needs and preferences.
Many researchers have explored related ideas, including both customization (allowing users to choose among behaviors already available in the application) and enduser development (allowing users to create, modify or extend their own software artifact) [14].Research has investigated a broad set of issues, such as how users collaborate to tailor a system (groupware or not) [22]; toolkits [11] and frameworks [31] that support the development of adaptive groupware systems; and how to support users in understanding the impact of their choices in groupware [30].
In spite of the broad array of research on adaptation of group and social computing systems, researchers have not considered configuration decisions that have their effects over time.One reason may be that these sorts of time-dependent configurations are only now starting to play a larger role in existing systems.Increasingly, a user makes decisions that change not only the next state of the system, but also the possible interactive paths (the set of states achievable by future actions that have been enabled by the current decisions).For instance, concerns about specifying future states in Facebook have emerged, ranging from cleaning up profiles 1 to what happens to profiles when users pass away 2 .
Our research focuses on the challenges of specifying configurations in collaborative systems 3 that may impact future interactive paths.When such configuration possibilities are offered to users, designers must support users in anticipating at the time of their decision the impacts that they may have on future interactions with other users or on how their information or digital artifacts might be accessed (e.g.data, photos, files, etc).For example, Pereira Jr. et al. [20] illustrate the difficulties that Facebook users have in understanding some of the potential consequences of posting a photo to friends.While they understand that the photo will be visible to their friends, it is not clear what these viewers or other users can do with the photo, or who might be able to gain access to it eventually.
In this paper, our goal is to probe the complexity of decisions that users may take during a configuration task that come into effect over time in collaborative systems and that involve different users.Our communicability analysis is grounded on the Semiotic Engineering theory of HCI [8] and focuses on raising and discussing issues related to configuration settings, but where the impact unfolds over time.In order to contextualize our discussion, we have chosen Google Inactive Account Manager (IAM) as a case study.
Google IAM is an especially interesting case because it has been designed to handle decisions about accounts that become inactive because their owners are (likely) no longer available to take action themselves.Thus, they should not be able to verify if the settings they choose in the present achieve the intended impacts in the future (and make changes if they do not).Although the configuration process is mainly a singleuser interaction with the system, the user makes decisions that will involve future asynchronous interactions with other users (albeit unidirectional), and of these users with the system.Thus, Google account owners make decisions that will only come into effect in the future and that will affect other people.
The methodology for this piece of research follows the same foundational theory as much of Semiotic Engineering itself, namely Peirce's semiotics and pragmatism, the pillars of his scientific method [19].Briefly, this method is composed of three sequential stages: (a) abduction; (b) deduction; and (c) induction.During the abductive stage, investigators study the hypotheses that will drive the entire scientific cycle.All hypotheses must have consequences that can be immediately formulated and tested against a limited range of facts at hand.Once they pass the abductive reasoning stage, the deductive stage begins.In it, all the logic consequences of the hypotheses qualified in the previous stage are generated.If no logic contradictions are found at this stage, the inductive stage begins, in which logic possibilities are tested for empirical truth in order to confirm, or disconfirm, the generalizations contained in the hypotheses that came from the first stage, abduction.
Empirically confirmed truths reinforce the investigator's knowledge base and belief systems, and trigger new logic deductions, followed by new empirical tests at the next inductive stage.Disconfirmed facts, which are found not to be true, surprise the investigator, who thus engages in abductive reasoning, again, to correct his previous knowledge and find more appropriate hypotheses.The entire cycle begins anew, moving towards empirical truth, which in Peirce's view is only achieved by the scientific community in a historically continuous process of approximations and corrections that create habits of interpretation and action (which may eventually bring up surprising contradictions and reveal the fallibilism of the scientific process, which abduction is ready to embrace and begin to correct, once again).The pragmatism of Peirce's view lies in that all hypotheses (and knowledge) must be translated into action in the world, the process that will finally test them for their truth [3][7].
Against this backdrop, our investigation about what may be true in the future falls naturally in the category of inquiry that relies on abduction, that is, on the construction of qualified hypotheses to be used in subsequent stages of the ongoing scientific method.There have been many interpretations of what is meant by an abductive process in science.We follow the general orientation of Magnani's approach [17], which distinguishes between theoretical abductions (guided by theories, models, conceptual frameworks, and symbolic manipulations) and epistemic abductions (guided by the manipulation of real facts and objects in a situated inquiry of the form and meaning of hypotheses).Therefore, our theoretical abductions are informed by the Semiotic Inspection Method [9][10], the Configurable Interaction Anticipation Challenges (CIAC) [23] and MoLICC, an extended version of MoLIC (Modeling Language for Interaction as Conversation) for collaborative interaction [28] [29].Because all of these are developments from Semiotic Engineering theory [8], they provide us a cohesive set of theoretical tools to guide the questions and issues that we find when examining Google IAM.This specific piece of technology gives us the necessary empirical evidence to strengthen and qualify our hypotheses, while manipulating epistemically the objects of this system's structure and behavior, as embedded in the technological discourse communicated by its designers and developers through the system's interface.
In the next section of this paper, we present other works related to collaborative systems configuration and configuration over time.In section III we briefly present Semiotic Engineering theory that grounds the methodology and analysis performed.The methodology adopted in our research is presented in the following section.Next, we present our analysis of Google IAM, followed by the discussion of our analysis and our conclusions.

II. RELATED WORK
Configuration is a popular solution for adding flexibility to a computational system.With configuration settings, users can adapt aspects of the system (e.g.functionality or look-and-feel) to better fulfill their needs or preferences.To support configuration, system designers decide at design time what parts of the system users will be able to configure and which are the set of parameters and values that best represent them.
Group system configuration research covers earlier collaborative systems applications as well as social computing.In collaborative systems, Wulf et al. [31] have addressed flexibility at 3 levels.The architecture level focuses on deeper architectural rearrangements; the interface level, on supporting changes by end-users; and collaboration focuses on providing support for sharing tailored artifacts among groups.
In the present work, we focus on the interface level, and more specifically on user configuration over time.Users' configuration can have a range of impacts on systems, especially when considering collaborative systems in which changes can affect both the users themselves and other users.They also can impact both the current state and future interactive paths of the system [23].
An impact on the system's state means an immediate impact on the interface or behavior of the system (e.g.including a button in a toolbar or changing the visibility of a document in a collaborative editing system).Solutions ranging from providing users with awareness [4] to creating specific graphical interfaces used to visualize and interact with a set of parameters [6] [25] have been proposed to support users involved in understanding configuration changes.
Impact on interactive paths of a system means that the changes have an effect not only on the state, but also on actions (other) users can take as a result of that change.For instance, in Facebook, setting the visibility of a photo to one's friends has an impact on the actions those friends can take (e.g.tag someone in the photo); these actions in turn may change the initial userspecified visibility of the photo.This interactive path is one of many that may (or may not) take place due to the specification; such impacts (if any) may occur immediately or at any moment in the future.
In this direction, some researchers have proposed that users should be able to explore (some) future interactive scenarios using a simulator.Wulf and Golombek [30] allowed users to explore the filtering of settings used to publish or receive information by simulating different setting combinations across two users.Pereira Jr. et al [20] noted problems Facebook users had in understanding the effects of their privacy settings for photos.They proposed a simulation environment that would visualize an abstract relationship network and allow users to ask "what-if" questions about settings, including possible impacts of other users' actions on photo visibility.
Although some of these papers investigate how users can explore future scenarios and interactive paths, they do so for specific case studies.Their results show that allowing users to explore and interact with the future scenarios improves their understanding of them.However, no one has offered general guidelines, criteria or methods that could be used to evaluate the broader problem of how systems support users in understanding the effects of settings over time.
After identifying the digital legacy scenario as an interesting case, we also looked at the research in this specific application arena.We found that such research has mainly contributed to identify needs, requirements or guidelines to develop systems for the bereaved, or supporting people to prepare for their own deaths [16] [18].We found none addressing the impacts of user-specified configurations over time.
Our research contributes to the scientific investigation of future impacts of system configuration, as it raises relevant issues drawn from analysis of Google IAM.In the next section, we briefly present the Semiotic Engineering theory in which our analysis is grounded, followed by the methodology adopted in this work.

III. SEMIOTIC ENGINEERING IN A NUTSHELL
Semiotic Engineering [8] is an HCI theory that perceives an interactive system as a communicative act from designers to users.Designers communicate decisions regarding who they believe the users are, what problems the system can solve, and how users interact with it to do so.The system acts as the designer's deputy and conveys to users the designer's message, that can be paraphrased as: "Here is my understanding of who you are, what I've learned you want or need to do, in which preferred ways, and why.This is the system that I have therefore designed for you, and this is the way you can or should use it in order to fulfill a range of purposes that fall within this vision." The message is transmitted indirectly to users, who grasp it as they interact with the system's interface.Thus, in Semiotic Engineering the interface is perceived as a metamessage because it conveys the designers' message to users by exchanging messages itself with users (user-system interaction).
In creating their message designers' must define its content (that is, what to communicate), as well as its expression (how to communicate it).The content of the message involves making the necessary decisions to fill out the metamessage template (the paraphrased representation of the method described above).In the case of configurable systems, the content includes the decision space designers are offering users.The expression of the message can be thought in terms of the interaction and the interface layout.Designing the system-user interaction requires the designer to define the possible system-user communications that can take place to convey the metamessage.To do so, a Modeling Language for Interaction as Communication (MoLIC) has been proposed [2] [27].It was initially proposed for single-user systems, but it has recently been extended for collaborative systems (MoLICC) [29].
In this theoretical framing, the quality of the interface is associated to the quality of the designers' message to usersthat is, its communicability.Communicability is the distinctive quality of interactive computer-based systems that communicate efficiently (in an organized and resourceful way) and effectively (achieving the desired results) to users their underlying design intent and interactive principles [10].
A message being transmitted is comprised of signs.A sign is anything that someone can take to stand for something else in some respect or situation [19].In Semiotic Engineering interface signs fall into one of three classes: static, dynamic and metalinguistic [9] [10].Static signs are those whose meaning can be interpreted independently of temporal and causal relations (e.g.menu options or toolbar buttons).Dynamic signs, in contrast, are bound to temporal and causal relations and represent the system's behavior (e.g. when the user clicks on a link or button labeled "Change this setting" a dialog about the setting to be changed follows).Finally, metalinguistic signs refer to other (static, dynamic or metalinguistic) signs (e.g. an explanation on what a configuration parameter refers to).
Currently, there are two main methods for assessing the communicability of a systemthe Communicability Evaluation Method (CEM) and the Semiotic Inspection Method (SIM) [9].In our case study, we use SIM because it focuses on interface meanings and design intent expressed by the designers of the systems.In other words, it focuses on the emission of the meta-communication message.In the next section, we explain the methodology adopted in our work, as well as the methods used in our analysis.

IV. METHODOLOGY
Our goal was to explore aspects related to the configuration space when the impact of users' decisions comes into effect over time and involves other users.As a case study, we have chosen Google IAM, as the decisions users make are only meant to be activated once they become inactive, and typically involve trusted contacts.
In order to perform a systematic and thorough analysis of Google IAM, we use the Semiotic Inspection Method (SIM) [9] [10].Our goal was to not only generate an account of the users' space decision offered in Google IAM by designers, but also specifically take into consideration the challenges involved in configurations in collaborative systems over time.Therefore, we combine SIM with the Configurable Interaction Anticipation Challenges (CIAC).Previous work has shown that SIM can be applied to different domains and take into consideration different aspects of the interface [26], including in combination with CIAC [24][21].
The users are presented the systems' decision space through their interaction with the system.Thus, we have also re-engineered the possible conversations the users can have with the system using MoLICCa Modeling Language for Interaction as Conversation in Collaborative Systems.Model-based inspections allows evaluators to represent a system using an abstraction defined by a model; this representation is then analyzed to gain insights about the system [13].In our research, it explicitly represents the possible interactive paths the account owner may have with the system, as well as the resulting interactive paths that trusted contacts will have with the system at a future time.Fig. 1 presents an overview of the methodology adopted in this work.
We next briefly present in this section the Semiotic Inspection Method (SIM); the Configurable Interaction Anticipation Challenge (CIAC); how SIM and CIAC were combined; and, finally, MoLICC.

A. Semiotic Inspection Method (SIM)
SIM [9][10] is an inspection method and thus is an interpretive and qualitative method.However, different from the other HCI inspection methods the goal of SIM is to explore the communicative potential of interactions, including the identification of design intent, communication contents, expressive choices, and alternative paths, both successful and unsuccessful.As part of the process the evaluator is required to reconstruct the designer's meta-communication using the message's paraphrase as a template.To prepare for SIM the designer defines the focus of the analysis and scope of the evaluation, and prepares an inspection scenario [5] that will provide the contextual structure required for the communication analysis.The method is then carried out in five steps: the three first ones are a segmented analysis in which the evaluator examines all the 1) metalinguistic signs, 2) static signs, and the 3) dynamic signs in the system related to the inspection scenario.At the end of each of these steps the evaluator reconstructs the metacommunication message based on the inspected signs of the corresponding step.
In step 4 the evaluator contrasts the results and reconstructed message from each of the previous steps.The evaluator should analyze the results from each step, identifying points at which they are consistent or redundant, and pointing out any inconsistencies and gaps that may be identified among them.Finally, in the fifth and last step the evaluator reconstructs a unified meta-communication message and assesses the costs and benefits of communicative characteristics and strategies.Fig. 2 illustrates the steps of the method.
We next describe the Configurable Interaction Anticipation Challenges, and then explain how they were combined with SIM

B. Configurable Interaction Anticipation Challenges (CIAC)
As designers decide at design time the configuration settings that will impact interactive paths over time, they should consider whether and how users will be able to understand such future possibilities at the moment they are changing configuration settings.As a step in this direction, Prates et al. [23] have proposed five challenges -Configurable Interaction Anticipation Challenges (CIAC)that might help in this planning process: Anticipation support: there may be a large or even indefinite number of possible interactive paths that may be enabled by a configuration setting.Can users anticipate the effects their decisions may have now or in the future (all of them or the most relevant ones)?
Representation: in defining the configuration, there are two aspects that designers must define: 1) the settings interface; 2) representing the possible effects of setting choices to users.If the settings interface makes use of a common set of interface elements, users will be familiar with them (e.g.choosing which elements of a menu should be displayed in a toolbar).However, the settings interface may also introduce new signs that refer to aspects of the interface that only make sense in a configuration settings dialog (e.g. the name to show in a collaborative editor when a comment is added).Regarding configuration effects, designers must weigh pros and cons of an abstract representation versus a simulation of the actual interface, as well as whether and how future scenario exploration will be supported.
Costs x benefits: analyzing the possible effects of a decision will have a cost to users, so designers should consider in which situations the benefits would be worth the cost.What are the advantages of an informed decision and how does this compare to the cost of not having information about the potential impacts?
Conflict negotiation and mitigation: In group systems, when decisions have effects on others, conflicts may arise.Designers should identify possible conflicts and how to support users in mitigating them.

Definition of default values:
Configuration settings often require designers to define default values.In this case designers will make decisions about which default values are most appropriate.Do these default values represent users' expected preferences?Do they represent an intended use for the system?

C. Combining SIM and CIAC
SIM analyzes the meta-communication being conveyed by the designer.Thus, we combine SIM with CIAC so as to analyze if and how designers used metacommunication messages to transmit any decisions they had taken in relation to the challenges raised in CIAC.In our analysis, to combine CIAC with SIM in steps 1 to 3, the evaluator explicitly registered and analyzed signs for each of the classes that conveyed decisions related to any of the five challenges.In step 4, in addition to the required meta-communication analysis, the evaluator analyzed signs, communicative aspects and design intent related to each challenge.In other words, no changes were made to the steps of the method, but rather an analysis of the challenges was embedded to allow for a specific focus on what was being conveyed to users.For instance, besides reconstructing the metamessage template, the evaluator also considered what designers had conveyed regarding support for anticipation, such as Does the system allow users to anticipate the effects considered by the designers?If so, how and in regards to which settings?

D. MoLICC (Modeling Language for Interaction as
Collaborative Conversation) MoLIC (Modeling Language for Interaction as Conversation) is an interaction design language based on Semiotic Engineering [2].The language allows designers to describe the interaction as a set of possible conversations that the user can have with the system's interface.To do so, MoLIC offers a graphical representation that allows designers to represent the beginning of the conversation, the topics that are addressed, possible turn-taking between users and systems, potential breakdowns that may take place during the conversation, as well as the end of the conversation.It is interesting to notice that since MoLIC focuses on how the designer's metamessage is conveyed to users through the system, it represents the system processing that takes place within the conversation as a black box (see Fig. 3 (e)).Recently, MoLIC was extended in order to also be able to represent interaction in collaborative systems [29].This extended versiondenominated MoLICCincluded 3 new elements in the language: Incoming Message Indicator (IMI), Outgoing Message Indicator (OMI), Shared Space Indicator (SSI).OMI allows designers to indicate a message being sent from one user role to another one.Whereas IMI indicates, when (in the conversation with the system) a message will be received by the other user role.In other words, IMI and OMI allow the designer to represent messages that can be exchanged (synchronously or asynchronously) by users through the system.SSI on its turn, allows designers to represent a shared communication space, that is a space in which different users' roles can participate in the communication with and through the system.
In this paper, we do not present a complete description of MoLIC or its extended version, MoLICC.We limit the explanation to the elements that were used to represent the Google IAM interaction, with both users' role (i.e. the account owner, and the trusted contact).Fig. 3 presents the elements of MoLICC described in this section and that will be necessary to understand the analysis presented in the next section.

E. Methods' Application
In the case study, the first author who is an expert in Semiotic Engineering applied the methods, and discussed the results with the other authors 4 .The analysis using SIM integrated with CIAC was conducted in March 2015 5 , using this inspection scenario:

Jim is a professor who operates almost entirely in the digital realm. He is very organized with his email, redirecting accounts to Gmail, where he tags and separates files that are work related, that relate to bills or shopping or are personal. He also uses Google systems to save documents, pictures, videos and other types of data. When Paul, a good friend of Jim's passed away unexpectedly, Jim started thinking about what would happen to all his digital "stuff" if he were to die. He found that Google allows users to specify what to do when an account becomes inactive. He wanted to know what decisions about his "stuff" he could make and
4 The author who conducted the analysis presented the complete metamessage and findings of her analysis, as well as the evidence used to achieve them.All the material generated was made available to the other authors for comment and refinement of the analysis.5 It is noteworthy that in 2017 (noticed by authors in August of that year) Google IAM changed its configuration interface.Although users' decisions and steps to be taken are the same, their presentation has changed and for some decisions, more information about their effects has been added.

what would their effects be once his account became inactive.
As mentioned, Google IAM is an intrinsically asynchronous group system, since users' interaction to determine the future of their digital assets will (usually) also define how other users will interact with the system at a later moment.Although the scenario does not explicitly mention the trusted contacts interaction with the system, the inspection included analyzing the effects of users' decisions.The actual interaction of a trusted contact with the system was not examined, since it would require an actual inactive account.
The analysis comprised all of Google IAM's metalinguistic signs available at Google IAM dialogs, as well as in the help system (including the help page aimed at trusted contacts).All static signs available in the different screens of the decision configuration process, as well as all dynamic signs represented by the possible interactions were inspected.Due to space constraints in the next section, we only present the results of our analysis, represented by the final reconstructed designers metamessage, as well as the analysis of the future impact of configuration decisions offered to users.Fig. 4 and Fig. 5 described in the next section present some of the static and metalinguistic signs inspected during our analysis.
The re-engineering of Google IAM using MoLICC was conducted in April 2017.The resulting interaction models were based on the knowledge about the system, generated through the systematic analysis using SIM and CIAC.
As mentioned in the Introduction, the two analysis methods (SIM+CIAC and MoLICC) are used to perform different analyses of Google IAM, and to inform a theoretical abduction focused on raising issues involved in designing systems that offer users configuration decisions that will only come into effect over time.The results of these two analyses are presented next.

V. GOOGLE IAM ANALYSIS
In this section, we present our primary results of the analyses performed.The section is organized into four subsections: in the first one we present the reconstruction of the designer's metamessage to users; in the second one we summarize the decision space that is offered to users; next we discuss the findings according to each CIAC challenge; finally, we present the interaction models generated and our main findings based on them.

A. Reconstructing Google IAM Designer's Message
In the final step of SIM, the evaluator generates a unified meta-communication message based on the contrast of the metamessages generated in previous steps.Here we present this final metamessage generated according to the SIM template.("We" refers to the Google IAM designers, and "you" to users.)

''Here is my understanding of who you are, ..."
We understand that you are a Google user who has data stored in Google products.

"... what I've learned you want or need to do, ..."
You want to plan for the future of your digital assets stored in Google products.You want to determine who should be notified and who should have access to which of your data, when your account becomes inactive, that is, when you stop using it for any reason.

"... in which preferred ways, and why."
You want to be the one to decide if you want to do this planning and if so, when you want to do it.Also, you want this to be easy and quick to do.

"This is the system that I have therefore designed for you and this is the way you can or should use it in order to fulfill a range of purposes that fall within this vision."
I understand that you are the best person to tell us how long without any activity we should wait before considering your account inactive (consider a period between 3 and 18 months).Also, we want to make sure that it really is inactive and will send you an alert, so that you have the chance to prevent it from being considered inactive if that is not actually the case.To do that, you must provide us with a cell phone number and we will send you a verification code to confirm the number.We will also send a message to your Gmail account and any other email accounts you wish.Also, we believe you would like trusted contacts (up to 10 people) to be made aware that your account is now inactive.You can either just notify them or also give them access to any of your data available in some Google products.For each trusted contact, we believe you want to write an individual message.For those you wish to grant access to download (part of) your data, you must also provide a cell phone number.The phone number will be a way for us to guarantee the security of your data, because once the trusted contact is notified he or she will be sent a verification code using the cell number to guarantee that only the intended person will be able to download your data.Your trusted contacts will not be informed of their nomination until your account becomes inactive.They will then receive the message you wrote to them with an explanation from us saying that we have been instructed by you to send this message, and for those to whom you grant access to your data, we will also include the instructions on how to download the data.You can also write a message to be sent automatically as a response to anyone or just to your contacts who email you.
You can also decide whether you would like us to delete your account and data after it has become inactive or not.In case you do, it will only be deleted after your instructions regarding notifications and access have been carried out.
Because our goal is to offer you a simple and easy process, we explain each of the steps to you in a "just in time" fashion.The first time you enter the settings we provide an explanation of what it is meant for and what steps are involved.The next times you enter, this is not needed, but it will be available on demand.For each step, we provide brief instructions that will allow you to change the settings easily.

B. The User´s Configuration Decision Space
The reconstruction of the designer's metamessage identifies and describes the decision space that Google IAM designers provide to users in regards to planning the future for their digital assets.The decision space involves the definition of four settings: Alert me, Timeout period, Nominating trusted contacts and Deciding on deleting or not the account.Fig. 4 illustrates some of the static and metalinguistic associated to each one of the settings available in Google IAM.
The timeout period settings determine when the settings will come into effect, and the "alert me" warns the user before they do, guaranteeing that the account is actually inactive and the users are not taken by surprise.
Nominating trusted contacts and deleting the account will impact not only the user him/herself, but also other peoplethose appointed as trusted contacts; those who get an automatic Gmail response; or those who try to interact with available assets in the future (e.g. an inactive user's YouTube channel).

C. CIAC Guided Analysis
As explained in the methodology section, we used CIAC as a guide in step 4 of the SIM analysis, to inspect if and how designers had dealt with each of the challenges related to configurations with future impact.We next present the analysis for each of the challenges.
Anticipation support.For Google IAM there are two decisions that have primary impact on interactive paths: nominating trusted contacts and deciding about account deletion.Therefore, our analysis of anticipation support focused on identifying if and what kind of signs Google IAM designers communicate to users for anticipating the effects of these decisions.
Users are told in natural language by Google what will be the effects on a nominated trusted contact once their accounts become inactive.There are two impacts on trusted contact: (i) they will get a message from the account owner written at the time of the configuration setting; (ii) they will gain access to (some of) the data (only those with whom users decide to share their data).About the message (i), Google IAM tells users as part of the dialog in which they write the message that the email will be sent once the account becomes inactive (Fig. 5(b)).The "About Inactive Account Manager" help page reinforces that the trusted contact will not receive any notification at setup time, and shows an example of the footer Google will add to the message (Fig. 5(c)).However, there are no links from the configuration setting to this help page.About gaining access to data, when selecting the data to be shared with the trusted contact the user is informed that the trusted contact will have 3 months to download it (Fig. 5(a)), and that they will need the verification code to be sent to the cell phone registered by the user to access it.In the next dialog, in which users write the message, the user is told that additional information on how to download the data will be included in notification message (Fig. 5(b)).As mentioned, an example of what it might look like is shown at the "About Inactive Account Manager" page (Fig. 5(c)).However, the example message to be sent to trusted contact does not mention the verification code, nor the deadline for downloading the data.
Finally, regarding the impact of deleting their account, at the configuration setting interface Google IAM explains that all data associated with their account will be deleted, including publicly shared information.The help page notes that distinct Google products will be affected differently.It does not offer any explanation about how each one will be affected, nor where users may find that information.However, it does point out that if the Gmail account is deleted, users will no longer have access to their email and nor will they be able to reuse their Gmail username.The settings dialog informs users that the account will only be deleted once the user's requested actions have been completed.
Representation.The Google IAM configuration dialog does introduce new signs that are not present in the interface of Google applications.Although the interface widgets used to represent them are known to users (i.e.buttons, links, labels, etc.), new concepts are introduced, such as "timeout period" and "trusted contacts".In these cases, as described in the metacommunication reconstruction, the meanings of these signs are explained to users at the point at which they will need to make a decision about it.Most of the support offered to users to represent the anticipation effects of their settings is through explanations in natural language.The only exception is the footnote to be added to the user's message, for which an example of what it might look like is shown.The fact the designers used the word "might" may indicate that they are aware that an unknown period of time will pass between defining the settings and their effects taking place, and that the message could change during that period.It could also be because they may have chosen not to detail the whole message, but parts of it.As mentioned, no explanation about the verification code or how long the user has to take action is included in the example message.
One may argue that the use of explanation and an example depicted as a static sign are reasonable or good choices because the number of decisions and effects to be presented is small.However, the fact that the explanation is spread across different pages (as shown in Fig. 5), with little (or no) redundancy among them might make it difficult for users to gain a full understanding of these effects.

Cost x benefits.
In analyzing the cost of the Google IAM settings there are two stakeholders to consider: users and trusted contacts.On the user's side, there is the cost of changing the settings and anticipating its effects.On the trusted contact side, the cost is taking the action(s) requested by the user, for example verifying one's identity and downloading the data that was shared.The user only needs to make four decisions and take six steps to specify the future of his or her digital assets (i.e.change the settings).These settings can be also easily changed after being defined, and enabling or disabling IAM (once the settings have been defined) only requires one button press.The cost of understanding all the effects to their account and digital assets is a little more costly because it requires users to also visit the help pages about IAM, as well as making sense of information that is presented at different moments in different interfaces.
Users may also wish to anticipate the effects for the trusted contacts they have nominated.Although there is an example of the message with instructions that they might receive, the costs associated with downloading (time or storage space) are not mentioned.In the help page users are informed that they may see the data associated to their account in Google Dashboard.If users go to Google Dashboard there is information about each product (e.g.number of contacts; number of conversations in Gmail), but not about how much storage space the information takes.
Moreover, users may be interested in anticipating if they would be able to recover from any unintended effect and how, especially if their account became inactive and they want to reactivate it.Google IAM tells them that they will take precautions to prevent that through the "Alert Me".However, this situation is not explicitly considered in the interface or help.The only implicit references are: 1) if the account is deleted, there is no way to recover their username in Gmail; and 2) in the help page aimed at trusted contacts, one of the reasons listed for the contact not being able to download the data, is that the user signed back in and reset the countdown for the timeout period.Since the trusted contact only gets the instructions about downloading after the account is deemed inactive, it seems that even after it is "inactive" the user may log back in and reactivate it, unless the user has chosen to delete it, and that action has already been carried out.
For the trusted contact, there is no cost at the time in which the setting is being defined, because they are not informed of their nomination as a trusted contact.Any such cost would arise at the moment when the account becomes inactive and they are notified by Google of their status, and are required (if it is the case) to take actions to download the users' data.In this case, the main costs would be the storage space that may be required, but also recovering from any breakdowns that may take place in the process of downloading the data.The help page aimed at trusted contacts only explains what could cause the trusted contact not to be able to download the data, but not how to recover from such situations, which may imply that there is no possible recovery.
Finally, the emotional cost involved to users and trusted contacts should also be considered, given that account inactivity may be triggered by unhappy events such as an incapacitating health problem or even death.When users are making plans for their digital assets, they may consider these scenarios and especially when writing the message to each trusted contact (which is not optional 6 ).For the trusted contact, on their turn, there may be an emotional cost associated to being informed that they have been nominated a trusted contact and are now expected to be responsible at some level for the user's digital assets future, especially if they are caught by surprise.Also, there may be a cost associated to receiving the user's message, especially if some unfortunate fate has stricken the user.Finally, there might be an even higher cost if after receiving a notification they find out that due to some problem (e.g. a new cell number) they are not able to take the requested action.
Conflict negotiation and mitigation.In a configuration context such as Google IAM, potential conflicts could arise between user and his/her trusted contacts regarding trusted contact nomination, or among trusted contacts regarding a user's digital assets.Google IAM designers have left all potential conflicts out of the realm of Google.The decision not to give users the option to notify trusted contacts at the time they are nominated suppresses any conflict related to a contact's unwillingness to serve in this role.Trusted contacts are only notified once the account becomes inactive, and at that moment the user may no longer be available to negotiate, or at the least any such negotiation will take place outside of the system.
In the case that users are no longer available when their accounts become inactive, different trusted contacts might have differing views on what should be done with the assets.The designers also avoided this conflict by: (1) limiting trusted contacts to download (a copy of) the data; (2) by not telling trusted contacts if there are others, who they are or what access they have.
Users can grant access to their data, but it is up to them to decide if they want their data deleted or not; they cannot name a trusted contact to make decisions for them.It could make sense for a user to name a trusted contact to make that decision, but then different views from trusted contacts could arise in a dispute about the course of action to be taken.All trusted contacts granted access to data will have their own copy, so no conflicts regarding who is (or should be) responsible for which data will arise among them.If any conflicts should arise from the use trusted contacts choose to do with the data (e.g.make it available publicly) it will take place outside Google's responsibility.
Definition of default values.In the case of Google IAM there are not many decisions for which a default value is provided.First of all, setting Google IAM is an option, and by default it is disabled.Within the Google IAM design space the only defaults are: email for 6 Although we have not performed a systematic analysis of the new Google IAM configuration dialog, we have noticed that the message is now optional.notification which is set as the user's Gmail (this cannot be deleted, but others may be added), the timeout period that is set as the minimum (3 months) and the option to delete the account that is set to "No".
The default values set are not enough for users to enable their IAM, at least their cell phone must be provided and verification code entered.If users just enter this information and accept all the defaults there will not be a high cost to them, because it would mean that they would be notified before their account becomes inactive (i.e. if they do not interact with it for 3 months), but no one else would be notified, and the account would not be deleted.Also, if it becomes inactive, the implicit communication in the help pages implies that reactivating it would have a low costjust log into their account.

D. MoLICC for Google IAM
In our MoLICC analysis, we re-engineered the interaction diagrams that represent the account owner's, as well as the trusted contacts' interaction with Google IAM.The resulting interaction diagrams are depicted in Fig. 6 and Fig. 7, respectively.Fig. 6 shows that the interaction with the Inactive Account Manager starts by request of the user.The first scene (Manage Decisions) shows that the dialog7 between users and Google IAM is about users' cell phone number, the timeout period and delete option.Also, users may choose to "talk" about their trusted contacts, in which case the dialog involves informing their names, email, cell phone number, message to be sent to them, and data users want to share with them.
Once the user enables Google IAM, the black box represents the system's processing.The left transition indicates that as long as the user is active he/she may review their Google IAM decisions, including enabling (or disabling) it at any time.On the other hand, the right transition will only be possible once the user becomes inactive, as represented through the "precond" label, that means that the transition will only be performed if the precondition described is true.In our diagram, we included the precondition "precond: user inactive" to indicate that the message to the trusted contact will only be sent by the system (in the user's name) once the user is considered inactive.Thus, M1 represents the Outgoing Message Indicator, showing the message to be sent from users to their trusted contacts through the system, as well as the access to the data users have chosen to share with them.
The model for the trusted contacts' interaction with the system (Fig. 7) indicates that the initiative for interaction is taken by the system, but only if the owner of the account is inactive.The scene (Deliver Message) involves the system informing the trusted contact about the owner's message and its contents, the data that the owner has chosen to share with this trusted contact, as well as Google IAM's own instructions on how to proceed to download the data.Notice that the Incoming Message Indicator (IMI) also is dependent on the owner of the account being inactive.
The interaction models represented by both MoLICC diagrams show that the number of possible conversations between users (both account owner and trusted contact) and system is limited.One aspect that is important to notice is that there is no shared space between owners and their trusted contacts.In other words, there is no space within the system in which there is any interaction between owners and trusted contact.Moreover, the time in which owner-system interaction and trusted contact-system interaction take place is necessarily asynchronous and disjoint.Although MoLICC does not allow for explicit representation of temporal aspects, this separation in time has been described by associating the precondition that the owner must be inactive to some of the transitions.In the owner's interaction diagram only if he/she is inactive will his/her outgoing message be sent to the trusted contacts.On the trusted contacts' diagram, the interaction can only start once this precondition is true.
Even though the interaction between owners and system and trusted contacts and system do not take place in a common (virtual) space or time, it does not mean that they are independent.The owners' decisions represented through their interaction define the trusted contacts interaction.The owner's definition of who the trusted contacts are define who will be contacted by the system to interact with it.Also, the message written and decisions about the data to be shared by the owner regarding each trusted contact will be used by the system in the message to be composed to be sent to the trusted contact, as well as in giving access to download the data.Finally, the trusted contacts' cell phone number informed is essential, since it is the only access trusted contacts will have to the authentication code necessary to download the owner's data.Thus, the system intermediates the owner's asynchronous and unidirectional interaction with each trusted contact.Furthermore, by examining Fig. 7 it is clear that there is no interaction among an owner's trusted through the system.As mentioned before, each trusted contact is not even informed if there are other trusted contacts and who they may be.This can be noticed in Fig. 7, since there is no shared space among trusted contacts, nor any signs in the scenes that refer to other trusted contacts.
It worth noting that the MoLICC analysis of Google IAM does not add new information to the SIM+CIAC analysis of Google IAM.Nonetheless, it does provide an overview of the designers' meta-communication with users through the system, and also raises some relevant issues regarding future impact of account owner's decisions.In this sense, the combination of the two methods allows us to triangulate the results, consolidating the issues raised.In the next section, we present the main results that arise from the analyses performed.

VI. CONFIGURATION IN GOOGLE IAM
Google IAM configuration settings are aimed at supporting users' planning for the future of their assets.However, part of this planning involves establishing an asynchronous communication between owners and their trusted contacts, that is mediated by Google IAM.One of the plausible scenarios that could lead to the account becoming inactive is the death of the owner.In this situation, the communication will be asynchronous and unidirectional not only through the system, but also in the physical world.
For some of their decisions, Google IAM designers explicitly explain the rationale behind their decision (e.g.why they request a cell number for trusted contacts).However, they do not provide any reasons for not allowing users to choose (or not) to notify trusted contacts (at setting time); why users cannot empower trusted contacts to make (any) decisions on their behalf; or why trusted contacts are not made aware of other trusted contacts.Once again, the designers might be reinforcing the role of Google IAM as the mediator in defining the future of digital assets.It is also plausible that the goal to avoid any possibilities of conflict within the realm of Google's action played a role in these decisions.After all, one can easily imagine that some situations, especially ones concerning digital legacy, could end up in conflict and even involve legal repercussions in the physical world.For instance, suppose trusted contacts had to make a joint decision whether or not to delete the user's account or that one of them was responsible for making this decision and the others did not agree with it.Google is unlikely to want to be part of that conflict.
In the context of IAM, all configuration effects will take place in the future, so supporting users' anticipation of such effects is essential.As we have described, Google IAM provides such support through natural language and one partial example, depicting the footer but not the whole message that will appear in a notification (see Fig. 5(c)).Even if this solution is appropriate, Google IAM makes it harder by not presenting all the information in a single location.Furthermore, Google IAM does not support a process for users to explore the future effects of their configurations.There are a number of possible scenarios that are not (clearly) referenced to in the existing explanations.For instance, there is some indication that the user might be able to easily reactivate an inactive account that has not been deleted, but this scenario is not explicitly presented, and the bits of information that could lead to this conclusion are scattered through different pages.Other questions such as "Why is there a time limit for trusted contacts to download data, if the user has chosen not to delete it?";"If trusted contacts do not download it in this period, would they be able to get a second chance to do it?";"When users choose to delete account and have data shared publicly (e.g.YouTube), will people be informed of it and how?" Finally, one of the plausible and even expected scenarios of use for Google IAM is as a digital legacy planner.If this is the case, its use may evoke deep emotions for both users and trusted contacts.Users must think about their own deaths and wishes and which messages they would like their trusted contact to receive when they are gone.Later (up to 18 months), the trusted contact (or in this case the bereaved) will receive instructions written by someone they cared about.IAM minimizes dealing with any emotional aspects by omitting references to death and framing it in a broader context.Even within this approach, simple strategies such as allowing users to preview a message to a specific trusted contact could help them gain a better idea of how to frame their request.

VII. DISCUSSION
In this paper, our goal was to discuss communication issues related to configuration in collaborative systems over time.To do so, we chose Google IAM as a case study, since, although its configuration decision space offers a small set of options to the users, it involves relevant aspects that are not specific to the system or its domain.
Analyzing the different communicative acts between systems and users in regards to configuration decision space we can pose the issue as one of modality.When owners communicate to the system the configurations regarding future actions they are talking about a hypothetical situation (at least at the time of the configuration).Furthermore, if the configuration defines not only one interactive path, but a set of possible interactive paths that may depend on other users' actions and decisions [20][23], then owners are talking about a set of potential scenarios and possibilities.Thus, when making decisions about configuration settings users are talking in a subjunctive mood.
Once the future possibilities come into effect, the user-system interaction is in an indicative mood.In Google IAM, trusted contacts' conversation with the system represent the current state.In other words, they are talking about what actions are possible or necessary at that moment.
One of the challenges related to the users' communication in the subjunctive mood is to be able to anticipate all the possibilities that their discourse is enabling.Even in Google IAM that the number of changes in the possible discourses of trusted contacts is small, we raised the challenges that owners may have in understanding the impact of their decisions on trusted contacts' interaction with the system.In other words, during the owners' interaction with the system depicted in Fig. 6, they should be able have a clear understanding of the interaction that trusted contacts will eventually be able to have with the system, depicted in Fig. 7.
Therefore, it would be interesting to support users' exploration when planning the future possible scenarios that they are creating.Previous literature has shown that allowing users to visualize the future states resulting from their decisions and exploring them, either through a simulated environment [30] or by exploring the effects of different decisions or actions [20], would improve their understanding of the decisions.
Providing users with tools that allows them to explore future scenarios and ask "what if" questions regarding how different decisions could or would change different scenarios would clearly increase the cost of the system.Nonetheless, designers need to do a careful analysis of the costs and benefits associated to providing exploration tools to users.Although in some cases it could be desired, but not essential (e.g. as could be argued to be the case in Google IAM), as the design space for users' decisions increase, these tools may not only be desirable, but even necessary for decisionmaking.
In the case of Google IAM, users can name up to 10 trusted contacts, and may select which Google product's data they want to share with each of the trusted contacts.Although users may be able to keep track of what are the possible interactions each trusted contact may have with the system, and which data has been shared with whom, or whether the data of a specific product has been shared with any of the contacts, it may be costly to do so.However, if Google opted to allow users to define access to data not by the product it is associated to, but rather by use of finer criteria (such as the tags used to organize it), it might become a very difficult task without a tool that allowed them to anticipate and explore the future interactive paths and scenarios they were enabling.

VIII. CONCLUSION
In this paper, we investigated challenges associated to the configuration decision space of collaborative systems.To do so, we chose Google IAM as a case study, and analyzed it using SIM combined with the five Configurable Interaction Anticipation Challenges, as well as its interaction model represented using MoLICC.
The application of SIM+CIAC and MoLICC allowed us to perform a deep and thorough analysis of the design space Google IAM designers provide to users regarding their planning for the future of their digital assets.Based on the results for Google IAM we were able to raise and discuss issues regarding challenges related to anticipation and exploration of the future effects associated to decisions in the configuration space offered to users.Posing the issue of the configuration decisions and its effects as differences in modality of the user-system communication taking place, can be useful to understanding and investigating different support users may need to be able to be efficient in generating their discourses.
The communicability analysis of Google IAM analysis using SIM + CIAC and MoLICC generated interesting results and point to the usefulness of these methods in evaluating configurable collaborative systems that have impacts over time.Although we have not compared our analysis with comparable results of the applications of other evaluation methods, we can speculate that methods that focus on users' performance would likely miss most of the issues raised, because these issues would not be likely to affect users' success in completing the settings dialog (which as we have noted is quite simple).
Furthermore, the methodology used also provides interesting results about the applied methods themselves.The combination of SIM+CIAC provided a thorough account of designers' decisions regarding configuration decision space.This is an indication that the SIM+CIAC combination would also be useful in the analysis of other collaborative systems that offered users configuration with impacts over time.Furthermore, although CIAC was proposed for collaborative systems, some of the challenges might be relevant for interaction over time even for single-user systems, such as anticipation support.Thus, an investigation on its applicability to single-user systems that offered configuration over time would be interesting.
The MoLICC analysis allowed for an abstraction of the interaction possibilities in Google IAM that explicitly represented relevant aspects of the interaction, such as the unidirectional nature of the owner's communication to trusted contacts, as well as to their disjoint nature in time.As a side benefit, because MoLICC has been proposed only recently, the resulting interaction models for Google IAM offer evidence and examples about its applicability.In our case study, the example of a precondition for a transition used to represent temporal aspects and asynchronicity is an interesting starting point for a thorough investigation of MoLICC's ability and limitations to represent a variety of time and space interaction possibilities in collaborative systems.
Finally, the results obtained through the analysis of Google IAM indicate that both the challenges (CIAC) and MoLICC could also useful during the design of collaborative systems with configuration settings whose impact take place over time.While CIAC could lead designers to reflect about the challenges and on how to address them, MoLICC could lead designers to reflect about the different modalities in the communication, and what information and space was being shared through time by users.
As described in the introduction, and according to Pierce's scientific method [19], our results contribute to the abduction stage of research aimed at understanding the complexity of designing configurations that will have their impacts over time in collaborative systems.To consolidate the issues raised in this paper, the next steps in our research will be to analyze other collaborative systems that offer users configurations that have their impacts over time.Moving to the next stage of the scientific method, we would then shift to deduction, in which the consequences of the issues raised are generated.In this, direction, investigating what types of anticipation and exploration tools could be useful to support users in such systems would be a valuable contribution.A first step to begin this study could be to, once again, use Google IAM as a case study, exploring different solutions and possibilities for the issues identified in Google IAM, as well as discussing their costs and benefits.

Fig. 5 .
Fig. 5. Information effects scattered in (a) Dialog in which users choose what to share with trusted contact; (b) Dialog in which users write a message to trusted contact; (c) help page about inactive account message;