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!
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!
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.
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.
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.
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“:
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?
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:
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.
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:
…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:
…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.
I used Apple’s excellent data migraiton program to copy my data from my old MacBook Pro to the new one. After the transfer, the first time I tried to sync with iTunes between my new Mac and my iPhone, iTunes informed me that I could not activate the DRM because I’ve used all five of my machine authorizations. I had already put the old MacBook Pro away so I decided to deal with this later. I interrupted the iPhone sync-in-progress just as it started to avoid issues with the third-party applications and music on my phone.
Things worked well for quite a while. Then, three days later, I noticed that when I tried to launch a third-party app (actually, Apple’s own Remote application), it crashed right away. And that, in fact, every third-party app crashes after launch, but the built-in apps continue to work.
I’ve since discovered this is a fairly common problem with iPhones. I’ve rebooted the phone and hard-rebooted the phone (you know, holding down the front button and the top button) many times, authorized iTunes and synced, de-authorized iTunes and synced, downloaded new free third-party apps via iTunes and synced (to try and trigger the DRM to reset), downloaded new apps via the iPhone, removed and re-downloaded several of my apps at random, wiped the iPhone and restored from a backup, removed all my apps via iTunes and synced (losing all my data, some of which wasn’t synced with other services and I’ve no idea how to restore the data back), and then added them back via iTunes and re-synced, and yet, after all this, the problem still persists.
I guess I’m off to the Apple store to fix the problem, but geez, I really don’t have time this week to deal with all this. Have I missed anything? I’ve scoured the forums and I seem to have tried everything.
![[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.](http://bengalbraith.files.wordpress.com/2009/06/cooper11.png?w=922 "Alan Cooper")
![[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.](http://bengalbraith.files.wordpress.com/2009/06/cooper2.png?w=922 "Alan Cooper")
