However, our efforts to usability are still limited to one single angle: The actual end user experience. While this is unquestionably the most important part, we can’t ignore another: Usability for developers. Since tackling the whole world of development is too much for one blog post, we’ll only investigate web development here.

Syntax & API

Why are certain programming languages more popular than others? Usually not because they’re faster – not even because the input or output is smaller. A single argument counts most: The easiest understandable, the one with the greatest learning curve wins.

Think about it – while binary approaches to languages and data formats are much more efficient, it’s a pain to work with. Take JavaScript – due to it’s flexible and dynamically typed nature, it’s not always the most efficient way to code – however, it’s the most popular.

Let’s think about a higher abstraction: JavaScript libraries. jQuery, for once, is highly popular amongst web developers because the API has a natural, language-oriented aspect. It’s almost neurologic – by looking at a certain block of jQuery code, you start to almost guess what the other functions could be named like.

Now, as soon as you have a good concept of the API using real-world language, easy to understand by simply looking at it, there needs to be a next step: Make the learning curve as small as possible. This can be done by providing a complete and solid documentation, demonstration of every feature, walkthrough tutorials and ways to communicate within the community (forums, mailing lists).

So, in other words, for a web programming language or toolkit/framework to be developer friendly, the following arguments (at the very least) need to apply:

• Real-world language when naming API calls (do, write, make, etc)
• A high learning curve, achieved by
  • Good documentation
  • Good demonstration
  • Good communities around the project (forums, mailing lists, etc)
  • A strict API design with no or little exceptions

Of course there’s more to it, but this should give you a good start (by the way, this works for most development, not only web development).

Tools

The second very important field where usability needs to be improved are the actual tools web developers use to create applications and websites. It’s no wonder Dreamweaver is ridiculously successful – it’s not necessarily something that outputs great results (although it can, if you’re disciplined!), but it’s simply so damn easy to use.

Web developers usually have to use tools for the following tasks, and the sub lists tell you how these need to be  improved:

• Writing the source code (IDE’s, Editors)
  • Better versioning integration
  • Helpers for refactoring
  • Integration with the browser engine
• Creating and designing the frontend (WYSIWYG Editors)
  • Integration with the browser engine, instead of faulty preview modes (Dreamweaver CS4 has that, but they didn’t remove the preview mode yet)
  • Smart control panels that utilize a framework’s documentation to create fields / controls
  • Tight framework integration
  • Integration with actual design applications (i.e a bridge to Photoshop from Dreamweaver, allowing “live slices” to be be embedded into the Dreamweaver source, that update automatically as soon as I change the overall image in Photoshop)
• Testing (End-platform, various browsers, Selenium [automated tests])
  • Semi-automated testing frameworks that run in a browser and serve a click-through for testers and mainly create experience surveys
  • Automated user tests, creating a ‘fake’ user that executes clicks and drags on actual websites and applications
• Debugging (often integrated in IDE’s, our in the actual platform, i.e. Browsers)
  • One tool that debugs across various browsers, instead of great tools for each browser, i.e. Firebug, Dragonfly, the IE8 Debugger.

While there are some solutions that are clean, well designed and integrated for application development (see iPhone development), web developers still suffer. Especially testing and debugging is still a pain in the arse, and needs to be improved.

Conclusion

In the end, I think there is a lot that needs to be done to make the actual developers happy before those can make the end users happy. A developer in an inspiring environment can create things you wouldn’t even imagine.

On the jQuery UI side of things for instance, there’s still a lot that needs to be done, but what’s really great is that we realized that our development cycle sucked. We have started to make developer tasks as easy as possible – there’s a new jquery.simulate plugin that triggers actual clicks and drags to ease testing, there are new commit hooks that will clean trailing whitespaces and there will be a project tool in the future that aids in documentation, testing and API design. We were also proud to be the first framework to announce web widgets in Dreamweaver.

So if you’re involved into a product that helps developers, think about how usable it is (instead of all it’s cool features), and help me and my comrades to make developer lifes easier, so they can create the great products we all love.

We’re seeing a lot of move recently – Mozilla pushes their JavaScript API, Webkit adds CSS coolness, Opera comes up with Canvas 3D and Internet Explorer with awesome new events like recently featured hashchange. Now even Google comes up with their own browser and Gears is therefore becoming a own standard for that very own browser.

If you look at all that development however, it’s becoming very clear that it’s NOT the same than 10 years ago. I believe the overall idea behind it is different: Browser vendors are not actively trying to lure people to exclusively use their browser, but they’re trying to push the standards for the first time in 10 years – they want to push the web .

As a web developer, one might think it’s all a big mess now, and it does help nothing to their very own situation, because they cannot use the new standards of one browser in their new product – what about the other 75% of their target audience? And then, I’m not even sure if that feature survives in 2009!

Here is the point where I come in, as a JavaScript library developer. What we library developers can do is smoothen the path for these poor web devs. There are two ways of doing so:

1. The Copy approach: Replicate an existing standard on other platform with the help of JavaScript
2. The “Lowest common multiple” approach: Take a couple of different standards across browsers and create a subset that can be used across browsers

Let me show you one example for each approach to better show you pros and cons:

1. The Copy approach: Google’s excanvas
   excanvas tries to bring the <canvas> element to Internet Explorer by using VML. While I think it’s a great project, it has some fundamental flaws: excanvas is not able to replicate the whole canvas API using VML. Although they’ve done a fair job of porting most of the features, some are missing simply because it’s not possible/too slow/too much work to port them.This makes developing for it fairly difficult, because you never now exactly what behaves how.
2. The “Lowest common multiple” approach: Dojox GFX
   The Graphics engine of Dojo creates a own API and uses several different standards to render the exact same result. The advantage here is pretty clear: By defining what to support and what not in a limited subset, a web developer can be sure that whatever he uses here, even the most awesome, cutting-edge features, will work on every platform.

In my personal option, the second approach is the one that helps defining new standards. It’s the library developer in the end that reviews all standards and tries out what’s possible and what’s not, and therefore, the library developers opinion weights a lot. The library developers are the ones that have the power to bring new features to web devs as early as possible – not the browser vendors.

Cheers!
Paul

(What I talked about in this post is something i will feature again in my session for the Ajax Experience. If you have a change, I invite to check it out!)