Thursday, September 29th, 2005
We checked out the service, and it was a pleasure to fool around editing things. A pretty seemless experience all around, and you can check out some screen shots below.
We managed to chat with Abe Fettig, the developer behind Jotspot Live, on the launch:
What made you think of Jotspot Live?
The idea for JotSpot Live came at the end of March. I’d just gone to PyCon and seen Donovan Preston’s talk on LivePage, which lets you do two way communication between a web server and browsers. That got me thinking about what a live Wiki would look like.
At the same time, I was feeling annoyed by the way Wikis become less useful as the time between edits shrinks. When there’s a bunch of people interested in editing the same page at roughly the same time, you’re going to have conflicts. At JotSpot, our Wiki gives the editor a lock on the page, which prevents people from clobbering each other’s changes.
But before every company meeting there’s be a lock war as all of us tried to update our bits on the meeting agenda page. What bugged me about that is that I knew the changes we were making were in different parts of the page.
The idea from JotSpot Live came from those two lines of thought: fine grained editing and locking combined with live updates. I had a chance to try implementing the idea at our hackathon a little while later, and
(surprisingly) it seemed to work! As you can see from the hackathon blog post,
the core features of Live have been there from day one.
What are the target users and use cases?
I think JotSpot Live is useful any time you have more than one person writing about the same thing. That means meetings, classrooms, conferences. It’s also especially nice to use when you’re geographically separated from the other people you’re meeting with: you can all be looking at (and contributing to) the exact same set of notes, even though you’re not in the same room. And you don’t have to pick one person to be the official note-taker.
In many ways, though, I don’t know what the use cases for Live are going to be. We wanted to get it out there to see what people did with it. For example, since the launch on Tuesday I’ve been exchanging emails with a college professor who’s using Live to assist his English class students with their writing. That’s a use case I hadn’t thought of (and it brings with it its own set of feature requests, like Word import), but I’m thrilled to see it.
In your opinion, what are the “cool” features?
Did I mention it’s Live? :-) That’s definitely the coolest feature: even the simple fact that pages in JotSpot Live have presence is cool. It’s nice to see who’s there on the page with you at that moment. I also think our keyboard shortcuts are cool: you can use the arrow keys to move around the page, enter to edit something, ctrl-enter to save, esc to cancel and edit, and the delete and insert keys to delete and insert.
Having the obvious keyboard shortcuts work makes it feel more like a real app and keeps you in your flow. Keyboard shortcuts are something more web apps should think about.
I’m also happy with our support for drag and drop: You can grab any block-level element and move it around on the page. If you drag a paragraph into a list, it’s transformed into a list item. And after you’re done dragging all the other users see an animation of the thing you moved moving on their screens, so it’s clear to them what happened.
How do you handle the “live” part? Polling?
We’re using a (very slightly modified) version of LivePage, which Donovan Preston wrote as part of Nevow, a Python library for building web applications using the Twisted networking framework (which I just wrote a book on: Twisted Network Programming Essentials). LivePage doesn’t use polling. Instead, it uses a clever technique where each browser keeps an open XMLHTTP request to the server at all times, opening a new connection each time the old one closes. That way every client viewing the page is constantly waiting for a response from the server. When the server wants to send a message to a client, it uses the currently open request. So there’s no waiting.
What were the challenges for building the app?
The biggest challenge was making it work right in all the browsers. We support Mozilla/Firefox, IE, and Safari, and it definitely feels like we’re starting to push the limits of what they were designed to do. I saw some truly weird browser bugs while developing Live. IE in particular seems to have trouble keeping track of the state of the page when you’re making lots of changes to the DOM. Sometimes it freaks out and starts hiding elements, swapping the position of elements, or inserting seemingly random text into the page. Firefox is much more consistent, but has some crasher bugs that we have to be careful to avoid. Safari is like the well-behaved younger child: it generally does what it’s told without acting up, but there’s some things it just doesn’t know how to do yet.
Thanks, these were good questions and it was fun to answer them!