As prognosticated earlier, the next release of Bespin (named “Chuck Finley”) schlepped out the door this week. One half maintenance release and the other half feature release, Chuck Finley adds a “deploy” command and support for SVN commands while fixing various glitches with the once-shiny-now-lusterless “H. E. Pennypacker” release we put out in late August. The deploy command takes Bespin one step closer to the vision of developing entirely in the cloud and we’re absolutely thrilled to move in that direction.

Kevin Dangoor goes into Chuck Finley’s new features over on his blog, including a look at an enhancement to collaboration that shows you the current location of your collaborators’ cursors (a fancier version of this is coming soon).

Next up is 0.4.5 “Bubba Ho-Tep”, a planned maintenance release for next week that may gain a few features as well.

Today we shipped the next release of Bespin: the 0.4.2 “H. E. Pennypacker” release. As discussed in my recent “Bespin Roadmap” blog post, H. E. Pennypacker is primarily a bug fix release focused specifically on issues related to the new collaboration engine. The key fixes in this release include:

• Work towards ensuring that we never lose your data (bugs 511289, 511217, and 511291)
• You can now export projects from Bespin (bug 511828)
• Various other stability enhancements (bugs 511125, 512044, 511539, 509496, among others)

We’re now focused on shipping Bespin 0.4.3 “Chuck Finley” which will deliver deployment and SVN/HG commands (right now we have our own VCS commands that map into SVN and HG; we are working on implementing the actual SVN/HG commands you’re used to).

Command-line Only?

In the bespin mailing list, I saw a message or two lamenting that we are too focused on the command-line at the expense of the UI. Take heart, gentle fans. We have plans to implement GUI equivalents for nearly every major command we can think of; it’ll take us a while to get there.

We hope you enjoy H. E. Pennypacker, and I look forward to telling you more about Chuck Finley in a week and a half or so.

With the recent release of Bespin 0.4 “Stratospheric Stratus” last week and 0.4.1 “Fletch F. Fletch”* on Monday, it’s a good time to post an update on the Bespin roadmap.

0.4.2 “H. E. Pennypacker” – August 26th

Minor release that aims to whack any major bugs reported in the collaboration engine; if we have resources left over, we’ll add support for a subset of native SVN and HG commands to Bespin’s command-line.

0.4.3 “Chuck Finley” – September 7th

Includes a new feature: a “deployment” command. We plan to support SCP (and therefore SFTP and FTP) to start and build up from there.

0.4.4 “Bubba Ho-Tep” – September 14th

Minor release to fix bugs and introduce small enhancements and feature polish.

0.4.5 “Ash Williams” – September 21st

Adds “colorization” to the collaboration engine: the ability to track who has changed what in a file and visualize that in a configurable fashion, probably with foreground or background text color. While this may sound like a minor feature, it actually represents a significant enhancement to our existing functionality.

Also includes “cursor tracking” to show you where collaborators are currently hanging out in the document.

0.5 “Brisco County Jr.” – September 28th

Follows-up with additional social development features, such as:

• “Live file history”: the ability to scrub back and forth along a timeline that corresponds to the history of the file to see what it looked like at any point since its inception. This is vital for collaboration because undo/redo doesn’t undo changes to the document made by your collaborations; using this feature, you can essentially do this by going back in time to revert a change made by someone else.
• “What are my friends doing right now?”
• “What is everyone else in this project doing right now?”

Feedback

Follow along with us on the Bespin mailing list as we update the community if (when?) we deviate from these plans, and please do give us feedback here on this blog or on the mailing list.

* We neglected to update the UI’s codename label in 0.4.1 to Fletch F. Fletch from 0.4′s Stratospheric Stratus.

Roadmap image adapted from Jemimus’ IMG_2699

At our launch, we documented the server API, but we’ve changed it a touch here and there since. We need to keep the Wiki up-to-date. But in addition to our back-end, there is MobWrite, which powers the collaboration engine. MobWrite’s protocol is documented, but we’ve altered it a touch and published our alterations as well.

If you’ve an interest in implementing a back-end server, please do let us know and we’ll put more effort into updating the published documentation.

We just launched collaboration in Bespin today; it’s come a long way since the initial prototype we had working earlier this year. That progress is due primarily to the hard work of our own Joe Walker and Google’s Neil Fraser, the latter of which created Mobwrite, an editor-neutral diff-and-paste collaboration engine that Joe integrated into Bespin underneath the beginnings of a set of social collaboration features that Joe’s designed and implemented over the past few months. As Joe mentioned in his blog today, this is but the first step in a journey towards a very social coding experience on-line with Bespin.

With today’s (beta) launch of collaboration, you can now use bespin.mozilla.com to check out an SVN or HG project from any public repository, hack on the code with a whole bunch of friends in the same session, and commit the code back to the repository. We’ve tested around twenty sessions collaborating on 10,000 line files and things seem stable, fast, and fun–but before you get too carried away, collaboration is to be considered beta, and you may lose some data while using it until we have a chance to examine bugs filed by the community and fix ‘em.

We definitely need to implement some sugar to track cursor positions of collaborators, colorize text according to author, and so forth. Watch for some of this soon.

Here’s to more social, collaborative coding experiences in the browser!

We’re hoping the Pie solves a couple of problems for us. Let me take a couple of steps back. Currently, Bespin has two screens, a “dashboard” and the editor itself.

We’ve not been happy with this arrangement.

You see, our original concept for the dashboard was that it would have all kinds of neato project statistics, showing information on your productivity, where you are spending most of your time editing, real-time information on others currently working in the same project, etc. You know, a dashboard.

But the “dashboard” in the Bespin 0.1 and 0.2 releases is just a file explorer. And it’s been the only way to open files, so Bespin users have to constantly go back and forth between the dashboard and the editor. Bleah.

Augmenting the Editor

Our first approach to solving this problem was bringing the dashboard into the editor:

While we developed a bunch of ideas for making this into a pretty good experience, we couldn’t get past the uneasy feeling that we were taking the first step towards this kind of an interface:

One of our goals for Bespin is to keep it simple–while still providing advanced features. So the thought of winding up with an interface with so many knobs and dials gives us more than a few shudders. Plus, it’s just fugly.

Don’t get me wrong–I’m sure lots of folks like the traditional IDE clutter-up-your-world-with-panels style, and we want to support that. But we want to be absolutely sure that clutter doesn’t become the default, nor the required way to interact with Bespin in order to utilize most of its helpful features.

The Pie

As we discussed these issues, we started thinking more about a concept I’ve been pondering for a while for mobile devices: a predictive pop-up that groks HTML, CSS, and JavaScript grammars and based on context predicts with high accuracy a reduced set of words you’re likely to want to type next (outside of free-form text entry, of course). For example, given a blank link in JavaScript, we can predict that you’re likely to type one of “var, if, for, while” and so forth. Obviously, there’s lots of challenges involved in getting this right, and it may be unworkable entirely.

We took this basic concept and re-imagined it in a more general-purpose application:

And, as of this morning, we’ve got some of this implemented in Bespin:

The idea is that you can use the mouse (right-click) or the keyboard (CTRL-K) to bring up the pie, and then select the quadrant (up, down, left, right on the keyboard) you want, and a pop-up menu renders the content. You can also skip directly to the area you want with a direct keyboard short-cut (e.g., CTRL-J for the command-line); selecting it with the mouse just requires a gesture towards the desired icon.

Why a Pie?

We’re intrigued by this concept for a few reasons:

• On small screens (e.g., iPhone), the interface still works well. The pie would appear first, and once you make a selection, it disappears and is replaced by the pop-up. This is an easy adaption to make, and we’re designing the contents of the pop-ups to scale to different sizes easily.
• The pie will pop-up exactly where the mouse right-clicks, minimizing the effort required for the mouse to select items (see this demo from Jono for more detail on that point). For the keyboard, the pie will always appear in the bottom of the screen.
• The number of pie pieces can expand, giving users a top-level short-cut mechanism that is easy to use with the keyboard and mouse
• It’s different, a bit whimsical, and hopefully fun (will take some tweaking to find out for sure)

There’s lots more to discuss about finer details and interactions, but I’ll save those for another post once we start refining things a bit and getting feedback from others. (All of the details now are in flux; e.g., we’re not crazy about the individual icons in the pie yet).

Enter the Gratuitous Animation

But before I go, I wanted to show you a bit of fun we had with the pie. Another of our goals with Bespin is to make it fun, and so of course we can’t just have the pie menu appear. We designed a couple of different animation effects describing how it could come in and go out:

Here’s how it turned out:

You can see a stand-alone, live version of the animation by clicking on the image below (but you’ll need a canvas-compatible browser, such as Firefox 3+, Safari 3+, Chrome, etc.):

We’re pretty impressed by how quickly canvas animations render on Safari 4, Firefox 3, and Firefox 3.5 beta. Even when we run the animation on a huge window, we’re able to alpha-blend every pixel in the window to create a fade out effect on the window contents while rotating the pie into place. Nice job, browser graphics gurus! Thanks for making it so fast.

We did the animation by hijacking Dojo’s animation facility a touch:

var anim = dojo.fadeIn({
    // create a fake node because Dojo Animation
    // expects to mutate DOM node properties
    node: {
        style: {}
    },

    duration: 500,

    // use one of Dojo's fancy easing functions
    easing: dojo.fx.easing.backOut,

    // Dojo supports an onAnimate() callback for each frame
    // of the animation and passes in values that it is setting
    // on the DOM node. We'll grab "opacity" and use it as a
    // general "progress" value.
    onAnimate: function(values) {
        var progress = values.opacity;
        renderPie(progress);
    }
});
anim.play();

As with everything we do here in Mozilla Labs, this is experimental–it may be we come crawling back to docking panels as our primary interface metaphor.

What do you think?