The Sea of Ideas

Real-world APIs

My friend Nicolas is defending localStorage in his blog, and I want to show my full support. In particular, this following sentence caught my eye and should make you curious:

[It] absolutely stinks of browser developers creating an API that’s easy to implement rather than creating an API that’s easy to consume. This is the opposite of how good APIs are made.

I simply couldn’t agree more. Browser vendors and the W3C tend do de-prioritize the most important feature of any API: Its usability.

In April 2011, I proposed a new CSS feature I called “hitmapping” in the form of extending the pointer-events property to support a new opacity threshold. Everybody I talked to – including browser vendors – agreed on its importance and usefulness. However, the thread soon turned into a discussion of how difficult implementation would be in WebKit, and the proposal was blocked. How can this possibly happen? As a web developer, I couldn’t care less whether something is going to be harder than something else to be implemented because of a browser’s architectural design decision!

What do we get instead? In my case, nothing. I have to perform black magic voodoo (image tracing and canvas manipulation) to achieve the same feature. In most cases though, we get alternative verbose APIs that are too complicated, too slow or too verbose. But hey! At least they’re easy to implement by browser vendors.

As a library developer, I’ve been going to hell so other web developers don’t have to. Vendors seem to have settled on the idea that web library developers will create abstractions around their new browser APIs, so developers can use them.

To the vendors and spec editors: This is not ok! It’s part of your main responsibility to create usable, real-world APIs. Library developers are doing your job because you don’t. I know many of you personally, and I know you are smart enough to fix this. Do it!

Thank you,
Paul

The jQuery Foundation

Today, I’m incredibly proud and happy to read about the launch of the new jQuery Foundation, and rather than doing a quick tweet, thought I’d write down a couple words to congratulate all members of the jQuery team, and all jQuery users.

I was one of the original six signers of the documents when we joined (guy signing the paper is me) the Software Freedom Conservancy as a project on September 11th, 2009. Back then, the jQuery organization was still a toddler, and we were in real need for legal and administrative support to be able to concentrate what matters most to the jQuery team – jQuery, its sub projects and its users.

I’ve been out of the main loop for some time now, but reading about the new foundation gave me a smile today. jQuery as a project has matured to the point where they can pull this off and succeed, and there’s few open source projects out there who can. The secret sauce to success is an extremely passionate, strong team of developers that make up the jQuery Core team.

It’s been a hell of a (fun) ride when I’m looking back at my personal relationship with jQuery. When John and the community in 2007 asked me to start jQuery UI, I didn’t know what was in front of me. It’s been an amazing time that taught me many things about software development and working with others. Working on the jQuery UI Team helped many to get their next jobs, including myself, and most importantly, I have made many great friendships during my time at the jQuery project.

Keep on rocking, jQuery!

The coverflickr

When I was refreshing my labs and updated them to fit the corporate Dextrose design (http://labs.dextrose.com), I quickly figured that I wrote quite a few plugins in the past that still deserve a lot more attention, because they are..well… kind of awesome.

In order to receive more attention, plugins like Coverflow need a kickass demo. Before, I only had small image demos in a small canvas, which weren’t quite as effective, so I decided it’s time for a killer mashup: Meet the Coverflickr.

The Coverflickr is a mashup experiment to show the beauty and flexibility of the Coverflow plugin while making use of a multitude of new HTML5 features. It’s an interface for browsing Flickr’s interesting images in a graphically sophisticated way. It is best experienced in Safari (even better : Latest webkit nightly!) or Chrome, although it will run smoothly in Firefox 3.5+ (minus preview animations and reflections). Here’s the techniques that are being used in the Coverflickr for those who care:

• CSS box reflections combined with CSS gradients for the reflections
• CSS Transforms for the preview mode and within the coverflow plugin
• CSS Transitions for the preview mode and the alternate mode switching animation
• YQL for the fetching of the images

There are a couple not immediately visible but pretty neat features going on here. For them, I had to significantly alter the coverflow plugin (soon to be released in a new version):

• Endless browsing. When coming to the right end, it fetches more images, appends them to the list and refreshes the coverflow with the new method “refresh
• Alternate transformations.Click on the bottom link “Alternate version” and the transformation will animate live into another one now using rotations. The coverflow plugins transformations can now be exchanged on the fly through the “transformation” option.

This has been an incredibly fun demo to do, and I realized it wouldn’t be possible to do so without the help of the Webkit project, pushing the web like nobody else. I therefore dedicate this demo to the Webkit team, my personal heros that are not afraid to pioneer new features for the greater (web developer) good.

Enjoy, and let me know if you like what you see (also if you don’t, but please be kind)!

Underestimated UI techniques: Morphing

When I design new applications, I realized I use a couple patterns that I haven’t seen in much use elsewhere, so I’ll start to blog about them. The first pattern in this series is called morphing.

What is morphing?

Bush-Obama morphing

Morphing essentially describes a state change on an element, transforming it into another. Many UI frameworks have helpers for morphing, usually in the form of class animations. jQuery UI has made it transparent to animate jQuery’s class manipulation functions like addClass, script.aculo.us has Effect.morph which essentially does the same.

Why is it useful?

From a higher level UI perspective, morphing really describes that one element becomes another based on the context. It is essentially very powerful because it gives your users a visual cue what is happening, how is happening and why it is happening. Instead of doing an instant change, the users eye can follow the motion and you therefore give them a better feeling of control over the whole situation.

Show me!

Let’s do an example. While working on smart.fm’s new item builder, I had to visualize the following steps: Clicking on a button to add text, then displaying a text input, and hiding the button since you cannot add text twice. Usually, it would roughly look like this:

However, with morphing, it not only looks hot but solves the issue in style:

This was a particularly lazy example, since it doesn’t even truly morph one item into another – it just animates the width of the button and fades in the input on top. But visually, the element clearly transforms.

Morphing in the wild: Inline editing

One technique that was is heavily inspired by morphing is inline editing. Essentially, you click on a paragraph or element, and it transforms into and editable element. Most solutions don’t actually morph, but you get the idea. There are thousands of other usecases out there waiting to be discovered, and if you have some, I’d love it of you share them with me!

A plugin so short it’s tweetable: Mask

I recently found the need to create a utility that helps me to mask a series of elements with a background image that spans across them, so the the picture basically gets masked by the elements selected. I couldn’t find a sweet reusable solution out there, so I went ahead and created my own little jQuery mask plugin. Here’s the code:

$.fn.mask = function(u) {
	return $(this).each(function() {
		var p = $(this).position();
		this.style.background = 'url('+u+') -'+p.left+'px -'+p.top+'px';
	});
};

Here’s how to use it:

// grab all li's on the page and mask them with a certain image
$('li').mask('http://farm3.static.flickr.com/2075/2509376094_737cce37d4_o.jpg');

Most interestingly, this was the first actually useful plugin that was tweetable in it’s entirety: http://twitter.com/pbakaus/statuses/2492305298. Enjoy!

The technique behind the jQuery UI demos

I’ve decided to start blogging more about the actual things I’m working on everyday, and in this series, I want to first talk about the updated and improved demos of jQuery UI. The first important thing to understand is that the demos that come with the development package, and that you can browse from the trunk, and the demos you see at the jQuery UI website are the same.

The standalone demos

To me, the new demos are truly outstanding. Let’s talk a bit about why. If you download the development package, or browse the trunk, you’ll see a demos/ folder, with sub directories for every individual plugin. If you open one of these sub-directories, you’ll see a index.html, a default.html and named individual demos, i.e. containment.html. Each of these demos:

1. Is a standalone demo
2. Includes all the files it needs (JavaScript / Theming )
3. Displays a description of the current demo at the bottom

This means that those demos are excellent for learning how to do something – they come completely uncluttered, so you can copy and paste JavaScript and markup easily. Additionally, the default.html shows you the most simple state of the plugin (usually without any provided options), and the index.html provides a easy named listing to all these sub demos. Even better, if you open demos/index.html, you’ll see a page that looks very similar to the website demos section, but works like this:

1. If you click on a plugin in the left hand navigation, i.e. ‘draggable’,
2. it fetches the content of demos/draggable/index.html using Ajax and displays it as right hand sub navigation
3. if you click on one of those links, the created iframe in the middle updates itself

The website demos

For the website demos, it got a bit more sophisticated. We removed the beautiful but unusable demo carousel, and created a unified demo section that automatically pulls the standalone demo files from the repository, therefore it’s never out of sync. However, the simple iframe approach couldn’t be used because of the incredible amount of server requests made that way. Here’s the technique behind it:

1. include the theme and jQuery UI once
2. include demos/index.html using PHP, filter out any script/style tags and the header
3. now using JavaScript, rewrite all links to plugins to point to /demos/plugin

This shows you the index file. Perfect. What happens if you click on a link in the left hand navigation now?

1. A server-side rewrite rule resolves demos/draggable to demos/?load=draggable
2. in PHP:
   1. we export the ‘load’ information to Smarty, so we can access it in the template
   2. we then retrieve default.html and display it in a div frame, but filter out any script/style tags and header
   3. and we do the same for draggable/index.html, to show the right hand sub navigation
3. in JavaScript:
   1. we loop through all demo links in the right hand nav and define click events,so the link isn’t triggered, but instead, a hash is set (for easy bookmarking) and
   2. the selected file is pulled in via ajax – again, we filter out any script/style tags with src attributes, and the header/footer, and update the frame div
   3. at last, we pull out the description at bottom of every file, and display it below the ‘frame’

So, with a little more work involved, we not only made the demos extremely responsive and fast, but also reduced the requests to the server dramatically. Every time you click on a demo, only one single request is made, to fetch the actual html page.

Pretty cool eh? Enjoy!

The Library Detector

I’m happy to announce my first Firefox extension called Library Detector. Similar to a greasemonkey script I published to the jQuery mailing lists a couple months ago that showed if jQuery is running (which proved to be pretty useful to extend the Sites using jQuery page), the library detector is able to detect multiple libraries, currently including the following:

• jQuery
• jQuery UI
• Dojo
• Prototype
• Scriptaculous
• MooTools
• Spry
• YUI
• Qooxdoo

If one of these is found on the current page, it displays their favicon in the statusbar, and if you hover it, a tooltip will show with additional information (In most cases the version of the library, in the case of jQuery UI the plugins being used, and for Dojo if Dijit is being used).

Of course, there’s one catch in some libraries: If the developer renamed the scope of the Library (i.e. window.dojo) to something entirely different, the test fails (however, usually that’s not the case).

So, if you want to know what websites use your favorite library (or which do not), go ahead and grab the Library Detector from its download page.

Additionally, I’d love to see feedback, and if you think there’s a library missing, or if you have an idea how to improve a test / show additional information, please leave me a comment.

Cheers!

Taking Usability to another level

So I love that my main interest is finally a hot topic, and recently, Aza Raskin continued doing a great job evangelizing Usability in web and application design, making it more popular than ever.

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.

Possible jQuery (UI) promotion tour in Japan

After the great success of my trip to Tokyo in May (thanks to my friend Yusuke!), I have been thinking a lot of how to better promote jQuery and jQuery UI over there. Usually, american products have a hard time in Japan because of the language barrier, and the easiest way to overcome this is to simply be in Japan!

So here’s my idea: To every japanese company interested, I will give free workshops about jQuery and jQuery UI to employees/staff. In exchange, they will cover a small part of my travel budget.

So,

• If you live and work in Japan
• And your company uses jQuery/jQuery UI or wants to use it
• write me an email (paul.bakaus@gmail.com)

and we’ll discuss everything. I’m really excited about this idea, and it would be awesome if it works out. The same might happen in Brasil soon for another jQuery UI developer, which brang me the idea again.

Mata ne!

How library developers help defining standards

For the last couple of months, many people have been frightened that the Browser Wars are beginning to happen once again. It’s easy to come to such a conclusion if you see all these new standards in today’s browsers: Even only in CSS, Mozilla added a “-moz” scope for new CSS syntax, Webkit a “-webkit” one – and let’s not even talk about Internet Explorer.

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!)