Social Feedback System Features

There are four main directions for exploring new social feedback system features: the visual design space for social feedback, mechanisms for sharing interaction history, mechanisms for broadening the display of traces, and finding new tightly-knit contacts.

8.2.1.1 Exploring the Visual Design Space for Social Feedback

The visual displays selected for the Dashboard and WebWear were based on identifying simple visualizations that met the basic information requirements for the particular situation and the learning goal. However, many other visual encodings for the information are possible. A systematic exploration of the design space of visual encodings seems appropriate for future research on social feedback. It could be that certain visual encodings simply do not work for conveying elements of behaviour, while others could improve the learning outcomes.

Further, because the deployments of both the Dashboard and WebWear were relatively short, temporal information was not needed for learning in the tasks. WebWear does encode the age of activity within the glyphs: as the activity becomes older the color of the glyphs begins to fade (see Figure 5.2). The Search Dashboard does not show change in behaviour over time, but it may be particularly useful for people to see how their behaviour has changed over time. Encoding such temporal information should be considered for longer term deployments of the systems.

8.2.1.2 Interaction History Sharing Mechanisms

As described in Chapter 6 (on the challenges of social feedback), privacy concerns are an important challenge facing social feedback systems. While I have shown that there exist current contexts where individually-identifiable interaction history can be appropriately shared with low levels of concern for privacy (in tightly-knit workgroups), there are technological approaches that may further reduce the overall level of concern. However, in exploring new mechanisms for

177

sharing interaction history a balance needs to be struck between the effort of managing the distribution and the perceived risks to privacy.

WebWear has two simple mechanisms for controlling the distribution of interaction history: collection can be stopped and started, and past interaction history can be permanently deleted. These two mechanisms are fairly simple, but seem to have been effective.

Further privacy-protection mechanisms could be explored, such as whitelists and blacklists for websites (e.g., I may be willing to share activity on Wikipedia, but keep all my YouTube activity private). Lists of people could also be used for directed sharing. Contacts could be organized into useful groups for sharing and might be combined with whitelists and blacklists of websites (e.g., I am willing to share my activity on Wikipedia with my colleagues because it is most often related to work, but I am only willing to share my activity on YouTube with my wife because she won’t judge me by my viewing habits). Similar approaches exist in social

networking services, such as Google+17, for the explicit sharing of information. However, such a solution introduces a substantial cost: the need to define and maintain the group lists which represent who would receive interaction history and when they might receive it. In recognition of such overhead, research has proposed semi-automated systems to facilitate the identification of relevant contacts for sharing information [6].

Another interesting privacy-protection mechanism is providing complete control of interaction history, including its storage, on a user’s computer. In both WebWear and the Search Dashboard, interaction history is stored on a remote server. This means that the data is ultimately out of the control of a system user. Recently there has been an effort to provide general purpose information storage platforms that allow data, such as interaction history, to be stored on the user’s computer, and for which the user can control distribution by granting access to individual applications and people [152].

8.2.1.3 Mechanisms for Appropriately Broadening the Display of Traces

WebWear broadens the situations where interaction history can be encountered by displaying interaction history describing website-level activity and not just activity on particular webpages (see Section 5.1.4). Providing website-level support allows social feedback to be available in more situations, because a single website may contain many pages that have been

178

interacted with. Websites were selected as the means by which to broaden support because it is a simple means that can keep the activity displayed relevant to a particular task (since entire tasks are often completed on a single website). However, as discussed in the report on the field trial (see Section 7.4.1.1), there were instances in which this simple approach was too broad. Different mechanisms that allow the appropriate broadening of displayed traces should be investigated.

One approach to this problem would be to create a list of websites where the current website-based approach is appropriate. For example, in the field trial we found that sharing activities in this way was not particularly useful for google.ca (because too many different tasks are completed through searching Google), but it was appropriate for stackoverflow.com

(information seeking on this website was always for programming help). Other approaches for narrowing the activity of websites could be explored such as using subdomains to restrict the activity (e.g., activities on google.ca could be narrowed by using sub-domains, such as news.google.ca or maps.google.ca).

Further, semi-automated approaches could be explored that would attempt to identify and display only activities that are associated with the task. This would require some overhead for a user to confirm that activity is indeed associated with a particular task. However, it would

provide the further advantage that people could explore all activities associated with a completed task.

8.2.1.4 Finding New Tightly-Knit Contacts

The studies showed that an essential part of the success of future social feedback systems for local learning will be due to the properties of tightly-knit groups. However, there were likely other opportunities where the WebWear field-trial participants could have used some guidance, but none was available. Future work should consider how social feedback systems could address can appropriately maximize the size of tightly-knit groups to increase availability of support. While automated approaches may be considered – for example, by providing the traces of some unknown person who had the exact same task at some point in the past – this seems a

challenging problem for the short term. Another way that could be explored is through

encouraging people to expand the basis of what they would consider to be tightly-knit through recommendations of people who share similarities or who have tightly-knit contacts in common. Because trust is such a central property within tightly-knit groups, the system would likely have

179

to provide important details that would allow a user to decide if they can or should trust a potential new contact. Exploring the ways that tightly-knit groups could be grown could be a fruitful direction; a WebWear user with a larger set of contacts would have a higher likelihood of receiving support when it was needed, by having the knowledge and experience of more people available.