Thursday, September 29th, 2005

Jotspot Live: Live, group note-taking

Category: Dojo, Showcase

>A bunch of people have mentioned the announcement by Jot of Jotspot Live, which is a “Live, group note-taking” service built on Dojo.

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!

Screen Shots

jotspot-live1.png

jotspot-live2.png

Related Content:

Posted by Dion Almaer at 11:49 am
4 Comments

++++-
4.3 rating from 15 votes

4 Comments »

Comments feed

The non-polling approach is amazing! Are any other web apps doing this? It works extremely well. Would Apache support XMLHTTP requests that are open for a long time?

Comment by Steve — September 30, 2005

Steve,

Short answer: not likely.

Long answer: Apache is one of the reasons for things like Twisted Python to exist. Apache uses either the traditional thread pooling approach or the even heftier fork-and-forget mechanism. Both strategies have significantly higher resource usage for long-lived, low-data connections than something like Twisted, which is event based. In “normal” web workloads where connections close as fast as possible, Apache’s current strategies are generally fine. OTOH, when connections live a long time, only something like event-based servers do well.

Some work has been done on changing “normal” threading libraries to be event-based (or something like it), notably http://capriccio.cs.berkeley.edu/, but the addition of a pre-compile step and a modified libc mean that capriccio isn’t likely to hit your distro of choice anytime soon.

Hope that helps.

Comment by Alex Russell — October 3, 2005

hello
i created a one project for X company .In this project i used AJAx for Master creation.

It get the data from client side and posted to server s using ajax and insert this data to SQL Server using ASP and fetch the data from SQL Server using asp and show this data to client side using ajax without page refreshing…

If anyone have the time pls check taht link its will open uptp october 20 th.

http://www.inelpower.com/inel/fnb_i_calibdays.asp

Check that top link

| Designation | Department | Make | Model | Range | Site | City| Customer Type| Bank| Branch

thanks
Newbegin

Comment by newbegin — October 6, 2005

I expected it to use http push but it didn’t.
I sniffed the traffic and saw it did polling too often.

Comment by happie — January 16, 2006

Leave a comment

You must be logged in to post a comment.