Info

Ben is Vice President of Global Products at Walmart.com, where he works closely with his long-time friend Dion Almaer.

Bespin Roadmap

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

Michael Mahemoff recently wondered about whether Bespin will ever have more than one back-end. That’s a good question! We’ve waffled a bit ourselves on the back-end bit. The initial back-end was Java, but we migrated to Python. Michael pointed out that we’d need to solidify and publish the API for alternate back-ends to be viable.

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.

Bespin Collaboration Screenshot

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!

Open Web Tools Directory

Several weeks ago, I blogged about the Open Web Tools Directory, another Mozilla Labs experiment we launched to explore making some sense of the huge and diverse web tools ecosystem. Thanks for taking a look at the site, for telling us about your favorite tools and your own projects, and for all the feedback!

We’ve just pushed out another minor update to the directory, including the more updates to the tools database and some tweaks and bug fixes to the user interface. (We’ve still got more tools to add and will do another update next week.)

So what’s next for this project?

At Mozilla, we try hard to do things out in the open and engage the community in the development process very early. We’re a mission-driven organization and that mission is to maximize the Internet’s benefit to the public, so we like to get the public involved as much as we can in telling us what we should be doing.

Can you help us decide what the next steps should be?

The Open Web Platform

To get the conversation going, let me share our vision for this project. I’ll start with the big picture, and work back towards the Tools Directory.

At some point over the last few years, the web browser evolved from being a way to render hypertext documents and has become an application run-time platform. This new emerging web-based platform has been called the “Open Web Platform” with increasing frequency; I like the name and have used it for the past few years and will use it throughout this post to describe the technologies available to web applications (provided to them by the browser and occasionally plug-ins).

Liberation

I’m extremely enthusiastic about the Open Web Platform and its potential to liberate: to liberate applications from the shackles of operating systems (e.g., you must own [Operating System X] to run this application), to liberate developers from the tyranny of learning multiple SDKs (e.g., you must learn n entirely different technology stacks to get your app onto n different platforms), and to free users to customize their applications easily and to share those customizations freely (e.g., the Greasemonkey / “user script” vision). As the web platform gains in capabilities, it frees us from traditional unnecessary barriers that sap our productivity and block our progress. I’d like to expound on each of these “liberations”, but it’s a bit orthogonal to today’s theme, so I’ll move on for now and circle back another day.

(Don’t get me wrong: I fully support empowering application developers to chose the platform that allows them to best express their vision and meet the needs of their customers, and I want people to be able to profit from selling software. But I’m working as hard as I can with thousands of other people to make the Open Web Platform be the platform of choice for as many developers as I can. Because when that choice makes sense, we all win. Big time.)

Fragmentation

One of the reasons folks call the web platform “open” is that it’s beyond that control of any one person, entity, vendor, government, etc. As a consequence, knowledge about the platform is fragmented. There’s not one resource you can leverage quite like the developer networks of other platforms. There have been some attempts by the market to meet the obvious demand created by this void, but it’s pretty difficult to make money selling developer tools or developer-related services. A few companies succeed at this, mostly at a small scale, but much larger numbers of companies fail.

We’d like to do something about this.

Open Web Developer Center?

We think the web could really use something like an “Open Web Developer Center”, a site where you can go to find integrated documentation for the various browsers and specifications that compromise the platform and learn more about its capabilities, where you can find the tools that can increase your productivity and augment your capabilities, and where you can socialize with other developers.

Perhaps most important of all, we want a place where that helps more people get engaged in influencing the future of the platform in direct, tangible, and meaningful ways–to help realize the vision of the Open Web Platform as the People’s Platform, of the people and for the people.

The Tools Directory

So the tools directory is a first step towards realizing this vision. We’ve got a lot of work to do, but we think the next immediate steps are:

  • Provide great ways to navigate and filter the data. Seeing a centralized mass of tools is useful, but it’s much better to sift through the noise to find just what you want. Crowd-sourced tagging (i.e., folksonomies) are one step in this direction; we’d also like to add features that show you the tools that your friends use, the most popular and highest rated tools, and tools that industry luminaries use. What are useful filters / discovery techniques should we employ?
  • Crowd-source the data. What’s the right mix of data stewardship? Submit revisions and have them reviewed by “trusted editors”? Allow each tool to have an “owner” that modifies the data? Wikipedia-style free-for-all?
  • Efficient and accessible interface. The current UI is certainly… graphical but has a bunch of usability and accessibility problems. We think the right move here is to focus on a more traditional data-centric UI for the main view, but provide one or more graphical “explorers” for a different perspectives onto the data set and a bit of fun and whimsy. We’re making the data open to anyone to consume (we have a JSON-producing MySQL-backed web service we’ll make available soon, once we nail down the API a bit more) so we’d love to see folks create their own explorer interfaces on top of the data in addition to the one we’ll provide.

What Do You Think?

Are these the right immediate next steps for the tools directory? What do you think of the overall vision of the Open Web Developer Center?

I really wish all of us interested in this sort of thing could get together and brainstorm about all this. In fact, we should do just that. Look for another post on this topic shortly.

In the meantime, please do send in feedback, either via our mailing list or comments right here. Thanks!

Open Web Tools Directory

Just published a couple of blog posts earlier this week announcing the release of another project we’ve been kicking around here in Mozilla’s Developer Tools lab: a directory of the universe of tools to help web developers. The Ajaxian post goes into some detail on the technology behind it. Like Bespin, the directory uses HTML 5’s canvas element extensively. Unlike Bespin, there’s no compelling technological reason for this decision; we’re exploring different ways to visualize the data and we wanted to achieve a dynamic floating universe of tools.

We’ll be spending a great deal of energy in building up the directory and turning it into a vibrant, living resource for web developers, and we’d sure love to get your feedback on what you think we should to do it. Because the data is all available via a simple JSON format, we’re also keen to see other folks create their own custom front-ends for it. Who knows, perhaps a few other alternative interfaces will land in the coming weeks or months (we’re releasing a fully accessible version for the vision-impaired soon, btw).

I also want to give a special thanks to Mike “Morgamic” Morgan and Laura Thomson, two members of our incredible web development team at Mozilla, for tons of help getting this project going.

It’s been nothing short of a blast to work on this project. I’ve spent a good deal of time developing software on desktop platforms and here the web platform delivered the best of both worlds: easy-to-use graphic rendering API coupled with trivial network access built-in. And the performance! While a GPU-powered version would blow away the performance of the current version of the directory, I’m fairly certain that the web’s software rendering performance is comparable with the major desktop platforms software equivalents (e.g., Java2D, GDI, etc)–and I can’t wait to do a canvas 3D version to compare GPU-backed performance.

Go Web.

Beyond Dark Castle

I’ve a lot of fond memories from my youth that revolve around the Mac: getting invited over to a girl’s house in the second grade… to play Dark Castle on an early-model Mac; retrofitting my 3rd grade teacher’s Lisa to be Mac-compatible; getting pulled out of classes later on in elementary school to help the school principal with their Mac; learning how to do desktop publishing on the Macs at the neighborhood “Laser Layouts” shop; playing with one at the local software store, etc.

I could never afford one growing up, so it was always this magical machine I could only play with on borrowed time. And I guess the small piece of me that yearned for a Mac during my elementary school years still lives on in some form–I own a few vintage Macs, purchased a few years back.

Dark Castle and its sequel were among my favorite games on those old Macs, so it’s been great fun for me to relive a bit of the past and spend a few minutes playing the recently released remake: Return to Dark Castle. Beats firing up an emulator or obsolete hardware. Well, it’s easier, at least.

Google is Amazing

I find in Google’s search engine significant irony. Let me explain.

Have you considered how they can possibly index so much of the web so often and make it available coherently to the entire world and deliver individual results quickly and consistently? The Google engineering team deserves our immense respect for such an accomplishment. It is truly amazing.

Of course, the “Page Rank” algorithm is an equally amazing feat of engineering–a core idea with millions of tweaks to deliver the amazingly accurate results we have come to expect.

And yet, when you use Google, the interface is amazingly simple and effective. We forget about all of the complexity underneath, and we are compelled to return to Google time and again because we have such a great experience with it.

As a software engineer by background, I’ve spent a great deal of time in my career pondering how to build a scalable infrastructures, considering what languages to use to create my algorithms, and wiring together plumbing. Those are all important, but I’m thrilled that I also have the opportunity to work on the most important aspect of software creation: crafting an amazing user experience.

Does it sound arrogant to say that the user experience is that important? Yes, but when you consider that statement, isn’t it true? We can have amazing code and compelling server infrastructures, but if users don’t enjoy using our software, we’ve failed indeed–but if the users enjoy our software, does it matter if our code is crap or our infrastructure isn’t the best?

How many of the popular web properties and successful businesses of the world were built on famously hackish codebases? Facebook and MySpace, as does the wild popularity of PHP in general.

Wii

This reminds me of the Nintendo Wii. I have some friends in the video gaming industry. They can’t stand the Wii. They scoff that some people find it fun. They can’t get past that it doesn’t have the horsepower of some of the other consoles. Its the same as us scoffing at PHP.

Or is it? This is actually a bit different, because the hardware limitations of the Wii bleeds into the interface. Games *are* limited. Cross-console games always look worse on the Wii, and even Wii-specific titles make a point of focusing on the interaction instead of the graphics.

It’s one thing to say that the user interface is more important than the hidden guts of a system, but that internal heart of the system affects the user interface, so the two are obviously quite related. I’m just saying we need to maintain our perspective and remember which is the tail, and which is the dog.

You know, when you start to focus on refining the user interface, you realize that it’s quite a bit of work. GUI interfaces–as distinct from text-based user interfaces–are especially labor-intensive. If you’ve ported an old green-screen app to a GUI technology, you know what I’m talking about.

One of the reasons for the labor-intensiveness is simply because more is possible, and therefore, much more is expected. It’s not that there’s anything particularly complex about asking GUI toolkits like Java Swing and JavaFX, Adobe Flex, the browser, etc. to render a text box as compared to some text-based toolkit, but it can be a lot more complicated to add asynchronous data validation, to deal with concurrency in the interface, progress notification of background asynchronous tasks, creating rich and complex tables to display summary data in, dealing with hundreds more choices for skinning the UI, and so forth.

There are all these details involved in getting it right. I love the term “craftsmanship” for describing a devotion to getting the details right in creative acts.

Alan Cooper, author of “The Inmates are Running the Asylum” and “About Face”, has talked about craftsmanship recently in the excellent talk “An Insurgency of Quality“:

[Craftsmanship] is all about quality–it’s all about getting it right, not to get it fast. It’s measured by quality, not speed. It’s a pure measurement, and a delightful one. Craftsmen do it over and over again until they get it right. In their training, they build things over and over so they get the experience they need to get it right.

But you know what? Most of us in the software industry work in IT departments. Our bosses don’t talk to us in these terms, do they? They usually talk to us in terms of “getting it done”, don’t they?

I think Joel Spolsky captures the way many in IT view craftsmanship:

Craftsmanship is, of course, incredibly expensive. The only way you can afford it is when you 
are developing software for a mass audience. Sorry, but internal HR applications developed at insurance companies are never going to reach this level of craftsmanship because there simply aren't enough users to spread the extra cost out. For a shrink-wrapped software company, though, craftsmanship is precisely what delights users and provides longstanding competitive advantage.

So does that mean those of us in IT are doomed to create crappy software for the rest of our careers? Well, in the same talk, Alan Cooper maintains that Joel is wrong:

[The distinction between commercial and I.T. applications is artificial.] The issue is that there are human beings who are using our products. Some of those human beings pay for the privilege of using our products, and some are paid to use our products. I.T. [workers have] chosen to work in an arena where people are paid to use our products, and it's amazing how that covers up a lot of interaction design sin. While real people will use your really bad product because they are paid to use it, if it is a good product with decent behavior, productivity will climb. You can walk into any organization and spot the SAP users–they are crying in a corner. You can’t tell me that that’s good for business.

There’s a lot more to say on this topic, but let’s suffice for now with agreeing that whoever you are wherever you’re working, you can make the decision now to care about the quality of what you do. Various cultures will tolerate various degrees of craftsmanship, and that’s okay. Do the best you can within your own constraints.

Firefox Logos

Four snapshots of the Firefox logo revision effort

By the way, one of the things I love about Mozilla is the level of craftsmanship that goes on there. For example, Alex Faaborg, one of our UI designers, has recently been driving a revision of the Firefox icon. He’s gone through fourteen iterations and still isn’t done, all for a bit of polish that isn’t immediately obvious. I can’t tell you the number of times I seen him here at the office past midnight working away on this and other details out of his love for the craft.

Going back to the Wii thing. It’s a great example of expectations. If you expect video games to look like this:

Crysis Screenshot

…then the Wii is going to let you down. On the other hand, if you expect people who play video games to look like this:

Video Gamers

…you may find your enjoyment of the Wii a pleasant surprise indeed.

It’s funny–my friends who hold the Wii in such contempt, even when they have fun playing the Wii (usually with family), they still proclaim such hatred for it. They expect their video games to have amazing graphics, and even when such games deliver a valuable service–entertainment–the disappointment of missed expectations detracts from the experience. (Whereas those whose expectations are exceeded by the Wii, they just love it!)

The comedian Louis C. K. explores this area of our psychology in a popular video clip that’s gone viral on YouTube, Hulu, and others. It’s hilarious but it demonstrates something very true: our expectations for our life’s interactions are constantly on the rise–and we get very annoyed when our expectations are not met.

I think the first key of creating a compelling experience for your users–of practicing effective craftmanship in software–is to understand what their expectations are, and to meet or exceed them as often as possible.

What do you think?

Follow

Get every new post delivered to your Inbox.