[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

I’m getting bored of people publicly yelling and complaining at people who have build something great that only works in a limited set of browsers.

“Uh noes, you can’t ignore [insert browser of your choice here, i.e. Opera]! You’re fighting the open web!”

There, I said it. A couple years ago, as a developer, I could see their argument. Open, interoperable, non-monopolistic and awesome and all. A couple months ago, I was angry. And now I’m just bored.

Imagine somebody grants you a budget of three months development time, and it’s up to you to make the right compromises. You can either create an ‘okay’ product that runs on 95% of today’s browsers. Or instead, you create something unbelievably great that runs on 70%. What would you pick? And no, you absolutely cannot have both. I spent too much time with outdated browsers to still believe there’s a way to achieve both.

I find it amazing that many people will pick the ‘okay’ product, just because the ‘open web ethics’ demand it. If you are creating a consumer point, there is absolutely no reason to go that route. None. Let me repeat that, as it is important. You should always – always focussing on creating a great product. Great in absolute terms, not relative to the browser. Achieving 15fps in a game on IE7 is not great. It’s great relative to what the browser can offer. In the case of a game, your baseline is 60fps.

You don’t want people to play your game at 15fps. “Their game is so great it only runs on latest browsers” almost definitely sound better than “Many people complain about the bad performance in their favorite browser.”. Hell, maybe your favorite reporter is using IE7. It unfortunately doesn’t stop here, as there is more harm to be done supporting outdated browsers. Progressive enhancement almost never works. I guarantee you that if IE7 is your baseline, you won’t be using all the cool features you get with, say, Firefox 7. And another project that focusses on the right compromises will always win.

So please, please, please! Focus on creating absolutely great products. Literally.

He was spot on during our Twitter exchange – his Scrollability demo performed amazingly well, while our own Scroller demo sucked hard on an iPhone 4 with iOS 4 (it was ok on iPad). Joe suggested that one has to use CSS Animations or transitions to improve framerates. He also suggested to use the “scale” transform to handle content scaling. Being an early adopter of CSS Transforms and all things shiny myself, I had my doubts about the JS animation vs. keyframe animation part. My own tests on sprite animations suggested that in fact, CSS keyframe animations were not at all faster than JS animations. In addition to that, even if there was a speed increase, there are multiple issues with implementing it that way:

• Scroller is designed with portability in mind. It only handles logic, and does not apply values. It can therefore be used in any environment, including Canvas.
• Zooming isn’t as easy as just putting a “scale” transform on the content and be happy. CSS Transforms do not modify the bounding box, so the content doesn’t actually become bigger. You won’t be able to pan to the edges anymore.

That being said, I was still curious on why our demo performed so bad in contrast to Scrollability’s shining examples. So I went ahead and created a couple quick mashup demos to be able to compare the context as well as functionality. First, I took Joe’s table demo, removed Scrollability and put our Scroller on it. No content or logic changes. Compare:

• Table demo (Scrollability)
• Table demo (Scroller)

Holy crap! Now that both are running in the same demo and scenario, performance on both is amazingly similar on an iPhone 4 running iOS 4. Scrollability still feels a tick smoother, but both are very usable and nice. I wasn’t finished yet so I created another interesting test case, putting Scrollability into our own DOM demo. In order to be able to compare, I deactivated zooming and horizontal scrolling on both. Here are the results:

• Fancy demo (Scrollability)
• Fancy demo (Scroller)

This is pretty amazing. On my iPhone 4, I found Scroller outperform Scrollability by a quite visible margin, and the margin is even greater on Chrome for Mac. At this point, I don’t have a clue as to why Scroller performs better – one possible reason might be the missing scroll indicator.

Update: I have heard from a couple people that they couldn’t confirm Scroller being faster than Scrollability on iPhone 4. After hours of debugging, I finally found out why they saw so different results. If you have the debug console in mobile Safari enabled, Scroller will always outperform Scrollability. If you have it disabled, Scrollability will outperform Scroller by a great margin. It’s completely mysterious, and it doesn’t help that Apple doesn’t give us debug info. I will continue to investigate what the issues are and update this blog post. Stay tuned.

Update 2: Obviously it had to be something silly. It wasn’t the viewport size. It wasn’t even the Scroller. It was the logging of debug values into input fields that caused a dramatic slowdown in Scroller when the debug console was not activated. I still have no clue why it was fast with debug on, but the riddle is solved. Scroller now always outperforms Scrollability.

In the end, I have learned that it’s not only the code itself that makes things fast, but the context. Only by comparing against the same context, the same markup in our demos, I was able to realistically learn about performance impacts. But as with all comparisons, take it with a good grain of salt. While Scroller and Scrollability have overlapping featuresets, there’s things that are different: Scrollability has a scroll indicator while Scroller doesn’t (it’s all logic, really), and Scroller additionally comes with zooming, both directions scrolling and some more.

And both have their respective use cases: I found it amazing how simple it was to setup Scrollability – it’s a great and easy plugin if you need simple scrolling content. For advanced scenarios such as games or more interactive content on Canvas or WebGL, I encourage you to try the Scroller. It requires more setup, but comes with greater flexiblity.

Until next time!

So why do I dislike dialogs that much? After all, I have written countless JavaScript implementations of dialogs and overlays in the past, and we have one in jQuery UI for quite some time now (and while I’m starting with my rant, keep in mind this is purely my personal opinion, not the one of the jQuery UI team). Diving into the browser and social game world, it slowly became crystal clear to me what the issue really is about.

Dialogs invite you to be lazy.
Solving the issue of navigation and interaction within your information architecture of your website or game is a very hard challenge. “Uh, if I just had a good place to put that invitation feature somewhere in my UI..”. If you are a web designer or developer, chances are you shared a similar frustration before. But wait! Thankfully, there’s an easy way out. Just take the feature and pack it in a dialog! That way, we don’t have to clutter our UI and can hide certain features, bring them up when needed. …right ?

Let’s turn it the other way around to see what’s going on here. By using a dialog, lightbox or overlay, you are effectively cheating. The content in your dialog will not fit into your centralized user experience, and remains disconnected. Your users have a harder time to relate to features in lightboxes. Even worse, modal dialogs often break one of the most important rules of great user experience: Never block the interaction of your users an your product.

Dialogs are the new popups. So the next time you are setting up a dialog, take a break and think about a better integration.

What is Progressive Enhancement?

First, let’s discuss what I’m actually talking about. Progressive enhancement is a programming concept that simply says you should start building your product or website with the “Lowest common multiple approach”, so it runs in browsers like Internet Explorer 6 or with JavaScript disabled, and then continue to enhance functionality, interaction and UI for more capable browsers, devices and users. When well executed, this means that your site is targeted and usable by a maximum audience.

..but isn’t this awesome?

Indeed it is! That’s what’s great about progressive enhancement. It makes sure your website runs on every device or browser if executed well, which is definitely something admirable. It also has a multitude of positive side effects – such as possible accessibility benefits and it is really well suited for a junior programmer, as it teaches the layers of a web app in a direct way. … so what am I complaining about?

PE limits creativity

My first thesis is actually very easy to explain and to follow. So you’re a student of a famous painter, and you’re learning how to draw basic forms. After the art class, the teacher decides to draw something in front of the class to show off his skills. Unfortunately, all canvasses are used by the class, so he has to pick yours and paint on top of it. I’m pretty sure he succeeded in making it awesome based on your painting, but what if he had a clear white canvas to start with?

I’m positive that most people will come to my conclusion that the second painting would have been truly his, unleashing all his creativity. The situation is, as you might imagine, extremely similar with progressive enhancement. Since you always improve upon the lowest layer of your implementation, you’re not inventing new user interfaces, new metaphors or interactions – you’re merely improving the old ones. Even more unfortunate is the fact that we accepted to live with this fact. It is pretty likely you wouldn’t even have noticed this if you didn’t read about it here.

So we want to start drawing on a clear white canvas. Wouldn’t Graceful Degradation fit the bill?

Graceful degradation

Graceful degradation is basically the opposite of PE. It says “start on a free canvas and build crazy shit, then make sure it runs in less charming situations”. While in theory definitely a great improvement to PE, it doesn’t always work out, since there are many complex UX patterns and ideas that cannot be reproduced easily in a lower metaphor. In general you could therefore say that it also simply requires a lot more time than PE. That being said, I still use GD to a great extent in many of my projects, and I’m pretty happy with most outcomes.

You are the problem!

Uh well…not personally. Let me explain: I fully endorse the concepts of Progressive Enhancement and Graceful Degradation. In fact, PE for instance is a vital concept for jQuery UI to follow and implement. The real problem comes with the usage. Web developers misuse PE and GD to a great extent. And it is very easy to follow the wrong path if every “Best practise” powerpoint slide tells you to always follow PE. Let me make that crystal clear: “Always follow” = guaranteed misuse of PE.

So what? I should just screw IE6?

Actually yes, you should screw IE6. …errr, let’s start over: First off, in many instances, you will never need an alternative. If you’re targetting iPhone Safari as platform for your web app for instance, or if you’re working on an intranet application to be used with only a single browser. However, there is a great alternative to PE & GD: Instead of adding layers on top of your current site or app and let it become a big fat hard to maintain blurb, how about developing a second client? I will argue that it doesn’t take longer than the GD approach, and quite important players have done so: Gmail, anyone?

The bottom line: Start thinking!

As mentioned, it is really not a problem of the concepts themselves, but of how they’re used. If you’re reading this, give it some serious thought and start thinking yourself. Think back in time and look at the projects you’ve done so far. Is there a chance to improve your workflow by not following every best practice advise blindly? I bet!

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

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!

Finally I can present you one of my newer interface experiments that has grown to something quite nice in the meantime. With the transition from small movieclips to longer and bigger full length flicks, sites like Youtube still don’t really get the idea that the movie player has to give the user space, feel a bit like a theater for a overall greater experience. What we still receive is a bloated page with thousands of comments below, tags and whatever – things the user really doesn’t need or want to see while watching. This is why I started a new experiment – building a movieplayer for the web that doesn’t suck.

Shows only what’s needed

The first idea of the interface was that everything that’s not required during movie playback will simply not be visible. This effectively means that if the video is playing, nothing else should be shown. Under that requirement, I thought it will also need at least movie information somewhere, and a search interface.

The Uberplayer has slide-in elements for controlling the video. Every function or visibility can be controlled through either the mouse or the keyboard. At initialization and pause, all controls are automatically shown, since you’re not focussing on the video. During video playback, move your mouse towards the bottom and the search slides in – move it to the top and you’ll see current video information and the search bar.

Coverflow

I can also proudly state that this is the first time I actually integrated my experimental Coverflow plugin into an actual application. After you entered a search term and pressed return, the bottom view slides in and presents the search result thumbnails in a really nice flowing coverflow like view if you are using a webkit enabled browser. If not, don’t worry – the fallback looks nice nontheless! Additionally, the click-through rate is minimized by switching coverflow states on mouse over – clicking opens the new movie.

Integration with Youtube

I choose to integrate with Youtube because it allows me to do searches to their API’s through their JSON API. What does that mean? It means that the Uberplayer is completely backendless, therefore doesn’t need any server software / logic. It’s all JavaScript, baby!

The second reason was that Youtube has a nice chromeless player, which worked really well for my kind of interface. The only drawback is that the chromless player doesn’t support HD playback at this point, but I hope they’ll give us that feature eventually.

Feature overview

To get an idea, here’s a quick walk through all features that are probably worth mentioning and explain how the player works.

• Full-screen playback at all times (toggle full screen mode on your browser for a better experience)
• Fluid slide-in interface (move your mouse towards the bottom or top to blend in controls)
• Click on the video to toggle pause state and blend in all controls
• Rich keyboard interaction
  • ‘down‘ toggles the search results view
  • ‘up‘ toggles movie information and search bar
  • ‘space‘ toggles pause state
  • ‘s ‘ focusses search bar and let’s you type in a new search (‘escape’ cancels)
  • ‘left‘,’right‘ let’s you navivate through search results when the search results view is active
  • ‘return‘ opens a new movie when the search results view is active
• Automatically generates hash urls that you can bookmark or send to someone – they will not only open the movie, but also the attached search results
• Completely backendless through Youtube’s JSON API

What’s left to do

This is a very early preview release, so please be merciful. Some things I would like to do for the next version is a playlist manager (sliding in from the left), and if I only could get access to a chromeless Vimeo player, that would totally kick ass.

Anyway, check it out, and leave a comment!

What’s it all about?

For real people to actually use your application in daily life, it’s not enough to bundle it with a nice UI and a bunch of cool features, it has to be really responsive as well. The reasoning is simple – people hate to wait. People hate to wait in
lines (except the British, hehe), they hate to wait for their salary, they hate to wait for the weekend to arrive and they
hate to wait for the next season of their beloved TV series. Ok, sometimes the anger can transform into excitement (and vica versa) – but raise your hopes too much, this seldom happens in the case of web apps. Yes, people hate to wait after the click.

Responsiveness is often described by how quickly an application reacts upon a user triggered action. Basically everything we do in the web is interaction- the website or application waits for an user action and then replies. There has been already a lot of research on today’s topic, concluding for instance that people already get the feeling they’re waiting if the result doesn’t come up in less than 0.5 seconds. But the answer to the problem is the tricky bit.

The obvious solution: Performance optimizations

Many of todays apps and websites are Ajax driven, to the extend that a user initiated action triggers a request to the server. This is why the most obvious solution coming to mind is to improve the time each request takes. Be careful though – this is also exactly why responsiveness is so often forgotten in the frontend planning. People tend to think of it as something non-visual, therefore they let the backend guys do the work.

Now after you speeded up the requests and your backend, you have to take the frontend really serious. The JavaScript powering your website is often the most visible bottleneck because it’s directly happening on the client, even before any backend request can happen. And it’s not only JavaScript – heavy usage of CSS Frameworks (especially resets) for instance can horribly slow down any application as well. Remember – if your frontend performs bad, the backend guys don’t even have a chance to make up for it. Of course I could go into detail how to actually optimize your code, but that’s content for another blog post.

Transparency and disguise

In the last couple years I noticed a general pattern when designing a responsive experience. There are essentially two ways to tackle it: The first is total transparency – the user should never be clueless, and if the application is in a loading state, tell it to your user so he doesn’t get annoyed too much. The second, and to me the one with almost unlimited potential is illusion.

Fixing the experience without fixing the implementation

Something only very few people I met realized is that an application can be improved even without fixing the implementation. There is really only one thing that matters to the user – how the application feels. Yes, let me repeat that: Your implementation doesn’t have to be responsive – it just has to feel that way.

Apple – masters of illusion

The best way to describe what I mean by making your application *feel* responsive is through a perfect example. It’s the best illusion of responsiveness I’ve seen so far. I’m talking about the iPhone.

The iPhone runs a very sophisticated operating system based on Mac OS X, with thousands of API’s for developers to use. Combined with the fact that the iPhone isn’t running particularly fast hardware (more than a standard cellphone, but way less than any netbook), simple performance optimizations could only get you so far here, and this is is where the magic comes in.

Almost every interaction on the iPhone uses an animation to transition from one state to another. You’ll see animations when you launch or quit applications, when you slide through screens and on many other instances, sometimes so tiny you don’t realize it. Since they’re very well integrated into the general flow of the interaction, they not only excite users but serve as visual cue helpers that let the user ‘grasp’ what’s happening. But the key is what happens during the animation: Any application you launch or close on the iPhone needs time to initialize and to de-initialize. You guessed it already: It’s all done when the user is distracted by a beautiful zoom effect. How cool is that?

As a summary: At the cost of slowing down the operating system in technical terms (every animation takes a fixed amount of time), Apple improved the whole user experience and made the iPhone feel extremely responsive .

Loading indicators

As a conclusion to the illusion technique, in 90% of all cases a loading indicator is evil. Why on earth would you want to highlight the slow parts of your application? That being said, a loading indicator is always better than a frozen state and a clueless user. As a general rule, only add a loading indicator to your application if all other improvements fail. For instance, there are situations where you absolutely can’t predict when the result will arrive. Imagine a multiplayer game with two players, and you’re waiting for the other player to select his character. In this case you have to notify the user that the game is waiting for a response.

See you next time!

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.