Online Groups Blog

In May last year Google released Google Wave. In August Google announced that they were shutting it down. Wave was an editor that allowed multiple people to edit the same document at the same time. It was similar to the editors that appeared in the labs during the early 1990s. In this post I examine why Google Wave should have been the perfect system for me, and why I never got beyond looking at introductory video (and it was not because of lack of advertising).

Sitting in the Bulls-Eye

I cannot think of anyone more firmly in the target audience for Google Wave than myself: I work the web, I know a bit about alternative document organisation techniques, and I could get an invite without too much trouble.

Google Wave presented me with a new way to work with other people and the web. Systems that are implemented with web-based technologies, such as Google Wave, excite me. That is why, I talk to people every day about what tasks they do, and how web-based systems may or may not help them. I love the web, and I enjoy designing solutions for people that use web-based technology. I get a thrill debating about how web-based technology works in with the wider scheme of things. Finally, I enjoy implementing designs — using a variety of languages.¹

Google Wave was based around a time-based method for organising documents. I am very familiar with such systems, as they were the focus of my thesis. I was intrigued by Google Wave, how a big company would try to solve some of the tricky problems with temporal interfaces, and how the the solutions would be made accessible to a wide audience.

Last, and least, getting a Google Wave invitation was not a problem. The World is not that big a place, as anyone who has played Six Degrees of Kevin Bacon can attest.

A Shot… and… A Miss

I seemed to be the ideal candidate to try out Google Wave. But I never used it. I can think of five reasons that I did not try it out: it would take time to learn, I had no one to use it with, it didn’t seem useful, it had technical flaws, and they did not pass Michael’s Test of Collaborative Systems.

The problem with New! and Innovative! systems is they can be a pain to learn. I have a background that is familiar with both the web and temporal document organisation, but I could not justify the time to learn Google Wave.² In addition there is plain-old homeostasis: I am happy with how I work (mostly).³

Google Wave will never work unless all your colleagues are using it. (There is no point having a phone if you have no one to call.) Sadly, convincing others to use a system is a hard task. I may have been able to convince my workmates to use Wave if I could have found a good use for it while working alone. However, Google did not present any compelling reason to use Wave by yourself.⁴

I could not justify the time taken to learn Google Wave, but I did watch the introductory video. From the video (which was designed to sell the system) I had a big question: how would Google Wave would solve any problem that I had? It was lovely that I could edit a document at the same time as my workmates, but if I needed to do that I would pull up a chair at my colleague’s desk and work on the same document. Currently I am in different time zones to my workmates, and so the normal way of collaborative editing (by sending a document back and forth by email) works really well.

In the demonstration video Wave had problems contacting the server. This worried me: what if I had no network access? Is broadband a requirement for Google Wave? Finally, if Google cannot get a system to work during a demo, why should I bother to use it? Some get excited about cloud computing, but I still have my doubts, as I type this at the wrong end of the Southern Cross cable.

The final problem I had was that Google never mentioned how undo worked in Wave. Undo is tricky when dealing collaborative editing systems. Imagine you are editing a document with someone else. Things are going well, but you slip and mistype something. No big deal, you hit undo. What does undo do?

• Does it undo your own edits, or the other person’s edits?
• What if the other person makes a change that is based on the thing you are about to undo?
• What happens if the thing you are undoing changes while your undo message travels to the server?

None of these are easy questions to answer, especially when dealing with a network as unreliable as the Internet. I smelt a rat. If Google had solved the above issues they would be chuffed and would have mentioned it. If they had not solved the above issues then the system is flawed and I did not want to use it.

So, for a variety of reasons I did not use Google Wave. I guess I will have to stick to mailing lists.

Footnotes

1. GroupServer is built around four languages. From most familiar to obscure they are JavaScript, SQL, Python, and TAL (which is an extension to XHTML).
2. Apple took a different tack with the touch based user-interface. It was slowly introduced to the market, allowing both developers and users learn how the new system worked.
   • The iPhone came first, and was based around a phone, which is originally a tactile system.
   • Then they made the system more general with the iPod Touch, which is an iPhone without the phone.
   • Now we have an iPad, which is further generalised away from the phone as it does not even the same size. (My gut tells me that iPad owners are likely to have an iPhone, which would also help with acceptance.)

   I also suspect that aiming at the consumer market, rather than businesses, helped iOS based devices as learning an interface is akin to playing. Learning to swipe is part of the fun of owning the device. If you are trying to get work done, then a new interface is an annoying hindrance. (There is a reason that iPad applications are not developed on the iPad.)

3. I am mostly happy with the tools I use at work, but I will get around to switching to Eclipse in the near future.
4. Version-control systems — such as Git, Mercurial, and Subversion — are a collaborative tool that is useful for one person to use. I like to think as version-control systems as allowing you collaborate with your future self, which could be considered a different person, but I have a tendency to over think temporal interfaces.

I have an idea: a browser plug in that measures the similarity between a page on a news site and a known press release. I doubt that it would have to be very sophisticated: my ol’ favourite TF-IDF algorithm could generate the keywords and compare them to a database of known press releases. Give the page a score from 1 (a verbatim copy of the press release) to 5 (an original article).

[I promise to make a nice post about Google Wave on Monday.]

Back in 2008, I shifted my working days to Tuesday to Friday in the office, then from home on Saturdays. Overall it worked well, but some Saturdays were harder than others. I wasn’t sure why, but on those days I found it particularly hard to concentrate, and ended up having to work on and off all through Sunday, too.

A handy article published by A List Apart, comprising tips from readers for working from home, was the first step towards improving the situation. I was intrigued by the different approaches that worked for different people, many of which were simple common sense. One piece of advice that I put into practice straight away was the “Apply technology” section. (Let’s be honest — what geek needs an excuse to apply technology to any of life’s problems?) That got me on to Remember The Milk, a fantastic task-management tool which has long since taken over from my scrappy, often-updated, paper to-do lists.

Immediately, creating flexible to-do lists with due dates and priorities (and let’s not forget that oh-so-satisfying “Complete”) got me more focused. This became even more important when I finally realised that at the times when I find it difficult to concentrate, it’s either because I don’t enjoy the task itself, or more commonly, because I’m not 100% sure that I’m doing the right thing. I wasn’t able to commit to a task because I wasn’t sure it was the most important thing to work on, or whether I was taking the right approach to it. Essentially, I hadn’t gone to the effort of making some hard decisions about priorities, or breaking down the task, before jumping in. That was a breakthrough for me.

Google Calendar has become more important to my work, too. I prefer RTM for keeping track of my day-to-day tasks, but Google Calendar for keeping an eye on upcoming events (for some clients, these events are added to the calendar up to a year in advance). I then translate the preparation required for those events into smaller tasks in RTM.

The third Firefox tab that I open up every morning is Tracklr. Since I started using Tracklr to clock my work, I actually have an accurate idea of how long I have been working on a task, and I can record notes on what I did in that time. (In the past, trying to remember just why something took so long, weeks after finishing it, was a source of headaches.) It also helps guard against those times when I would get a little… too focused on fixing a problem, shall we say, and stay on it for hours instead of taking a breather and coming back to it with fresh eyes. Now, even when I’m well in the zone, part of me remains aware that there’s a timer running somewhere, and I remember to stop and clear my head.

The main weakness with email is its main strength. The wonderful thing about email is that every individual can have an email address and an inbox. The terrible thing about email is that a group can not have an email address or an inbox.

Email is an individual-centric medium. That makes it a great medium for one-to-one, and one-to-many communication, but a rather poor one for many-to-many communication. This creates a dilemma. Much of our work and learning takes place in groups, in discussions with multiple contributors, and multiple concurrent conversations. Email is the default medium that people use for online communication, but collaboration tools are often web-based, with poor support for email. At best, you can be notified by email of new posts, but you must visit the web interface to make your own post.

Of course, you can use reply-to-all for group collaboration. In this mode, each person who posts a reply-to-all member must maintain a copy of the membership list of the group.

GroupServer, Mailman, Google Groups and other Mailing List Managers set out to address this problem by providing an email address and an inbox for a group. The system has an entity for the group. That entitystores the membership list for the group, forwards messages to the members, and keeps an archive of those messages.

Here is an example. The NZ Open Government Ninjas is a group of 120-odd black-clad deadly warriors of the web who are working on Open Government projects. Anyone who considers themselves to meet this criterion can join the Ninjas.

Once you are a member of the Ninjas, you can email all the other Ninjas with a single email address ninja-talk@groups.open.org.nz. The system takes care of sending the email to the group members. It also shows you email in an online inbox for the group. The default view for that online inbox is a list of Topics (emails with the same subject line). This view makes it easy to track multiple concurrent conversations.

An individual topic, for example the Open data workshop, 29 July topic, contains all the posts with the same subject line, arranged for reading in chronological order. You can also view all the last posts in full on a single page, or a summary of the latest posts. Finally, you can search the posts in the group’s inbox, or view files that have been posted to the group.

The group’s inbox stores the messages and files that belong to a group, in the same way that an individual’s inbox does so for an individual. This means that group members do not have to manage that content themselves, and that any member can visit and browse a single authoritative repository of the group’s content.

This simple step of giving the group the basic features of email, an email address and an inbox, enables group members to hold multiple concurrent conversations, using the client they are familiar with: email.

A recent article in Network World made me very glad that GroupServer (and OnlineGroups.Net, by extension) only displays plain-text email messages.¹ The problem is this:

• Fancy formatting in email uses system called HTML.
• HTML can contain a programming language called JavaScript.
• JavaScript can do evil.
• It is very difficult to remove the JavaScript from the HTML.

HTML is the format that all Web pages are written in, including this one. It allows all the things you would expect of word-processors, such as making text bold, adding bullet lists, and breaking the text into paragraphs. Email messages are often sent with both a plain-text and a HTML version.²

JavaScript is normally used to provide little interactive tweaks to an HTML page. For example, JavaScript changes the Search button on this search page to say Processing… when you click it. JavaScript allows me to make these small improvements that make GroupServer easier to use.

Sadly, JavaScript can be used to carry out nefarious activity — just like telephones allowed prank calls, and email allowed spam. It was this problem that Google came across. Ne’er-do-wells sent messages with Javascript in it; the messages did unexpected things, such as forwarded the user’s browser to a pharma site or tried to download something unexpected according to Google. A few years ago Google purchased an entire company, Postini, to help them deal with this sort of problem. Despite all the effort by Google some nefarious JavaScript managed to get through to GMail, which is what prompted the article in Network World.

It is possible to strip JavaScript from a page, but spotting the JavaScript is surprisingly hard.³ Thankfully, there are tools that clean the HTML, and I would love to integrate one into GroupServer. Sadly, the HTML can be quite different after it has been cleaned.⁴ Each of the different email programs (Microsoft Outlook, Apple Mail, Mozilla Thunderbird, Eurora, IBM Lotus Notes, Google Gmail, Microsoft Hotmail, Yahoo! Mail, Novell Evolution, Pegasus Mail…) produces a slightly different variant of HTML. Checking what the messages from each program looks like after cleaning is a daunting task.

I want GroupServer to support HTML email. However, the task is way down on my todo list: it is currently job 126. In the mean time, I am please that our pages, and the members of the groups run by GroupServer, are safe.

Footnotes

1. The HTML version of the message is stored and forwarded on to the other group members. However, GroupServer only displays plain text on the website.
2. The HTML produced by most email clients does not conform to any standard that I know of. It is truly awful stuff.
3. The Wikipedia page on Cross Site Scripting details a few ways that different systems try and overcome this problem. It also links to the Browser Security Handbook, which shows some of the many ways JavaScript code can be hidden.
4. One of the problems is with the style attribute. It normally controls how things looks, and is a good thing. Sadly, JavaScript can be embedded in the style attribute. Removing the style attribute would be the safest thing to do, but doing so changes what a message looks like.

[This post is based on a topic in the GroupServer Development Online Group.]

There is no doubt that online collaboration technology has got better in the last twenty years. But has that resulted in more collaboration? Certainly, it looks like people spend more time hanging out online, but is the technology itself what makes the difference? I have seen enough instances of “build it, and they do not come” to know it is not. No matter how awesome your technology is, it does not make people collaborate. What does then? Here’s how I think about it.

There are three requirements for collaboration:

• Medium — some way to get messages between people.
• Motivation — people have got to want to collaborate.
• Agreement —agreement to use a particular medium in particular ways.

Medium

Of course, the medium most familiar to most humans is face to face. If you abstract what happens in face to face collaboration, however, there are processes that can happen via other media. I form an expression of some idea, feeling or intention and I send that in your direction. You receive the expression, unpack it, and it has some affect on you. Body language, cave paintings, spoken language, inscribed tablets, the printed page, letters, telephone, email, SMS, Twitter. They all do the same job.

Merely enabling the technology, however, does not mean collaboration necessarily happens. Anyone in a city knows how isolated we can be from each other, despite even face to face proximity. On our own server, over 90% of the sites and groups started are unused, even though others are well-used.

Motivation

On the other hand, if the participants are motivated, even the most ordinary technology will often suffice. An obvious example is SMS or “texting”, as it is called in New Zealand. The multi-press system for entering messages can hardly be called usable, and yet is no barrier whatsoever to the teens who send thousands of messages per month from phones concealed under their school desks. Last weekend, I read a story about people rowing three miles in a dinghy to a dance, before the road from Governors Bay to Lyttelton was put in.

If people are sufficiently motivated, they will participate. Hold on to your technology budget until you have established this.

Agreement

Motivated participants with access to a collaboration medium need just one more thing before collaboration is likely to happen. They need to agree to use one particular medium that is available, and then agree to use it in ways that will be effective. The 19th century Cantabrians observed strict social protocols at community dances. SMS users have found inventing SMS language (or “text-speak”) to be a more effective work-around for the limitations of cell phone keypads than type-ahead.

To use an online collaboration medium, 100% of the participants in collaboration must agree to use the chosen medium. If one keeps using email, all the others must keep using email. In fact, in most cases, people do simply keep using email, adhering to loose agreements such as “mostly reply to all”. Add to that “use a subject line that matches the content” and you can do pretty powerful collaboration, with ordinary email.

GroupServer is a web-based open source web-based mailing list manager developed by OnlineGroups.Net. If you know OnlineGroups.Net, you’ll know that GroupServer is its engine. For that reason, we’re pretty excited to be able to call GroupServer “1.0?”, and to make it available for free download.

We have released GroupServer before, but we try not to talk about that now. Like most software developers, we want our product to be perfect before anyone sees it. Well, it isn’t perfect now, but it’s a lot better than the previous version.

I could explain what has changed in the new version but that won’t mean much to you, unless you’ve been following GroupServer closely. What I will do is give a quick overview of what GroupServer is, and where it fits.

GroupServer is a mailing list manager. It has all the email interface features of systems like GNU Mailman and Google Groups. Unlike Mailman, however, GroupServer has an integrated web interface, similar to that of Google Groups. This means that users can read and send posts, and manage their subscription settings via a single web interface. Unlike Google Groups, however, but like GNU Mailman, GroupServer is open source. This means that administrators can take complete control over the implementation and management of their site, and even develop enhancements to the software, rather than having to use the service exactly as it is provided.

It is possible to interact with GroupServer almost entirely via email. It has email subscription and unsubscription, digests, moderation, spam-handling, bounce-handling and vacation-message loop-handling. It tells you if you can’t post to the group you have tried to post to, and tells you why. When people join and leave groups, GroupServer sends notifications to the group member and administrators.

Via the web, GroupServer looks like a web forum. Each group is located on a website, usually with other related groups. One GroupServer instance can support as many sites as you like, so that you can keep unrelated groups separate. Some groups are visible to the public, so that anyone can read posts without logging in. Other groups are private, and can be joined by approval. And other groups are secret, so only logged in members can even see the existence of the group. Once a person is logged in, they can carry out a single search across all the groups they are a member of. They can also define email addresses that work with all of their groups. Unlike Mailman, each group member has a profile, and can assocate as many addresses as they like with it.

A good example of a GroupServer site is the GroupServer site itself. This site has several groups related to the exploration, administration and development of GroupServer. A larger GroupServer site is the E-Democracy.Org forums site, which has over 130 groups and over 13,000 members. The site processes around 9,000 posts per month, and supports groups such as St. Paul Issues Forum with nearly 700 members, and Minneapolis Issues Forum which has nearly 1,300 members.

Those and many other sites run on the same code that is free to download and install. Making installation easier has been one of our main priorities for 1.0 Beta. The installation process is scripted using buildout, and is well-documented. It is still not as smooth as we would like, however, and we are working hard on improving the installation process for the next release. After that, we will be releasing a swag of enhancements that support one the main tasks of online group administrators: helping people to join and leave groups.

We think that GroupServer is a useful alternative to Mailman, as it provides a much more usable web interface. We have created a feature list comparing GroupServer with Mailman and Google Groups. If it is just the web interface that you want, however, Google Groups is a serious contender. GroupServer fits in custom installations, where greater control is required. As the source code is freely available, you can look under the hood, and inspect the exact mechanisms that GroupServer uses to manage users’ data. GroupServer administrators have direct access to the databases, system log and other behind-the-scenes components. Developers can create custom enhancements, or influence the core development of the system.

Now that GroupServer is approaching 1.0, we are looking for feedback from experienced open source mailing list administrators. What are the problems that you have with Mailing List Managers? What do you want to achieve that you currently can not? How could GroupServer help your users, and group administrators?

I am not sure if Malcolm McLaren is right about failure and creativity in this interview with Andrew Denton― but he provides food for thought.

I was taught that to create anything you had to believe in failure, simply because you had to be prepared to go through an idea without any fear. Failure… was a wonderful thing.

Goodbye, Malcolm, and thanks.

My earlier post on the Apple iPad discussed how the new device was not a new device: all of the stuff we are excited about is the same paradigm we have had since the 1970s. However, a review in the New York Times gives me hope that the iPad may be more than a new type of personal computer.

[The] Scrabble app shows the whole board without your zooming or panning: a free companion app for your iPhone or Touch is called Tile Rack; it lets you fiddle with your letters in private, then flick them wirelessly onto the iPad’s screen

I think it is odd that this sort of interaction was not mentioned earlier…

I have been thinking about the Apple iPad, specifically how it relates to other devices. I then recalled my undergraduate course in human computer interaction, and the work that was done on ubiquitous computing. I looked about me, and realised that I was surrounded by devices that were restricted to a few research labs fifteen years ago. The hardware is all there, with a few differences, but we are a long way from the vision of computing that came out of the last decade of the 20th century.

In the 1970s the Xerox Palo Alto Research Center (PARC) gave birth to the computing interface that would be used for the next 30 years (at least): the personal computer, modern graphical user interfaces, Ethernet networking, laser printers, and object-oriented programming. Famously, Apple stole most of these ideas to create the unsuccessful Lisa and highly successful Macintosh computers. As a follow-up, under the leadership of Mark Weiser, Xerox PARC started work on the next generation of devices.

What they came up with was the concept of ubiquitous computing — where computers will be vastly better at getting out of the way, allowing people to just go about their lives (Weiser, 1993). To achieve this Xerox PARC decided that we needed three devices to supplement, or largely take over, from the personal computer: tabs, pads and boards.

Tabs

Tabs were the smallest interface; about the same size as a Post-It Note. Originally they had very limited capabilities, with 128KB of store and the ability to play video at four frames a second. Tabs did have wireless networking, using a bespoke system that Xerox PARC developed, so they could work like a two-way pager (a device that the original tabs superficially resembled). Input was provided by a pen, but because of the limited processing power a simplified alphabet called Unistrokes was used (Goldberg and Richardson, 1993). Within an office building a tab could report its position, so your workmates will know where to find you, a bit like an advanced RFID security card.

Cell phones (alias mobile phones) are the same size as tabs. The intervening few years have seen store increase into hundreds of gigabytes, video increase to full-motion, three wireless protocols (Bluetooth, 802.11, and GSM) are typically used for communication, and GPS is used to track the location of the cell phone anywhere in the world (except in an office building, where satellite coverage can be a bit spotty).

Pads

Pads, or tablets, have had a longer history than tabs, as far as I can figure out. Commercial pen-based interfaces had been available for a couple of years by the time Xerox PARC started working on the MPad. Unlike the commercial offerings of the time, the MPad had wireless networking, multiprocessing (unlike the not-yet-shipped Apple iPad), and multimedia capabilities. However, it was the software that made the MPad dramatically different from the current crops of pads, but more on that later.

The pad has had a hard time commercially. Microsoft has been pushing tablets for over twenty years without much success (I can recall booting a Windows 3.1 for Pen Computing machine). The Apple Newton was problematic enough to get a mention on The Simpsons. Far more successful has been the netbook, which has a user interface similar to a desktop but it is as portable as a pad, for a lot less money. Interestingly, some netbooks are acquiring touch-screens, so they can behave even more like tablets. (The photo above is of a netbook, rather than an actual pad.)

Boards

Of the three interfaces I recall learning about as a student, the board is the first one I can recall ever seeing, sort of. The idea was to create a shared space where many people could interact — much like a whiteboard. The Xerox LiveBoard (Elrod et al, 1992) was the result of the PARC work on boards, which actually made it to market as a Xerox product. It could be used to record drawings, and make presentations, blazing a trail that Microsoft PowerPoint and Apple Keynote follow.

I first came across the LiveBoard concepts with the electronic whiteboards, which would record and play back the drawings that were made on it. However, game consoles are most common board-sized interface that I come across. They drive million-pixel displays, providing a shared space where people can interact using wireless controls.

The Hardware Difference: Keyboards

The tab developed by Xerox PARC did not have a keyboard as they have a very small interaction area — too small for a keyboard (Weiser, 1993). The Palm Pilot and Apple Newton had pen-based input like the Xerox tab. However, most tab-sized devices are not pen-based: even the Apple iPhone uses a keyboard when text needs to be entered. I do not know why this is the case. Maybe it was a long running patent suit (1997–2006) brought by Xerox against Palm (over the Xerox Unistrokes system, on which Grafitti was based) that made others wary. Maybe keyboards are easier to implement and learn. Maybe the tricks used by tab-like devices to allow text input (like multi-tap and T9) are good enough: the speed of input using T9 is 14.63wpm (σ 1.09) (Wobbrock et al, 2007) compared to 15.8wpm (σ 4.02) for Unistrokes (Castellucci et al, 2008). The Unistrokes patent must be close to expiring, so we will see soon if someone picks up the pen-input ball and runs with it.

Keyboards were optional on the MPad developed by Xerox, all netbooks have a physical keyboard, while the Apple iPad relies on an on-screen keyboard. As for boards, the Nintendo Wii, Sony Playstation 3, Microsoft XBox 360 consoles all have an optional keyboard. In addition, Microsoft PowerPoint and Apple Keynote presentations are usually presented on workstations acting as boards and the keyboards are vital to the creation of many presentations (sadly).

…But Where is the Software?

Reading back across the ubiquitous computing papers, old and new, I am amazed at how far the hardware has come, and how little the software has changed. The original concept was to move beyond the intimate nature of personal computing, and to create devices that were better suited to communication and collaboration. The software would allow tabs, pads, and boards to interact with each other; not just your own devices, but those used by others. A presentation could be displayed on a board, appear simultaneously on pads (for annotation), and be controlled by a tab (Myers, 2001). A drawing made on one persons’s tab would appear on the shared board. A running program would follow you (well, your tab) from your workstation to another person’s office, where it will display itself so you could discuss it, a bit like cut and paste writ large (Rekimoto (1997) dubbed it pick-and-drop). There was excited (albeit awkward) talk of shared situations and collaboration. However, the seamless interplay between the multiple device surfaces that Weiser imagined is still far from reality (Klokmose et al, 2009).

Recent Apple products also lack the joy of ubiquitous computing. The language that Steve Jobs uses to talk about the iPad is still the language of the personal computer. Take the list of tasks that the iPad has to support:

• Browsing (which did not exist at the time of the Xerox MPad),
• Reading email,
• Viewing your photos,
• Viewing video,
• Listening to music,
• Playing games,
• Reading eBooks

There is no shared space, beyond email (which is older that I am) and Web browsing (which is fifteen years old by my count). Instead he claims that unless a pad is better than those tasks listed above it has no reason for being. He then goes on to discuss how the iPad can be personalised and discusses the many single-user tasks for the iPad. When he briefly discusses sharing, in the context of photos, the talk is centred around a single device.

I am not a ubiquitous computing researcher (I studied undo) so I cannot offer any insight into why the software is not there, while the hardware is more than capable. Instead I take heart that there are still people working away at the problem — publishing papers about frameworks and software architectures, as user-interface researchers do when they need something to present and the coding is harder than expected. Software is also what free and open-source development is good at. With the free and open software present in tabs of all shapes and sizes, pads and boards I hope that some hackers may be inspired to take up the ubiquitous computing ideas, dodge the remaining patents, and create software that brings people together, allows them to share situations (not matter how awkward) and make the world a better place.

Me? I am still trying to sort out email…