Because I was using jQuery in the animation, I decided to first try using jQuery’s .data() utility, which allows you to attach custom data to any jQuery object, by doing something like the following $('.item').data('rotation-x', 30);

Next, I tried creating each animated item as a Javascript object, and storing the values in the object itself, such as item.rotation = {x: 30, y: 45, z: 90}

To more accurately test the performance difference between these two approaches, I used jsPerf, a fantastic Javascript performance-testing website.

The results were pretty staggering. Storing and updating the animated properties through a Javascript Object is literally 100% faster than updating them using jQuery .data(), performing more than 100 million operations/second versus less than 100 thousand.

In fact, the difference is so great that you can’t even visually represent it on a bar chart. And it shows in the actual animation as well. Most experienced Javascript developers probably won’t be surprised by this, but beginners may find this helpful. I, for one, won’t be using .data() anymore when performance is at all critical.

More information on using these CSS Properties is available in the Safari Reference Library.

The benefits of animating this way are: no reliance on Flash or other browser plugins, exists in the CSS presentation layer so everything degrades nicely for browsers that don’t know how to handle it, and extremely simple syntax for attaching animations to things like adding a class or hovering an element.

That’s all well and good, of course. But this means nothing if performance is terrible. I have read complaints that WebKit animation is as much of a CPU hog as Flash, so I decided to do some simple experimentation.

The following example contains 70 DIV elements. Each DIV is styled using CSS to give it a Width and Height of 100, and one of two gradients. No images, everything is created using CSS. Every 1.5 seconds, a Javascript call runs through each of the 70 DIVs, giving each one a random new X and Y position, as well as a random Rotation. WebKit CSS transitions automatically perform the animation over 1 second every time any properties change. To view the example, you must be using Safari 4 or one of the WebKit nightly builds (the latest version of Google Chrome may work, as well).

I was very impressed by the fluidity of the animation. I never would’ve expected this kind of full-window performance out of a browser. Surely, this must be chewing up the CPU like nobody’s business, right? Go ahead, open your Activity Monitor. On my machine, it sits around 20.5 percent CPU use. That’s definitely not negligible, but it sits far below the near 100% CPU use that the Flash Plugin often requires. Maybe someone else could tell me whether 20% CPU is acceptable or not?

So then I decided to try it on an iPad and iPhone. In both cases, nearly flawless performance. Just a smidge slower than on a computer, but still very good. Unfortunately, CSS Animation and Transitions are only available via WebKit, but similar implementations will be available in FireFox 3.7, I believe. And in Internet Explorer… never ever.

It is difficult to overstate how much this last move hurts Adobe. Not only does it mean that their cornerstone feature in Flash CS5 is dead-on-arrival, but that their Flash & Flex customers still have no way into the most popular app ecoysystem of today.

Since the beginning of the Apple-Flash controversary, two hard-minded camps have developed. On the one hand, standards-minded developers and designers have applauded Apple’s brazen attack on Flash. They usually cite the poor performance and instability of Flash, as well as the ability for upcoming HTML5 and CSS3 technologies to replace Flash interactivity, as key reasons why the internet would be better off without Flash.

In the other camp, we have designers and developers who use Flash to bring high-end interactive experiences to 95% of internet users, without any of the meticulous cross-browser debugging required for typical, standards-based websites. In addition, Flash makes a level of interactivity experience possible that will remain unmatched by even the newest standard technologies for the next 5 years (give or take, depending on how quickly Internet Explorer catches up).

I agree with points on both sides.

Let me first set aside pragmatics: Flash is capable of creating the richest, most expressive, creative experiences available on a computer. No question about it. If I were to create a list of every website I’ve ever visited that created a profound, emotional, lasting experience for me, every single one would have been created in Flash. It’s so easy to decry Flash as an easy way to create superfluous visual nonsense. But take a hard look at the good things Flash has done, as well as the bad. Are there plenty of terrible Flash websites? Yes. Are there plenty of terrible websites, in general? Of course.

Flash simply makes things possible online that are not possible otherwise. Not just difficult. Not just slightly less interactive. Flat-out impossible. It’s sad that, as far as web technology has come, we have no way to create the highest-end interactive content without one specific tool made by one specific company. A web without Flash is, in an interactive and visual sense, a web with fewer possible experiences.

Now my reasoned, rational response to Flash: Adobe has done a fairly poor job of managing Flash. I’m quite experienced with Flash and Actionscript, and I can say that I really enjoy Actionscript as a language, but almost every other aspect of Flash implementation is crap. The actual Flash IDE is a mess, and Adobe has done very little to improve it since acquiring it from Macromedia back in 2005. It is buggy, crash-prone, and the interface is a curious combination of current Adobe app conventions and Macromedia hold-overs.

The real issue, though, is the bugginess and instability of the Flash plugin. At best, Flash uses far too many CPU resources and runs terribly on Mac OS X and Linux compared to Windows. At worst, Flash has been cited as the number one cause of browser crashes. If Adobe knew what was good for them, they would focus every resource they have on transforming Flash into a lean, performance-focused technology. Perhaps they have been doing so, but it doesn’t show as much as it should. Adobe, we don’t need a Deco Tool, for God’s sake. Fix the IDE. Fix the plugin.

I always weigh the pros and cons before using Flash for any reason, on any site. Now, with Apple distancing themselves from Flash entirely, I have another reason not to use Flash. I don’t think, as many do, that Flash is going to go away any time soon, but as Apple’s market-share grows, and as other browsers begin to adopt the high-end features currently only available on WebKit, Flash use will continue to shrink. I can’t help but feel a little bit sad thinking of a world where technology once again limits our creativity, but if that is what the collective web wants, I will do my best to comply.

The Complexification Gallery of Computation is home to a series of small computer programs that you can watch create incredible things before your eyes. If you only view one of these, I think it should be Substrate by J. Tarbell. Oh, oh, it’s magic.

Complexification Gallery of Computation

He has always seemed to me like the type of guy who is really keen on the theory of information design, but not very much in touch with how information design is playing a role in modern technology. How wrong I am. Tufte’s “blog” recently featured a short post critiquing info design in the iPhone, and even features a movie (narrated by his info-ness).

The movie is short but sweet. Tufte emphasizes many of the insightful decisions made by the iPhone design team, and points out some possible areas of improvement. He correctly states that while most of the iPhone screens are pretty to look at (stocks, weather, etc.), they waste a fair amount of space, and lack any means of digging deeper. Right on, Tufte. Great quote: “Clutter and overload are not attributes of information, they are failures of design.”

Ask E.T. (Tufte’s Blog)

Interface Design and the iPhone, by Edward Tufte

In no particular order, here are the chief offenders:

1. The Dock

The thing I expected to hate the most is the thing I hate the least. The reflective shelf dock. The dock itself isn’t absolutely awful, but components of it definitely are. For one, the automatic shadows that Apple has chosen to add to every dock icon do feel weird and unnatural in all but a few cases. The small arrows under each running dock application have been replaced by small glowing lights, which look bad and are much more difficult to see than their predecessors. The line that divided the documents/folders area of the dock from the applications has been replaced by a weird cross-walk looking thing that looks rediculous and unrefined, especially for an Apple product.

If you don’t like the new appearance of the dock and/or you like the dock on the sides of your screen, the dock appearance changes. However, the appearance doesn’t change to the old dock appearance, but instead becomes a “new” dock style with a dark background and white outline. There is nothing redeeming about this new side-dock style. It is flat-out ugly.

The biggest problem with the new dock is the new Stacks feature. In Tiger, when you dropped a folder onto the dock, you could then navigate through the folder by right-clicking (or control-clicking) on it. This was a great feature, and made finding files often much faster than using the Finder. This functionality is completely gone, replaced by Stacks. Let’s say I wanted to put my Application folder on the dock, so I had convenient access to all of the applications that I don’t use often enough to just drop on the dock. This used to be a great idea. Now, with Stacks, it doesn’t work. The “fan” mode of stacks can only display 12 items at a time, and the “grid” view makes it very difficult to pick out one icon in a sea of thirty.

Why, oh why, did you do this to me, Apple? Why couldn’t you at least let me set folders to be viewed the old (better) way? WHY??? I consider this criminal negligence on the part of Apple’s interface designers, and I won’t be a happy camper until this problem is addressed.

4. Window Styling

Apple has finally found a consistent window style to stick with across all windows and applications. Unfortunately, it isn’t that great of an appearance. Now I’m going to start nit-picking (as if I wasn’t already).

The new window style is solid grey with a vertical gradient to it. I think it might be a little too dark, but if it weren’t for other issues it might be okay.

Now, this next item just seems like laziness. The small icons at the top of the finder window are too close to the bottom of the window frame. They should have about the same amount of space under them as they do from the top of them to the close/max/min buttons. This is certainly being picky, but every detail should be considered, and this comes across as sloppiness.

Even the close, minimize, and maximize buttons in the top left of every window are uglier. They have have an overly-glossy appearance that I’ll probably get used to eventually, but for now I don’t like it.

2. The Menu Bar

This one will be much shorter than the last. The new semi-translucent menu bar was a horrible idea from the beginning. Almost everyone outside of Apple realized this all along. I’m sure Apple received hundreds of emails from developers and Apple-enthusiasts begging them not to do this, or at least give us the option to turn it off. They ignored all of that. The new menu bar does not look better, it looks worse and makes it more difficult to read. Period.

3. New Icons

For a long time, Apple’s icon design has been some of the best in the industry. Somehow, however, this previous success has been derailed with Leopard. The new folder icons are flat, boring, and in the case of the User Folder standards (Desktop, Documents, Library, Movies, etc) now don’t tell you anything about the folder contents unless you view them at an unusually huge size. Again, I’m not sure how this happened. Maybe Apple is slipping, maybe all of their talented GUI designers were busy with something else?

The other icon that I’ve noticed a major change to is the “System Preferences” icon of dock fame. I loved the old system prefs icon, wish they would’ve kept it forever. I hate the new icon. Hate it. It might look fine on an iPhone where that is the predominant icon style, but not in my OS.

These are just the things I found in the first 20 minutes of using the new OS, and they frustrated me enough that I actually stopped playing with Leopard to write this post. Granted, some of these things I’ll get used to. Some of them I won’t, and they’ll continue to drive me crazy until either Apple fixes the problem (unlikely) or a third-party developer does (incredibly likely). However, I don’t believe that we should have to rely on third-party developers to fix Apple’s mistakes, and I believe that Leopard represents more user interface mistakes than any previous version of OS X. I’m sure I’m not alone on this.

Enter Shiira, a relatively new browser contender that just recently reached it’s 2.0 release. The Shiira philosophy seems to be, “What if Apple would have taken Safari the extra mile?”

DESIGN
The icons and interface of Shiira are pretty much perfect. Not overwhelming, but not too bland. No brushed-metal interface, but just as carefully thought-out as Safari. My only gripe is the application icon. It succeeds in conveying the Japanese origin of the application, but I really don’t like having a huge fish sitting in my dock. It’s really too bad, if they would’ve just used the “big wave” portion of the icon they could’ve had something unique, appropriate, and attractive. Just saying, is all…

USABILITY/FEATURES
Shiira incorporates some of best features from other browsers I’ve used. One of my favorite features in OmniWeb was the “Page Dock”, which works the same way as Tabs, but shows a small thumbnail image of the pages instead of just a name. I often have 5+ web pages tabbed at the same time, so having a quick visual presentation of them makes them easier to find and access.

The bookmarking options work just as you would hope and expect. Easy to access, easy to save, and easy to modify.

The “View Source” options in Shiira are great for web developers, allowing you to easily view HTML, CSS, or Javascript.

There is even a full-screen mode, which I very rarely use, but could be very useful if you found a great design site that you wanted to immerse your self in fully, or even for setting up a demo machine for your own web site.

THE KILLER
In the two days I have been using the 2.0 build of Shiira, I have had 4 random crashes. In all of my time using any other browser, I can remember very few crashes (and even those were caused by sites with some crazy javascript setup). It is inexcusable for a browser to crash this often for no good reason, especially since Shiira is unable to remember your last browsing session when you open it again. Shiira developers, please fix this. Fast. I love your browser, and if you go just a few steps more to make it more stable, you will have a convert.

Shiira Macintosh Browser

On-Purpos, Inc

For everyone that I’ve been neglecting while I get settled into my new job, I apologize.

I also found an interview with Mr. Norman on NPR’s Radio Times. Its a free podcast, what’s not to like?

Tango Online Tax Preparation

NPR Interview with Donald Norman

Donald Norman Website