Google frustrates me by highlighting in their products some of the best and worst of web usability.

Consider Google Maps, which won me over instantly when I first tried it, almost entirely because of the innovative (then) “drag to scroll” behavior you can rely on whenever you see a Google map.

They won me over with a usability boon, which means I suffer through the usability gaffes. I often use Google Maps to locate businesses or other points of interest in whatever area I happen to be in. As luck would have it, the nature of businesses is that they cluster in one place. These are what our parents, who actually left the house, called “town centers.” So if I search for restaurants, I’m liable to see results like this:

This particular map was actually sent to me by fellow Boston-area Mac developer, Paul Kafasis. He was pointing out some local restaurants I should try. But this problem is not unique to this map or even rare. In fact, often the pins line up even more perfectly, so that you literally can’t tell there are more than one at the location.

Google has tons of real-estate to work with here, but to find out what’s actually at the cluster point, I have to go back to the ugly list and click items to see where they pop up in the map. With all that space to work with, surely Google could come up with something better.

The peacock approach would work to at least allow several places to show up at one spot, yet still be clickable. The directionality of the pin makes it clear that they’re all referring to the same point.

Of course, it could get complicated if nearby pins overlap with “the peacock.” Perhaps a “drop-down pin point” would be better, clearly identifying a multi-hit location with a different color and interior shape:

Surely with a feature that is so central to the map’s usefulness, Google can come up with something that improves on the current behavior.

Black Ink 1.0.4 includes a number of fixes to the multiple character support of the application. In particular there were major problems with Undo and with revealing answers, when multiple letters were present. Thanks to a dedicated Black Ink user for bringing these problems to my attention!

Anybody who’s solved a lot of crosswords is familiar with the fun games puzzle authors like to play. Sometimes a clue will contain a play on words, or sometimes an answer will contain an especially creative spelling of a word. I recently came across a clue for a type of running race. As I filled in the adjacent clues I became more and more confounded by the clue. It seemed as though every other letter in the answer was a “K”! I’ve never heard of a KAKAKAKA race! Turns out the answer was “KKKKKKKKKKRACE”. That was obvious, wasn’t it? A 10-K race! Another answer in the puzzle was “DDDGLASSES”.

Another trick puzzle authors sometimes use is asking solvers to enter more than one letter into a square. This is the last thing most of us is expecting, but when you stumble upon it, it’s a sweet victory. Usually the multiple letter answers are the same throughout a puzzle. That is, a three word run like “SET” temporarily becomes a first-class “letter” for the puzzle:

Once you figure out the first instance of the trick, you’re on guard for remaining answers. When there’s a gimmick to a puzzle, noticing it is the turning point to solving the rest quickly.

To enter multiple letters with Black Ink, just right-click the square, or select “Enter Multiple Letters” from the Edit menu.

I’m playing with some design changes for MarsEdit’s main window, and thinking it will probably end up mimicking the classic “Mail source list utility bar” appearance, where a few small buttons appear beneath a source list at the left-hand side of the window.

With things in flux while I moved bits and pieces of the UI around, I was able to observe a pretty stellar example of how the visual placement of objects within a container can dramatically change the appearance of the container’s size. Consider these snapshots, taken from Mail and this experimental version of MarsEdit. Stare at the buttons on the Mail version (top), then at the buttons on the MarsEdit version. Which section is taller?

Answer? They’re exactly the same height. 23 pixels tall. The crowdedness of the MarsEdit version makes the whole section seem way shorter than it really is, while the Mail version has miles and miles of room to breathe.

It occurs to me that this illusion might not affect everybody the same way. To me the difference is stark, unless I start fixating on the blank part of the bar, when I can more easily accept they are the same size.

Fraser Speirs recently tweeted some comments about strings in code:

“I think that I particularly hate strings in code that have programmatic meaning. I’m looking at you, KVC. And you, KVO.”

Reading this was one of those “yeah, that sucks!” moments, and it got me thinking about how the situation might be improved. The problem isn’t that strings are used to drive the logical flow of an application – this is nothing new. Since long before KVC (Key Value Coding) and KVO (Key Value Observing) came along, Cocoa has employed data-driven techniques for dictating logical flow in an application.

Consider Objective-C selectors. These are essentially “key value coded methods.” A selector is conceptually a string, so much so that Objective C offers a shorthand for creating selectors directly from text in your code:

SEL mySelector = @selector(doSomething:);

Apple even recognizes the desire to create selectors dynamically at runtime, and offers the NSSelectorFromString.

A great thing about selectors is that they’re only conceptually strings. The “SEL” data type is defined as an opaque data structure pointer. If you examine the memory of the structure (as of 10.4) you’ll see that it looks quite a lot like a string, which is handy for debugging, but it’s not guaranteed to be a string.

The opaque “obstruction” Apple has inserted between the conceptual and implementation levels mean two things:

1. Apple can change the implementation at any time to something that suits the system better.
2. Compilers can do first-class type checking on methods and functions that expect selector arguments.

Compare the selector situation with its much younger sibling, who seems to have been born in a hurry and without as much planning:

id myValue = [myObject valueForKey:@"hello"];

In contrast to selectors, where semantic meaning is locked into the explicit SEL data type, here we must derive meaning from the context of the constant string data. We only know that “hello” is a key (or we hope it is) because it is preceded by a “valueForKey:” method signature. It would have been a bit more cumbersome for Apple and developers if they’d defined a “KeyCode” type and required it in all key value coding and observing method parameters:

id myValue = [myObject valueForKey:@keycode(hello)];

But suddenly the string itself has a lot more meaning. You might argue that in this example, the problem is the same, but there’s just more context to surround the literal string. That’s kind of true, but with a true compiler type the meaning sticks with the variable long after it’s typed or viewed in the code. Methods could dynamically distinguish plain strings from coding strings, a compiler could produce warnings based on semantic knowledge of keys (“that string doesn’t conform to key coding syntax”), and runtime statistics could be gathered about the number of keys that are used by your application (whatever that is worth).

I haven’t really thought this through too far, but I’m curious why Apple chose not to mimic their own treatment of selectors when it came time to base another critical technology on conceptual strings. I wonder if a “strongly typed” set of key value coding methods as a wrapper on Foundation’s methods would prove useful in my projects, or be a misguided waste of time. What do you think?