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!
shre forever after

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 ever 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.