Smart things
Smart lists of various kinds are not new to Tiger, but they’re ever more important.

Say you’re a developer and you’re adding a smart something to your app. So you take a look at what other apps do.

iTunes...

Mail...

Finder...

The Rules

Here’s what you the developer can conclude...

1. Smart list creators must appear in a separate modal window. Or in a sheet. Or not in a separate window at all.

2. They must have + and - minus buttons that are, well, consistently round.

3. They must use large popup menus. Or small ones (even if the other controls are large). Or they could use a custom popup menu control that looks really, really cool.

4. The background of the rules should be a dark gray. Or, no, they should be alternating colors: blue, then white. Or, no, they should be lighter blue then darker blue.

5. The box containing the rules should have rounded corners. Or not.

6. A smart list creator should have an OK button that saves it. Or it should have a Save button.

7. A smart list creator must give you a place to set its name. Or not.

8. A smart list creator should give you the option to choose between matching all or any of the criteria. Or not.

P.S. A really cool innovation would be a consistent user interface for smart thing creators.
09:11 pm #

The inexplicable pressed state of the round textured button
Everyone’s familiar with Safari’s cool buttons, right?

Here, for example is the home button—first in normal and then in pressed state. Note how it highlights in blue. (Why it doesn’t highlight in graphite if you’re using graphite I won’t try to explain, because I can’t.)

If you look at Tiger, you can see this same button style used in lots of different places: System Preferences, Dictionary, Finder, Help Viewer, Address Book, Font Book, and so on.

So I was checking out Interface Builder in Tiger, and I see that Apple has now provided this as a standard button type—which is very cool. Here’s a screen shot from Interface Builder:

This is how things should work, I think: some folks on an app team come up with a new button, it stands the test of time (people like it and it’s usable), other apps adopt it, and it becomes a standard button type available to any developer. I’m all set to applaud, in other words.

First, an explanation

It’s not necessary for Apple to make a certain button type available before developers can create buttons that look and feel exactly the same way.

There was never anything stopping anybody from making buttons that look and feel the same as these Safari-type buttons.

Making custom buttons isn’t hard: you just need to create images for the buttons. (Sometimes you have multiple images, of course: normal, pressed, disabled, sometimes mouse-over, and sometimes graphite variants of the above.) You may need to write just a little code that says how the button should behave (does it toggle between two states like a checkbox, or is it like an OK button, that kind of thing).

But when a button type becomes a standard, then it’s slightly easier for a developer to use, because you just need to create the icon that goes inside the button, and you don’t have to deal with the extra stuff.

More importantly, it means that this button is now considered part of the OS X user interface, and you can use the button with confidence that you’re being consistent. (Presumably there is also some documentation that says when and how the button is best used.)

Blue, we must have blue

So after dragging the button to a window in Interface Builder, I “ran” the window to see the button in action. I clicked on it. It looked like this when pressed:

Looks good, right? A nice “pressed” look.

But see the problem? It’s not blue.

It’s not blue, so you can’t use it

Here’s what would happen were you to release an app that uses this button. Users would report it as a bug that the button doesn’t turn blue. They’d point to some of the many different apps that use this same button, and say, “See? The standard on OS X for these buttons is that they’re blue when pressed!” The users would be absolutely right.

So then you have to go back to the custom method of making images for each of the states and perhaps writing a little code to get the behavior right. Not hard, but you’ll have to do it.

But now you’ll wonder why you have to do it, when this button exists as a standard button type in Interface Builder.

How did this happen?

I don’t know.

The worst-case scenario is that the policy is to give developers some cool widgets, but don’t make them the same as what Apple uses—make it so developers have to jump through some extra hoops.

I don’t believe that scenario—it’s rather paranoid. I mention it because I’ve heard it from other developers.

My guess is that, simply, it’s an oversight, just a mistake.
07:02 pm #