Wednesday, February 11, 2009

WriteMaps: Follow up

I wrote about WriteMaps recently, an online program that allows you to easily map out a website. It looked like just the tool to help my high school students get a handle on some of their bigger design projects. One of the features that drew me was the ability to share a document between several users. I thought this would be great for small group work.

I had my entire class sign into WriteMaps and that happened without a hitch. We spent some time experimenting with the features and I then had a simple assignment where they would each add one node to a master document. It didn't work. Only a few kids were able to get in and change the doc. The rest of the changes went out into the nether regions never to be seen again. I've had similar occurrences in other groupware where if you have too many users at one time, it won't work.

No problem. I'm a flexible teacher and my hair can't get much grayer than it is now. So, I set them up into small groups of three and had them try to work on a document at the same time. I still got mixed results. Work was lost. Kids were frustrated. I had to back up a few steps.

I will still have the students do some mapping with the program but my plans for working collaboratively on one large site with this as our centerpiece have been scrapped for the time being. I emailed Scott Jehl (author of the program) asking if there is a way around this. When I hear back, I'll let you know.

In the meantime, I am exploring other options.


  1. Hi Al,
    I'm glad to hear you like WriteMaps, but I'm sorry to hear about the issue you had with your students. This is a limitation I'd like to solve in an upcoming release.
    I think the most immediate way to handle it will be locking - where a sitemap can only be edited by one person at a time. Perhaps there will also be a way to steal a lock from someone too, particularly if they happened to leave it open after finishing.
    Another option would be to have it entirely live for all users at once. My initial thought is that this would be quite chaotic though.
    Do you have any ideas for how best to approach this issue?
    Thanks and sorry it took a little while for me to get back to you.
    -Scott Jehl

  2. Thanks for getting back to me.

    The problem always seems to be (with every program I've tried) when I get more than two people working on the same document. Someone eventually saves over someone else's work.

    Insults are thrown.

    Chaos results.

    What I'd like to see is a master document (with one person who has final control and then each entry from different users identified somehow? Color maybe?

    Another possibility would be for there to be some way to easily merge documents. An editor grabs all the separate work of the group members and combines them into one large map.

    I (and several of my students) still use your program when we are working individually. I'm anxious to see where you go with this.


  3. Thanks Al,
    I understand your frustration. Unfortunately, this is something a lot of online collaboration tools struggle with.

    Currently, WriteMaps functions like desktop software: you work on a locally modified copy of a file and when you save, you overwrite the entire file resource. Of course, just like a desktop app, this really sucks for collaboration.

    The easiest way to solve it is a lock - essentially only allow one person to edit at a time, and enforce it with good messaging when someone else attempts to edit a locked map. Apps like pbwiki use this approach and it works quite well. Of course, this would disable simultaneous collaboration, but at least users are notified of the state, and in the end it's much simpler to implement than a live environment.

    A better but much more complicated solution is a total live editing environment where each person's changes merge into a single document as they work. If you've ever used google docs, they do this very well (though at times it can feel a little buggy). Like you suggested, changes made by each editor appear colored in your view. Each editor's local environment would track only their own changes in history, so undo/redo would not affect others' changes. But they could certainly modify pages that were added by others if they wanted to.

    The second option is what I hope to achieve and I'll be experimenting with ways to do this in the coming weeks.

    I'm currently working on a pretty big rewrite of the app right now so any other feedback you have would be greatly appreciated.

    Feel free to email me at scott[at] or info[at]