So, someone asked me the first good question about the vision for Bongo. To paraphrase, why am I against using the word groupware?
The easy historical answer is that it was almost the rallying call for Hula, and the groupware bad essay by jwz expressed this quite neatly in some ways. But that’s not a very good ‘why’ answer.
For me, the difference is probably quite slight in some respects, but it comes down to who we design features for. Do we design them for people, or do we design them for groups / teams / organisations? In my opinion, the answer has to be that you design for individual people.
A good example of a feature which I don’t think is person-oriented is “Read receipts” on e-mails. For those who haven’t seen it – and I can’t believe there are many – the idea is that by setting a read receipt on an e-mail, the person you e-mail sends you a signal back when they’ve opened the mail. In some software, that signal goes back automatically, in others a dialog comes up, sometimes it’s a setting that controls the behaviour.
From having seen how some businesses operate with regards to receipts, I can’t think of another feature which induces complete communication avoidance in people: I know people who are actively afraid of opening their e-mail lest they accidentally read something and inadvertantly tell someone they’ve read it, implying that they’re “actioning” the e-mail. Total loss of control over their time. (You can make similar criticisms of Blackberries too, I believe)
The basic issue with giving too much visibility into someone else’s data is that you get that Big Brother mentality, which if it doesn’t actually exist will certainly exist in the minds of the more paranoid members of an organisation. It’s almost like having your boss stand over your shoulder watching you work.
Are there examples of features I think ought to be in Bongo, but might not appear in “groupware”? Possibly. It seems to me that the aim of groupware generally seems to be to suck people in online, whereas software which is about communication, time management, etc., is actually about getting people offline. Putting in work-flow which manages more of people’s work in a groupware system seems to me to be totally the wrong answer, particularly where you have to have “group acceptance” for things to work properly: “Oh, you changed the meeting online to 3pm? We agreed it would be 4pm at the last meeting…”. Bongo would never assume that everyone else is using Bongo in the way that Exchange divides people between “Users” and “Everyone else”.
There’s no really easy way of expressing this, and I don’t think that there is a bright-line test for this either. In many ways, Bongo will be groupware, or be usable in the same way, and it will have most of the same features. But I think the focus has to be on the individual, and providing tools for an individual to use, not attempting to mold a team into a specific set of processes.
Of course, that could all still be “groupware”. We’re just redefining what groupware means 🙂