Designing A Social Portal Tim Mansfield, Nigel Ward, Gregor McEwan, Jos´e Siqueira, Anthony Wilkinson Information Ecology Project CRC for Enterprise Distributed Systems Technology University of Technology Sydney and Monash University http://www.dstc.edu.au
[email protected],
[email protected] The Information Ecology project is constructing a Social Portal. This article explains what we mean by a Social Portal, what user needs we believe we are serving by building one, what research goals we think we are serving and how we intend to go about it.
it should be more effective than existing solutions
Keywords information retrieval, social navigation, recommender systems
These criteria led us to the notion of a “social portal”. Section 2 defines this notion. Section 3 describes how this relates to user needs and how it improves on prior solutions. Section 6 describes the design of the system and the field tests. Section 7 outlines the research we want to conduct when we have an appropriate user community.
1 Introduction The Information Ecology project at DSTC is an interdisciplinary programme investigating how to improve the interconnectedness of the online experience. One of our goals is to enable software to better exploit the broad context (both within the computing environment and beyond it) of the execution of a user command. We intend to investigate ways in which software can appear more integrated with it environment by exploiting context more effectively. Several kinds of context are initially appealing and this paper describes initial work in studying one kind: the patterns in people’s social interaction with each other. The complexity of studying human interaction is great enough to have spawned several entire academic disciplines[1], so we have attempted to narrow our scope. We are interested specifically in what can be done with information about the people with whom our user communicates electronically. Our initial approach is to gather that information by providing an application which supports communication with a list of contacts and use that as a way to capture information. Based on this data we want to answer several research questions that are outlined in Section 7. For this to be useful as a research tool, we need an application which people will use for a significant proportion of their communication, therefore:
it should serve a known need Proceedings of the Fourth Australasian Document Computing Symposium, Coffs Harbour, Australia, 7 December, 2001
it should be primarily web-based to minimise the barriers to adoption.
2 What Is A Social Portal? Portal sites such as MyYahoo!1 or Lycos2 or MyNetscape3 attempt to pull all information of interest to the user together in one place. This information is usually organised as channels of information on some topic. Users can typically personalise the channels they see in a portal. For example, users can choose to see channels from newswire services such as Reuters4 alongside stock portfolio channels, TV listing channels, horoscopes, weather, and so on. By putting all information of interest in one place, these sites serve the user by providing a convenient starting place for accessing information of interest and keeping up to date with that information. Although portal sites claim to put everything the user is interested in together in one place, in fact many interesting sources of information are omitted. Portals may include newswire news, but they rarely put these next to a channel about your sister’s family news or a channel containing discussion of your company’s new strategic direction. We are building the Social Portal to investigate portal-style presentation of information from so1 http://my.yahoo.com 2 http://www.lycos.com 3 http://my.netscape.com 4 http://www.reuters.com
cial networks. Rather than solely relying on general channels that may meet the user’s information needs, we are building a system (described in Section 6) that also uses social context to recommend information. We wish to be clear that we are discussing an evolving, web-based prototype. The initial version simply focussed on sending channels of messages to social contacts. It also included a simple interface for personalising your view of received channels. Later versions will include access to traditional portal information sources.
3 How Do Portals Serve the User? Portals provide customisable interfaces for displaying multiple channels of information items on some topic. Users are given control over which channels they see and can customise how they see those channels. Portals often provide a large number of fixed channels for the user to choose from. The sources of items in these channels range from newswire services such as Reuters, other portals, automated information feeds such as stock price reports, individual authors (newspaper column style), or professional editors collecting information of interest. Portals attempt to pull all information of interest to the user together in one place. The popularity of portal sites suggest that having even some of the user’s information streams in the one place serves the user well. Portals give the user a convenient starting place for accessing information of interest and provide a convenient way to keep up to date with that information. A less obvious advantage of the in one place approach is that such systems can understand the user better. Recommender systems[3] are portal-like tools which recommend information to the user based on their understanding of the user’s information interests. This understanding is built up by observing the information the user manipulates. If users access all of their information through the one place, these systems can make better observations and hence more targeted recommendations.
4 A Critique of Portals Portal channels serve the whole channel audience. Decisions about what items are recommended to the channels are made based on a profile of the channel audience. The channels serve the group rather than the individual. This results in the recommendations within a channel being high-level, broad information that does not always target well to any individual within the channel audience. Horizontal portals, also called mass-market or broadcast portals, such as Yahoo! or MyNetscape
particularly suffer from this targeting problem. They provide channels of broad interest to large demographics (such as newswire services). Vertical portals or community portals address the targeting problem by providing access to fewer channels on a particular topic or targeted to a particular audience. For example, Redherring.com is an online portal companion to Red Herring magazine, providing information and discussion on technology business. Although vertical portals have more targeted channels, they still rely on a broad understanding of an audience and so do not always contain exactly the information and only the information of interest to a user. Enterprise portals are portals that operate within an organisation. They address the targeting problem with channels containing information drawn from within the organisation. They can provide access to more targeted information such as corporate calendars, internal memos, and even personal information sources such as email and personal schedules. Enterprise portals only contain organisationally accredited information. They tend to reflect a static view of the organisation. There is no support for information exchange between individuals or groups that have no official existence. Fundamentally, the shortcomings of existing portals arise from the portal having limited knowledge of the individuals that they serve. The only knowledge of the users is from generalisations of the demographics, whether it be an editor or author’s understanding, or a machine’s statistical understanding of the audience.
5 Adding Social Information The portals that we have investigated have limited representation of information sources. An important source of information that we feel is neglected by current portals is the people you know. Users already receive information of interest via their social relationships. Informal observation suggests that this is via email, either personally or on group mailing lists, via instant messaging systems such as ICQ5 or Yahoo! Messenger6 , via discussion fora such as Usenet News or Topica7 , and occasionally via references to web pages which may contain news, writing, pictures and links to sites the author thinks are interesting. Sharing information, particularly digital information like text, digital pictures and web links, is a process particularly amenable to digital media 5 http://www.icq.com 6 http://messenger.yahoo.com/ 7 http://www.topica.com
streams such as these. One main issue for the receiver is that it is difficult to see all of this information in one place. Although many portals support access to email, discussion fora and messaging systems, they do not provide a unified view of these media streams. Users must move into different sections of the portal to see these different media streams. The prototype we are building will eventually let the user see much more information of interest in one place, including information from social contacts.
Each receiver had a page consisting of all the channels they had been sent. They had the means to rearrange the order of the channels in a twocolumn layout.
6.2 Initial Field Test Conduct We used ourselves as beta testers to iron out some of the obvious bugs, but tried to restrain ourselves from adding features we wanted. Once the system seemed able to withstand normal use we set about organising the field test. 6.2.1 Deployment
6 Design Approach Our design approach is both synthetic and usercentred. Synthetic, because we designed the initial version of the Social Portal by immersing ourselves in as many existing web applications as we could. The design that resulted is a synthesis of functions that we had seen in various systems that fill a gap that we perceived. Our approach needs to be user-centred because we are grounding our research activities in data obtained from real social networks. The system has to capture a large amount of social network information to provide the necessary data. Therefore, it needs to be an application that a lot of people will use regularly. We sought an initial, plausible design and worked toward producing a viable implementation which we could field test. This section outlines both that initial, plausible design and the conduct of the first field test.
6.1 Initial Implementation Design The initial system was based on the common portal metaphor of an online newspaper. Rather than receiving news items from a wire service like Reuters in this newspaper, users would receive recommendations of web pages from other users. Like many online newspapers, the Social Portal organises items into channels, one channel for each topic contributed by a given user. The reverse-side of this design is that each user can make up channels about topics they would typically share and send recommendations to friends or colleagues using these channels. So, the initial version was based on these two basic notions: recommendations and channels. Recommendations had a title, a URL (for the thing being recommended), a description and a sender and date. Channels are a conduit from their sender to a group of receivers. Each channel associates a set of recommendations on a common topic (in the opinion of the sender) with a set of receivers.
We designed the system with a “viral” model of promotion. Whenever a recommendation was sent to someone who was not a registered user, that person would be sent an email inviting them to register. We extended this virus metaphor, so that new users had to be invited before they could register. We were interested in how far the system would spread within a community if we released to a small sub-group within that community. We targeted a group of 10 users within our own organisation, across several different groups within the organisation. The initial group consisted of several research staff, one administration worker, two marketing staff and a number of programmers. We conducted no user training unless users contacted us with difficulties in which case we tried to help, usually over a telephone. To help users understand the system we added some basic help files and a bug entry form. We also used a Wiki, a web site that anyone can modify, to allow users to submit feature requests. Finally, we created two standard channels for “help”, and “announcements” and provided them to every user. 6.2.2 Data Gathering We gathered data in three forms: 1. system logs - The system logs every action the user takes in the system (users gave consent to this before registering), 2. system feedback - the feature request Wiki and the bug tracking system collect some concerns that users felt strongly about, 3. semi-structured interviews - we conducted face-to-face and phone interviews with six users after they had been using the system for two weeks
6.2.3 Results
7 Future Work
In this initial field test, we were effectively conducting an acceptance test: was the system adequate to support the user group’s information sharing needs? Could it form the basis of a popular system we could use to collect the data that we need? Consequently, we mostly used the system logs to examine how often users used the system and how many registered to use the system. The results of that examination appeared to be that initially the system enjoyed a brief burst of popularity, there were a lot of registrations and a large proportion of the users logging in daily. Interest soon waned and use of the system became very irregular, with only one or two users logging in each day. We took this to mean that the system essentially failed the acceptance test. Examination of the system feedback and the design of the interviews were aimed at discovering why. Many comments from users concerned usability improvements: more effective ways to layout and manipulate the channels page, better conceptual structure for pages, clearer layout and language for less frequently used functions. Some users requested the ability to send recommendations to ad hoc groups without defining a channel first. But the most striking theme in the user feedback was the desire to have more communication with other users. Users wanted to give written and ratings feedback, find new users to communicate with and share channels as a forum instead of a broadcast.
The long term goals of the Information Ecology project are to study how broad context can be used to improve a person’s information experience. The research and development reported in this paper is aimed at capturing and using social context to this end. The prototype is being developed to be a popular application that supports and uses social networks. Once we believe, based on our user feedback, that we have developed such an application we intend to instrument the tool to gather data on how, when, and to whom people make recommendations using the portal. Based on this data we intend to investigate a number of research questions, including:
6.3 Summary
7.1 Acknowledgements
In reflecting on the feedback from that initial field test we decided that the fundamental design of the first implementation contained serious errors, so we set to redesigning it. Rather than attempting a complete redesign and redeployment, we chose to keep the system in service and roll the new design in piecemeal. In this way, we maintain contact with our small but enthusiastic user community and continue to gather feedback as we adapt the system. We use this continuous engagement as a discipline to maintain a focus on the users’ needs. Once we believe, based on our feedback, that the users in this initial group are served adequately by the system we intend to extend our field-testing to new user communities and continue gathering feedback.
The work reported in this paper has been funded in part by the Co-operative Research Centre for Enterprise Distributed Systems Technology (DSTC) through the Australian Federal Government’s CRC Programme (Department of Industry, Science & Resources).
Portals attempt to provide the user with a unified view of all information of interest in the one place. Is it possible to provide a unified view of socially recommended information alongside traditional portal channels? What other sorts of information can be effectively viewed in a portal channel model? Can we use the system’s understanding of social networks to improve the information seen in the portal? That is, can social context be used to improve recommender systems[3]? Can recommender systems be used to improve social context or cohesion? How do social networks change over time? How do they relate to other collections of people, such as organisational units or online communities[2].
References [1] S. Greenberg. Computer supported cooperative work and groupware. Academic Press, London, 1991. [2] R. McArthur and P. Bruza. The abc’s of online community. In Proceedings of First Asia Pacific Conference on Web Intelligence, Lecture Notes in AI, Pittsburgh, PA, 2001. Springer-Verlag. to appear. [3] P. Resnick and H. R. Varian. Recommender systems. Communications of the ACM, Number Vol 40, No. 3, March 1997.
