Social Software: Think “Baking Social Interaction In”, not “Blogs, Wikis, etc.”March 24, 2008 at 7:58 am | Posted in social software, usability | 1 Comment
With all the talk about technologies associated with Web 2.0 and social software such as wikis, blogs, and ratings systems it sometimes helps to take a step back to remember how it is the underlying concept of social software, not just the technologies often associated with it, that is important. And that concept can be applied even without fancy new technology.
The most hip, Web 2.0-anointed technologies can be used in ways that have nothing to do with social software. For example, a blog mechanism could be set up by an organization to allow a single executive an easier way to post announcements with the commenting feature turned off. This would not be social software.
And the other side of the coin is that old technologies can be used to build social software even though they don’t have ready-made components to build in or a fancy meme. For an example of building social software without Web 2.0, I’d like to introduce you to a circa 1990 OS/2 1.3 system called the Cost Tracker.
The Cost Tracker is the first system I ever wrote as a full-time corporate programmer. I was working at a large financial services company during the days when mainframe costs were the largest portion of the IT budget and expensive CPU time made every runaway process and abend a hit to the bottom line. Once a month IT would receive an inch thick printout (green bar paper, holes on the side, fixed space font of course) with all the mainframe jobs that ran, their CPU and DASD (disk) usage, cost, and 15 more columns of stats. The stack would be divided up into sections for each manager and circulated through inbaskets for perusal.
I worked in a central IT unit tasked with executive information systems and internal IT systems. My task was to replace that paper-based system with an easily accessible, graphical system that would make it easier to see the costs, compare actual to planned expenditures, and locate the root cause of costly overruns.
Note: This is just a mock-up of the system. The data is all faked, but similar to what was there.
For the longest time, I thought the unique value was the left half of the screen. It was an early example of a drill-down system business intelligence system which allowed the data to be rolled up to the highest level (departments) and then the user could drill down by clicking on bars or pie slices to drill into more and more detail (each manager in a department, each system for a manager, etc.) until you got a raw spreadsheet-like window with a narrow, manageable slice of the 10,000 rows of raw data. Plan is shown with slashed bars and anything over plan is in red. Now you’d use a BI system or maybe fancy spreadsheet to do this. But that wasn’t an option in 1990. I got to write all the charting routines from scratch in C and had a blast doing it. I even got to speak on drill-down systems and linked lists as a guest lecturer at Indiana University.
But now I think the unique part was really the right half. This is just an edit window where anyone could enter comments that were attached to the specific graph on the left side so that anyone who drilled to that node or looked at historical data would always have the explanation right there for reference. I wish I remember whose idea it was to do that – maybe mine, maybe my manager’s or CIO’s. The tendency, even today, would be to consider this a number crunching problem and the system would be “done” when it allowed you to drill into the data.
To think up this design required lifting one’s head up from what seems like a quantitative system to understand the social process that went along with the numbers. And that social process went like this: In the old paper-based system, when the numbers came out the managers would dig in first to find out how they did that month and prepare explanations if there were any major cost overruns. Then the directors would look at the numbers and ask managers that were over plan what happened. Then the CIO would do the same of the directors. These conversations were highly inefficient, taking place over team meetings or through email, at different times of the month, and without a good way to track explanations over time.
Going beyond analyzing the intricacies of the raw job-level cost data I pulled down from the mainframe to understanding this social process allowed the system to bind the quantitative and the social together. The simple addition of an edit window for each node in the data allowed explanations to be stored in a common form, ready and accessible by directors and the CIO, and available over time in a way that conversations and email could never be.
I see this now as a good example of how social software does not relate to fancy Web 2.0 product categories, but is the powerful idea that understanding and building social processes into software greatly improves the value of these systems by acknowledging and enhancing the interpersonal nature of modern business.
1 Comment »
Analyst biz Attention Management BEA Blogs Browsers business case collaboration communication Composite Applications Content Management Economics email Enterprise 2.0 Fun Gaming Globalization Google Governance IBM Information Work interruption science Intranet knowledge management Lotusphere2008 Microsoft Microsoft SharePoint Mobile and pervasive computing Office Oracle portals presence Recession RSS social software Uncategorized usability User experience virtual worlds Web 2.0 XML Syndication