About

buddyspace logo colour


BuddySpace was an innovative instant messaging platform built on Jabber, offering unique features like geographical maps, cross-platform support via Java, and open-source availability. It aimed to enhance collaborative work by providing enriched presence management, allowing users to visualise colleague availability in real-time through customisable dashboards. BuddySpace addressed the limitations of traditional IM tools, focusing on more than just messaging by incorporating spatial and contextual data for presence awareness. The platform emphasised scalability, interoperability, and user preferences, making it versatile for various professional and collaborative contexts.

screenshot of buddyspace map

Research Issues

The research explored the semantics of presence in collaborative technologies and massively multiplayer games. It focused on developing richer presence indicators based on users’ work intentions, moving beyond traditional status indicators like “online” or “away.” The CoAKTinG project aimed to improve presence management tools by using semantic filters for intelligent matchmaking in collaborative environments. In multiplayer games, the study investigated how player presence can shape gameplay, particularly in large-scale environments, where the number of participants impacts the gaming experience and design.

People

Project principal investigator:
Marc Eisenstadt

Chief presence architect, authentication, directory access & cool server stuff:
Martin Dzbor

Lead programmer, client architecture & implementation:
Jiri Komzak

Automatic roster & server hooks:
Adam Sporka

Client and website graphic design:
Harriett Cornish

BuddySpace website:
Damian Dadswell

World maps, cartography:
Ray Munns, Open University Learning and Teaching Services

Massive presence-based games:
Yanna Vogiazou

Publications

Vogiazou, I.T., Dzbor, M., Komzak, J. and Eisenstadt, M. “BuddySpace: Large-Scale Presence for Communities at Work at Play”Submitted to Inhabiting Virtual Places, Workshop at E-CSCW-03), September, 2003, Helsinki, Finland.

Eisenstadt, M., Komzak, J. and Dzbor, M. “Instant messaging + maps = powerful collaboration tools for distance learning” Proceedings of TelEduc03, May 19-21, 2003, Havana, Cuba.
Watch webcast replay of similar presentation, 8 minutes.

Buckingham Shum, S., De Roure, D., Eisenstadt, M., Shadbolt, N. and Tate, A. “CoAKTinG: Collaborative Advanced Knowledge Technologies in the Grid.” Proceedings of the Second Workshop on Advanced Collaborative Environments, Eleventh IEEE Int. Symposium on High Performance Distributed Computing (HPDC-11), July 24-26, 2002, Edinburgh, Scotland. [HTML format, PDF format, MS Word format – original].

“BuddySpace: Enhanced Presence Management for Collaborative Learning, Working, Gaming and Beyond”
(Paper from JabberConf Europe, Munich Germany, June 2002).

“From Buddy Lists to Buddy Space: Enhanced Presence Management for Collaboration, Learning and Gaming” (Presentation at Pulver.com Voice On The Net / Presence and Interworking Mobility Summit (VON/PIM Europe), Helsinki, Finland, June 10-13, 2002).

Sponsors and Thanks

Since February 1, 2004, BuddySpace was funded by the EU’s Sixth Framework Programme under the ELeGI project for technology-enhanced learning. Earlier funding, crucial for its creation, came from the UK Engineering and Physical Sciences Research Council through the Advanced Knowledge Technologies (AKT) project. Contributions from Jabber.com, Inc., and Jeremie Miller were also included, alongside software from L2FProd.com.

Information from the resource website

Introduction & philosophy: presence in a nutshell

BuddySpace is an instant messenger with four novel twists: (1) it allows optional maps for geographical & office-plan visualizations in addition to standard ‘buddy lists’; (2) it is built on open source Jabber, which makes it interoperable with ICQ, MSN, Yahoo and others; (3) it is implemented in Java, so it is cross-platform; (4) it is built by a UK research lab, so it is 100% free with full sources readiily available. But BuddySpace is about more than just ‘messaging’, as we explain below.

One of the key factors that led to the widespread popularity of Instant Messaging applications from 1997 onwards (including ICQ, AOL, Yahoo!, MSN, Odigo, and Jabber messengers) was the concept of pushed presence: the automatic notification of the appearance of friends and colleagues online. However, Instant Messaging (IM) is just one of many possible presence-related and presence-dependent applications. For example, presence-enabled applications can facilitate safety-tracking of children by mobile phone, support for emergency services, blind-date radar, group teleconference management, multiplayer games, and anything involving the collaboration of individuals separated in space and time. Why phone a contact only to receive an engaged tone or pre-recorded message, when the telephone network already knows what state your contact is in, and could indicate this directly on your contact list? All of these concepts embody varying degrees of what we refer to as enhanced presence management.

The concept of presence has matured in recent years to move away from the simple notion of ‘online/offline/away’, towards a rich blend of attributes that can be used to characterise an individual’s physical and/or spatial location, work trajectory, time frame of reference, mental mood, goals, and even intentions! Our challenge is how best to characterise presence, how to make it easy to manage and easy to visualise, and how to remain consistent with the user’s own expectations, work habits, and existing patterns of Instant Messaging and other communication tool usage.

What Problem Does BuddySpace Address?

  • Collaborative knowledge work often relies on opportunistic interactions; for remote collaborators, such interactions need to be kept simple, meaningful, relevant, and manageable.
  • Popular Instant Messaging tools (ICQ, AIM, MSN, Yahoo!) are effective in their niche but fail to address meaningful knowledge exchange and coherent workgroup practice, e.g. the ability quickly to find the right source of key knowledge according to stored interest and geographical profiles.
  • Knowledge workers are largely unfamiliar with (or even uncomfortable with) the unique opportunities afforded by high-impact, low-effort, low-bandwidth, large-scale communication capabilities.
  • Presence awareness requires more than knowing ‘online/offline/away/busy’ status: some grounding in geographical reality and an enriched presence-signalling capability could pay huge dividends.
  • Collaborative knowledge work of course involves people-people interaction, but there is more: knowing the status of devices, locations, and documents can be just as important.

Towards a solution

BuddySpace aims to provide enhanced capabilities for users to manage and visualise the presence of colleagues and friends in collaborative working, gaming, messaging, and other contexts. Of particular interest is the role of graphical metaphors for presence, including maps, logical layouts such as building schematics and project timelines and abstract artistic layouts such as graffiti walls. We are also studying the semantics of presence, in order to move beyond simple flags such as ‘online’ and ‘busy’ to include rich contextual and spatio-temporal information more approprite to one’s focus of activity. The snapshots below (click to enlarge), and the brief overview which follows, highlight our approach.

BuddySpace generalizes the concept of ‘Buddy List’ (popularised by Instant Messaging tools such as AOL Instant Messenger, ICQ, MSN Messenger, and Yahoo Messenger) to provide multiple views of collaborative workgroups according to users’ needs and tastes. Our aim has been to provide a personal ‘dashboard’ or ‘radar screen’ so that one can observe the availability and ‘interaction state’ of colleagues worldwide in a manner that exhibits the following desirable properties:

  • Immediate: real-time updates need to be pushed instantly to users rather than pulled in by request — the push approach helps keep updates more palpable and informative
  • Peripheral and therefore non-intrusive: users lead busy lives, and dislike being bombarded with yet more information, so we aim to keep awareness of colleagues available in a compact manner that can be noticed peripherally
  • Customisable: some people prefer simple or hierarchical lists, some prefer visual maps, some prefer status lights, and so on; some prefer a ‘Windows’ look-and-feel, some a ‘Mac’– we need to cater for diverse user preferences and capabilities
  • Scaleable: we have to provide ways to indicate the presence of potentially enormous numbers of people, even given that these numbers will be filtered down for personal use — researchers inhabit workspaces with many hundreds of colleagues around the globe; the Open University has well over 150,000 students online; large peer-spaces like music swapping communities have many millions of users connected simultaneously
  • Interoperable: with several hundred million users of the ‘Big Four’ (AIM/ICQ/MSN/Yahoo!), it is crucial that any approach allow interopebility with systems to which our users already subscribe; this is one of the many reasons we built BuddySpace entirely on top of Jabber (www.jabber.org), which provides gateways to the ‘Big Four’ products.
  • Cross-platform: we need to service a community not only on Windows, Unix/Linux, and Mac desktop and notebook configurations, but also on PDAs and mobile phones — we therefore develop entirely in Java
  • XML-literate: for future intelligent applications, communication transport needs to be about more than just string-transmission; another we adopted Jabber is that it is based entirely on a generic XML transport architecture, ideally suited for this purpose.
  • Open source: for the research community to join us and to gain leverage via our research output, we have ensured that BuddySpace is open source, available on SourceForge.
  • Clean: BuddySpace adheres rigorously to the Jabber specification, which means that it interoperates with other Jabber clients and servers without danger of the rogue behaviour that non-standard implementations inadvertently allow (e.g. the semantics of users inhabiting multiple groups is undefined in some clients, and can cause crashes).
  • Extendable: BuddySpace deploys a plug-in architecture which means that additions, such as new visualizations, and new concepts such as gaming interfaces, are readily achievable

BuddySpace fulfills all the above criteria, and provides a compelling user interface that can be highly compact, yet provide users with an important ‘feel-good’ factor, akin to seeing nearby office lights turned on when entering one’s office building at night. By studying the semantics of presence, we can also augment the existing impoverished presence states in a principles manner, providing capabilities that are more representative of the way real users work. Forthcoming capabilities will include automatic location updates via mobile devices, and the use of semantic matchmaking via intelligent profile handling, in order to help users quickly find and filter colleagues of particular interest.

Research Issues

Presence and Semantics

In addition to the appearance and ease-of-use of the presence management tools, the actual meaning of a person’s presence status is a topic of great interest. As part of our ongoing knowledge modelling work within the UK EPSRC-funded Advanced Knowledge Technologies project, we are beginning to develop richer presence representations that reflect user’s work intentions. For the specific sub-project known as CoAKTinG: Collaborative Advanced Knowledge Technolgies in the Grid, we intend to augment the prototype BuddySpace with semantic visual filters that customise the display of presence information to yield participants of interest at the right moment (e.g. those working on work-package X, or interested in ontology Y). The difference from earlier work, such as the dynamic sliders of Shneiderman, or even the powerful group filtering of IM products such as Odigo, is that the users will be asked to subscribe to a community of discourse, which includes an underlying ontology of areas of communal research interest and concepts such as project timescales and work plans, thereby enabling a degree of intelligent match-making even when users do not choose identical keywords (as is now required in the IM world). Key research questions in this realm are as follows:

  • Automatic filtering
    How much in the way of automatic roster construction and group visualisation can be provided ‘hands-free’, i.e. without significant end-user investment?
  • Semantics of match-making
    What do we need to store about the research interests of colleagues in order to indicate their simultaneous presence?
  • Presence semantics and dynamics
    Indicators such as ‘online’, ‘away’, ‘busy’ and ‘offline’ are proving to be much less useful than more advanced status indicators such ‘now working on work-package X’, and we need to develop a richer presence vocabulary to reflect this. What should this vocabulary look like?

Presence in Massively Multiplayer Games

The aim of this aspect of our work is to focus on the notion of presence of other players in massively multiplayer games and investigate the potential of a game based purely on presence information. We are particularly interested in the issues that arise when designing a game for a multi-user experience. In particular we note that a very large number of participants can sometimes be disadvantageous for the game experience and complicate the design process. In most games we notice a limit either in the number of people that can take part, or in the number of people that can interact synchronously or see each other during game play.

For example, in massively multiplayer games like Ultima Online and Asheron’s Call the player’s view is limited by an artificial horizon in the radar visualization: this conveniently narrows the immediate scope of events requiring urgent attention, but restricts the ‘total immersion’ effect that might otherwise be possible to achieve. This work attempts to explore the idea of a game where the very presence of a large number of people could not only be advantageous for the game itself, but actually form the fundamental premise of its play. The work is in an early state, and an indication of its progress is described in Yanna Vogiazou’s Directory of Work on Massively MultiPlayer Presence which drawing on links from the worlds of games, mobiles, instant messaging, and telepresence.

BuddySpace Release Version Notes

  • 2.8, May, 2007: Adjusted to provide more complete support Wildfire Jabber server.
    Default configuration options changed to msg.open.ac.uk server.
    Fixed bug causing program to hang when reconnecting after connection break.
  • 2.7, April, 2006: FlashMeeting Button added to allow instant launch of video conference from one-to-one and group chat windows.
  • 2.6, November, 2005: ‘Pro’ label dropped, as all versions unified in one place. BuddyFinder plugin added to support user searches based on personal profile information. SimLink plugin added to allow yoked control of SimLink’s ‘hot-plugin’ modules within groupchat.
  • 2.5.2pro, July, 2004: groupchat made MUC compatible after removal of jabber:iq:conference protocol pieces; in message compose window and invitation into chatroom added option to choose just on-line contacts as recipients; fixed problem with debug window.
  • 2.5.1pro-r2, March, 2004: fixed a problem with internal authentication
  • 2.5.1pro, February, 2004: SSL support, password encryption, correct interactions with newer Jabber2 servers, made Jabber IDs non-case-sensitive, added all the “2.5.0pro” features, such as server-published maps (previously available only to Open University + research partners) to public release
  • 2.5.0pro, December, 2003: server-published maps [so you get informed when, say, your group map is updated, and the new one can be auto-installed]; multiple presence: appear as ‘do not disturb’ for the whole world, but ‘away’ for Group 1, and ‘free to chat’ for Group 2; ‘invisible’ presence; plans: like the old unix .plan files, specify a small bit of text saying what you’re up to, so users can click on it and see; service discovery: for advanced Jabber capabilities which don’t yet exist!;
  • 2.5.0, December, 2003: ability to specify own nickname in response to groupchat invite; test login – automatically tries to create new account when login failed; reply indicator – message events: displays ‘Typing…’animation when your buddy is composing a reply (works across Yahoo and MSN too); names for cluster nodes in maps;
  • 2.4, November, 2003: auto-away upon Windows screensaver (option); remembers position and open windows, so next time you connect you get your favourite layout; displays progress of fine-grained login internal states; email-style messages can optionally appear in chat windows instead; reply message sets subject line and quotes original “re:subject” + “> original”; roster refresh fix; app/webLoader fix for Win9x; delete button and better deleting in messages window; shrink to system tray icon (Windows only);
  • 2.3, October, 2003: multiple invitation into groupchat room to bring in entire groups; full installer bundle updated to contain a newer version of JRE (1.4.1_05); stability fix – disconnecting is now more robust;
  • 2.2, June, 2003: added Bookmarks capability; clearer login screen; ability to send clickable URL’s in chat; minor bug fixes;
  • 2.1.1, late February, 2003: 1-click .exe and .sit installers and launchers for Windows and Mac; ‘Save values’ option on login screen; ‘Create/join conference’ renamed to ‘Groupchat’; New groupchat ‘wanna talk’ and better voting indicators; optional text ‘announce presence changes’ in groupchat; optional ‘chat-style alerts’ in groupchat; full emoticon set selectable in chat windows; Quick-toggle compact/full view on toolbar; toolbar no longer tears off’; ‘auto-popup message’ option only on preferences/alerts tab rather than also in View menu; easier Yahoo/MSN/ICQ registration via ‘Browse services’ menu; minor bug fixes;
  • 2.1.0.0, 9th January, 2003: Auto-login, auto-hide console window, audio alerts, power-user ‘compact mode’, BuddyBar ‘radar’ status lights, tear-off toolbar, multi-tabbed preferences window, ‘browse Jabber services’ capability, conference-room voting, ‘attention’ slider, and countdown timer, new ‘online but physically elsewhere’ and ‘low attention’ presence indicatoraturs, group broadcast, map editor, plus all most-requested features.
  • 2.0.4.4, 16th October, 2002: Roster sorted alphabetically; ‘View… Scroll tabs’ option greyed-out for JRE 1.3 users, as it is a JRE 1.4-specific feature; cluster dots rotated; custom group roster icons; transparent GIF images; config file stored for general (non-OU) users.
  • 2.0.4.3, 15th October 2002: totally reimplemented cross-platform Java version, with numerous improvements to the original (and now withdrawn) ‘BuddySpace 0.95’ Windows-only C implementation. Improvements include: 100% Java, modular component architecture including plugin and ‘skins’ capability, full roster and conference room capability, foreign transports (e.g. MSN, Yahoo!, ICQ), file and map transfer between clients, embeddable user maps including ‘clusters’ where you can ‘drill down’ to see who is online.

Click here for sources (SourceForge.net).