GrowingPains

Portals as Community Hubs

The main project I have been working on since last September is as the leader of the implementation of the student web portal of Tilburg University. It is interesting to be back here, this time in a very different role. Whereas as a student and scientist I was always thinking analytically about information systems development, I am now in the trenches trying to make these systems actually work, a very different ball game!

The original project assignment was quite a different one from the current mission. The initial idea was to build and deliver a portal consisting of a number of predefined portlets (channels to applications). These included portlets like My Week Schedule, My Exam Schedule, University News, Webmail, and so on. Through the portal, these applications are to be accessed from a single location, with a single sign on. The list was compiled by a committee in a preceding project, based on student surveys and a thorough analysis of goals and available resources.

Although such a well thought-through list is a prerequisite for a successful portal, it is not a sufficient condition. Rather than being a frozen technical system, a portal is a living socio-technical system.  It is a catalyst for the building of relations between people, applications, and business processes. Much more than a static, hierarchical model, a lateral, evolutionary model should guide the development of a portal. A portal is never finished, but needs to continuously grow in requirements and functionalities, driven by the real needs of the end users, in this case, students, while being constrained by technical and organizational realities.

Having been fully immersed in this process for half a year now, and still to go on for half a year more, it is surprising how much time and effort is needed not only in building technology, but in identifying stakeholders and aligning their needs, preferences, and interests. Not only students, but also the technologists and the owners of the applications and information resources to which the portal links need to have their say. Legitimacy is therefore all-important, as every decision can affect the ways of working of so many in the organization. In fact, the portal project is all about building for a community with a community. More about how we approach this from a community perspective in a later post.

It Takes at Least Two Tools to Tango

Quite a while ago, I mentioned that communities need less tools, more process. Community interaction processes tend to be very complex, leading to context-specific requirements which often cannot be met completely by any particular tool. Vice versa, many tools are often used for a very different purpose than what they were originally designed for.

I recently experienced a wonderful example of how relatively straightforward tools can be combined into "distributed applications" to provide very useful functionality. I am one of the three co-chairs of the First International Pragmatic Web Conference (see the Patterns for the Pragmatic Web-entry on this blog for an explanation of what the Pragmatic Web is about). Since we live and work far apart, we tried to write the Call for Papers by sending Word-files around. However, as it is such a new paradigm, confusion abounded and versions kept flying back and forth between the three of us. It was clear that just using e-mail + Word processors did not fit our collaborative needs.

We decided that, additionally, we needed voice contact. However, the phone would not do, since the three of us needed to discuss simultaneously. Phone conferences are still relatively expensive, so we decided to use Skype instead. This voice-over-Internet application allows up to five people to discuss for free. Additional benefits are that the sound quality is much better than that of the phone, and that one can talk using a microphone. This means that one's hands are free and one can type while talking.

Okay, so now we could talk, but we were still not there yet. We were considering three versions of the document: one previously written by one chair, one by another chair, and the third one the version-in-progress which contained the modifications that we were making as we spoke. This was too much, the poor mind's eye was getting very confused by all those almost-but-not-quite similar texts. Instead, we came up with the following solution:

 

• All of us opened one of the  previous versions in Word for reference.
• One of us was the editor, and opened the version of the second chair as the starting point of the version-in-progress.
• We now started editing this version paragraph-by-paragraph, line-by-line. Each time, the editor would copy the paragraph currently being discussed, and paste it into Skype's chat-window.
• All three of us would look at this paragraph, and compare it with the same paragraph in the Word-version.  We then proposed and discussed modifications a few lines at a time.  The editor kept track of these changes in the version being edited. Having agreed orally upon only a few lines, it was already getting difficult to see the bigger picture. Whenever that was the case, the editor copy/pasted the now modified paragraph into Skype-chat again. We would then orally make a few more changes, to be copy/pasted into chat by the editor again.
• This continued until we were satisfied with the full paragraph. We then moved on to the next paragraph, until we were, at last, happy with the final Call for Papers.

So, what exactly happened? Using a few standard functionalities (Word for editing text; Skype-Conference for group voice discussion;  Skype-Chat for keeping track of the rapidly changing "focus-text"), as well as a few simple rules (all authors focus on same paragraph; all authors compare the current focus-paragraph with the related Word-paragraph and make comments; the editor changes lines on which consensus has been reached in the version-in-progress; the editor pastes modified paragraphs into chat whenever there is too much confusion) a very complex group authoring process had been successfully supported by ICT. This is the first time I have been able to deal with such a daunting collaborative task online instead of face-to-face. It really was an amazing experience. So, who needs all these very expensive, proprietary collaborative platforms? Perhaps the future of online work is not so much 'less tools, more process', but really 'lean tools, more process'?

NB A much more sophisticated analysis of the co-evolution of tools and process is described in (De Moor and Aakhus, 2006).

References

- A. de Moor and M. Aakhus (2006). Argumentation Support: From Technologies to Tools. In Communications of the ACM, 49(3):93-98.

Social Software: What's in a Name?

Christopher Allen gives a useful overview of the evolution of terminology of software supporting social interactions, including such terms as bulletin boards, groupware, and the currently popular social software:

In examining the origins of 'social software' we can see the terminology for the field has moved through a sort of life cycle. There have been many terms for this type of software, some of which have taken off, and some of which have not.

Typically, a visionary originates a term, and a community around that visionary may (or may not) adopt it. The diaspora of the term from that point can be slow, with 10 or 15 years passing before a term is more generally adopted. Once a term is more broadly adopted, it faces the risk of becoming a marketing term, corrupted into differentiating products rather than explaining ideas.

Is 'social software', which just now gaining wide acceptance, destined for the same trash heap of uselessness as groupware? And, if so, what impact does the changing of this terminology have on the field of social software itself? Only the future holds those answers ...

Danah Boyd continues this much-needed discussion:

The term bothers me because the software is helping the hardware mediate between two people engaged in a social interaction. I've always loved 'computer mediated communication' (CMC) because it describes the action and then we can talk about CMC hardware/software and CMC behavior. In CMC, the focus is on the communication with the computer and its role as mediator being a description to the primary activity: communication. With social software, the adjective is describing our focus: software. I know that the term is used by technologists who build things instead of dealing with social interaction, communication or even hardware, but it still bothers me. I feel as though the term allows us to emphasize the technology instead of the behavior that it supports.

The "half-life time" of terms related to technologies supporting social interactions seems to be short, despite thousands of the brightest minds on the planet having been involved in the R&D on these concepts for at least five decades. From my background, being Information Management rather than hardcore Informatics, this confusion can be quite easily explained, however. The intended use of technologies is not the same as their actual use.  A mailer is usually aimed at supporting communication between human beings, although many people also quite happily use it for filing and retrieving project information.  On the other hand, a database can be used for human coordination and communication, for example when it sends a notification of an update to a database operator who is also the project manager. 

Thus, looking at the technological functionalities alone is not sufficient. What is lacking in the analysis is the usage context of the technology. Simply speaking, there is no social software, although there is a lot of software that is very suitable for social purposes. To reduce the confusion, we need to think more in terms of socio-technical systems instead of talking about social technologies per se.  Such systems analysis focuses on the roles that technologies play in a particular social setting. By making these roles explicit, we can ask such questions as: what are the gaps in functionality provided to the community? What are alternative functionalities for a particular social need? What type of community could best benefit from this particular technology? Do we perhaps need a very different kind of technology or a set of technologies? Playing a good game of cards can be an excellent "same place, same time" technology to break the ice before using an advanced electronic decision support system... Systems thinking thus steers away from isolated functionality suboptimization, while trying to optimize the holistic system of human and technological elements and their countless relations.