The good

JavaScript performance. I’m curious to know how they accomplished this (JIT compiler?) but I’m happy it’s here. More and more, client-side JavaScript is becoming something that can do heavy lifting.

Tabbed browsing. The weird tab/title bar doesn’t appeal to me, but I can see its value. To me, the window needs to feel like it’s a container, and the tabs just screw that up for me. But the space savings is nice.

Better keyboard navigation. Greatly appreciated by those of us who fill out forms on the web. Which is to say everyone. turns out they had this in Safari 3.

Better hints for location bar. Much better! The hints now work kind of like spotlight. Type stuff into the URL bar, and Safari will do its best to find a matching URL from any source it can think of (history, bookmarks, etc). The best guess is shown first (like Spotlight) and the rest are categorized. Problems: The location bar doesn’t seem to handle page titles, which is a shame. Also, if you mistype a URL and get a 404 or other error, it still shows up in history and can end up as the “top hit”. Uh… whoops!

Embedded web fonts. It’s great that Safari is doing this. However, to be realistic (a) more browsers need to support this, and (b) someone needs to sort through all the legal issues having to do with font embedding.

The meh

CSS animations. Back in 97, I was one of the folks working on the first version of Dreamweaver. At that point in time, the Netscape folks were coming up with new tags all the time.

When we told the Netscape folks that we were going to add a timeline to Dreamweaver to take advantage of the <layer> tag, they were surprised and happy. You see, the inspiration for the <layer> tag was this question: “how can we have the browser do the things that the Shockwave plugin does?” Fast forward to 2009 and replace “layer” with “CSS animations” or “canvas” and replace “Shockwave” with “Flash”.

My opinion on all this? Meh. If you want to do everything that Flash does, use Flash. Or invent something radically new that blows HTML out of the water. Don’t bother bolting that stuff onto HTML/CSS.

In fact, if you’re going to bolt stuff onto CSS, focus on getting the basics of static presentation right. CSS layout is still incredibly difficult (way harder than tables were). You have to do hours of Google research just to get a usable two column layout.

Top Sites. The top sites UI feels overly glitzy to me, and for no good reason. The slightly curved appearance implies (to my eye) that I should be able to rotate my view to the left and the right to see more sites. Which you can’t do, as far as I can tell.

Bookmark Sidebar / Cover Flow. I like Cover Flow, but it’s getting to the point where I can’t tell the Apple apps apart. iTunes has a sidebar on the left, a list of stuff on the right, which can include a Cover Flow view and a list below. Same with the Finder. Same with the browser. Same with…

Maybe I’m just thinking about this too abstractly, but it bothers me that so many of the Apple apps are starting to feel the same as each other. Not so long ago, iTunes was different than the Finder, which was different than iPhoto. Now, you have cover flow in the Finder and with Quick Look, you can play the song right from there.

So I don’t know. I’m kind of torn. Consistency is nice, but too much consistency leads to every single thing looking exactly the same. It feels a little bit like MS Windows UI right around when XP came out. Tree views were pretty general, and a lot of applications fit into the pattern of “tree view on left, detail view on right”, so that’s what everyone did.

Maybe it will grow on me. Or maybe they’ll iron out the kinks. (single clicking on a bookmark in the sidebar doesn’t navigate you to the page. It shows you a “category” with a single bookmark in it. Double clicking on the bookmark in the sidebar lets you rename the bookmark. The only way to navigate to that bookmark, as far as I can tell, is to click on the bookmark, and then click on the image of the website in cover flow, or else double click on the bookmark in the bottom pane below cover flow. I mean… cover flow is pretty, but isn’t single clicking a bookmark more important?)

The WTF?

Color profile support. They claim to be the first only one to support this, but doesn’t Firefox already do this? Is the issue that it is turned off by default? Or does Safari handle colors in a significantly better way than Firefox?

Apple is the design expert, right? So this UI has got to be, like, awesome, right?

Now take a look at this screen.

What do you think happens when you follow these steps:

* click on “edit information” underneath the 1.1 version of Notespark
* set the “availability date” to 1/29/2009

Possible answers:
A) It sets the availability date of version 1.1 to 1/29/2009
B) It sets the availability date of BOTH version 1.0 and 1.1 to 1/29/2009

If you guessed (B), you are way smarter than I am. And because 1/29/2009 is in the future, it immediately removed version 1.0 from the iTunes App Store. ARRGGHHHH!!!! Setting the date back didn’t seem to help any.

Let’s just hope the app comes back tomorrow.

[Late update] Yes, the app is back. Whew!

UI for editing homepage — the jiggling icons on represent.. what, exactly? Does this really feel natural to anyone? Is the idea that they needed to have some way to represent “edit mode” without occupying screen real estate?

Moving the “+” button on Safari down to the bottom toolbar is a nice touch — it lets you add bookmarks without scrolling to the top of the page. It would have been even nicer if they allowed you to access the URL bar without scrolling. (I sometimes find myself on webpages with hundreds of comments on them. Scrolling up to the top to access the URL bar is AWWWFFFUUUULLLL!)

The new location feature for maps is awesome.

The installation failed with the cryptic message “The file flashplayer.xpt could not be written.” This message could have been more helpful, but that’s really Adobe’s fault, not Apple’s.

I tracked down the problem to the fact that Firefox was installed using the “skuwamoto” account. Meanwhile, I was trying to install Flash Player using the “household” account.

So I decided to change the owner of Firefox to “household”. Easy, right? Guess again. Changing the owner of an application turns out to be kind of difficult.

~

I started by changing the owner of the file using the info dialog like so:

The install still failed. Take 30 seconds and try to guess why.

Ok. Being a software developer, I knew that applications were really “packages” which are a special kind of Unix folder. If you do a “show package contents”, you find that the Firefox package only contains one folder:

And after doing a “get info” on the folder, I found that the package contents still had “skuwamoto” as the owner. ARRGGGHHH!!!

Why on earth would you want to set the owner of an application without setting the owner of the enclosed folders?? Also note that the original info dialog had no option to “Apply to enclosed items”, so even if you knew that this was something to watch out for, there is no way to fix this without manually opening the package and inspecting the contents.

I mean… I had trouble figuring out what was going on, and I write software for a living.

What I love about this application is that it opens your mind to what a Flex application can look like. It looks deceptively simple, but there are some interesting UI thoughts behind this app. One innovation is that the navigation area serves double duty as an editing bar, saving screen real estate. Another is that they have really paid attention to how you can get your work done without losing data. If you leave the app and come back, you will end up in the same state, editing the same document. If you go into “creative tools” mode, you get multiple steps of undo.

I love seeing this kind of experimentation with Flex UI. Remember that HTML became what it is today after fifteen years of innovation. Flex 2 has been out for less than a year. These are still the early days. Those of us in the Flex community don’t yet know what this technology is capable of.

So I was playing around with the sliding drawer components recently, and it reminded me of two things: (1) Sometimes, good usability design is so subtle than you don’t notice it until it goes wrong, and (2) Fitts’ law is real, even though I’d previously dismissed it as a bit silly.

~

Good usability is sometimes subtle

I remember reading an anecdote about the design of the chooser in the Mac OS. In those days, the chooser looked something like this:

The chooser dialog would come up instantaneously, but the list of printers would take some time to fill up, based on the speed of your network. What UI issues would you consider if you were to implement this? Your average UI programmer might not think twice about how to implement this, but there was some subtle thought put into how the programmers over at Apple thought about this problem.

Let’s say that a new printer needs to be inserted into the list above the portion that was visible. (alphabetically before dmca_laser1 in this case). In these cases, the scroll position would be adjusted so that the visible contents of the list would not move.

Sometimes, these subtle details matter.

Why go through the trouble? Well, if you were about to click on a printer, you don’t want to end up clicking on the wrong one.

Now, what happens if a printer needs to be inserted into the visible portion of the list? Whether you adjust the position of the scroll bar or not, some things on the screen are going to move.

What the Apple engineers did was to detect the position of the mouse and adjust the scroll position to make sure to that the item beneath the mouse did not move.

Tweaking the sliding drawers

In my first implementation of sliding drawers, there was a bug in which if a drawer was open when the mouse moved off the screen, the drawer would stay open.

NOTE: Requires Flash Player 8.5 beta 3.
[Sliding drawers 1: drawers stay open]

Someone commented on how they were annoyed by sliding drawers remaining open in Visual Studio, and this feedback rang true. What if you have important content on the screen that would be hidden by the drawer? What if the drawer opened up and stayed open every time you moved your mouse off the browser? The more I thought about it, the more it sounded like a problem.

As a result, I tweaked the sliding drawers to close once the mouse left the browser window. This resulted in the following. Try it out. Move your mouse to the edges of the browser to open the drawers. Be sure to un-maximize your browser window to witness the true horror. And pretend you are in a hurry and need to work fast.

NOTE: Requires Flash Player 8.5 beta 3.
[Sliding drawers 2: drawers close on exit]

Ack! Instead of being better, the drawers feel much, much worse. Why does this “improved” version feel so bad? The answer lies in Fitts’ law.

Fitts’ law

I’d always thought that Fitts’ law was a bit silly. I first became aware of it during the mac/windows flamewars on USENET, in which people claimed that Macs were superior because, among other things, the menubar was on the top of the screen, and thus easier to aim for with the mouse. While undoubtedly true, it always seemed like a weak argument (and at the time, I was a rabid “mac guy”). Was this the only leg that us mac guys had to stand on?

Fitts’ law says that bigger things are easier to reach with the mouse than smaller things, and the farther away the thing is, the more this matters. To which, you might say “duh”. In the case of the mac menubar, the argument was that because it was at the top edge of the screen, it was essentially inifinite in size; you can fling your mouse as far as you want upward and hit the menubar.

Because of my earlier bug, in which the drawers stay open when the mouse leaves the browser window, I essentially had an infinite hit region for the drawers to open. “Fixing” the bug made my hit region very difficult to navigate to with the mouse.

There are a variety of ways you could imagine fixing this, but I decided to restore the original behavior, and add a timer to close the drawer if the mouse stayed outside the browser window for more than one second. Like the chooser example above, it’s not something I would have thought to do ahead of time, but after trying it, it makes a huge difference. Check it out for yourself.

NOTE: Requires Flash Player 8.5 beta 3.
[Sliding drawers 3: drawers close on exit, based on a timer]

Meanwhile, text fields that offer completion hints are starting to become standard for Flex and AJAX applications. Typicaly, these are used to let you quickly pick things that you’ve already typed into the box. They are not used for picking, say, a country from a list of countries.

I believe text input fields that offer hints for possible completions should be used instead of combo boxes 95% of the time. Down with combo boxes!

1) When you want to use the mouse, it is just as simple.
2) When you want to use the keyboard, it gives you better feedback on what you have typed already.
3) It gives you an obvious affordance to “start over” when you’ve made a typo.
4) It gives you more immediate feedback.

Here is a relatively simple version of a text completion control for MXML. Unlike most versions of this type of control, this is also optimized for the above case: picking from a list of predefined strings.

[Sample removed. Please download the new version instead]

When you want to pick from a list of predefined strings, just supply the list of all strings as the dataProvider of the control (just like how ComboBox works), and set the “mustPick” flag to true.

Let me know what you think. Are there bugs? Do you think the heuristics are wrong? Is this a good idea in general?

P.S. I’ve also had to include some other random classes as part of this. I plan on officially distributing these classes and other classes once they are more baked.