Introducing MenuBrain

November 19th, 2009

For a long time, I’ve been hunting for the perfect “snippets of stuff” manager app. Something that lets me save a phone number, bits of code or whathaveyou, then easily retrieve them later.

There are quite a few apps that do this — Yojimbo, xPad, Stickies — but none of them do it for me. They all require way too much management. Stickies scatters windows everywhere, Yojimbo wants you to tag things and put them in folders, xPad is a multi-document app. Every other app of this nature I’ve found is similarly overdone. While I can’t say I’ve seen every info organizer for the Mac, having really wanted to find an app of this kind for my own use… I’ve looked fairly thoroughly.

MenuBrain is the info organizer I wanted someone else to make. It’s stupidly simple.

Once you launch MenuBrain — and you’ll probably want to add it to your Login Items for the best experience — MenuBrain will take up residence in your menubar and wait for you to put stuff in it. To do that, you click the menubar icon (it looks like a database) and hit Edit. Then you just start typing, or paste something in, and hit return.

You can double click on an item you’ve entered to edit it, or drag and drop items to rearrange them. Close the window when you’re not using it. Oh yeah — there’s no Save button. MenuBrain just saves changes as you make them.

The items you add get added to the MenuBrain menu. When you select one, it gets copied to the clipboard — or launched in a web browser if it’s a URL. MenuBrain is pretty smart about discerning the significance of the info you give it. You can even annotate your snippets, like so:

Google Voice number: 555 123 4567

And MenuBrain will determine you probably want to copy the phone number, not the phrase describing it. Similarly, if you annotate a web URL:

Apple Store: apple.com/store

MenuBrain will recognize the important part is something that can be handled by a browser. (The fact that this is a pretty casually-constructed URL is no problem for MenuBrain.)

There’s even an “Add to MenuBrain” system service if you’re into that sort of thing.

The best way to get a feel for MenuBrain is to start using it. Download it for free and let me know what you think. (Try to be somewhat kind — it’s my first Cocoa app.)

Scribblenauts: For Great Justice

September 23rd, 2009

Scribblenauts is a wonderful game. Enter nearly any noun in the English language (within a few very reasonable restrictions — nothing vulgar, nothing copyrighted), and that item is summoned for you to use in solving the game’s puzzles. Need to protect a sandwich from some ants without killing the critters? You might beam the food up in a UFO. Trying to grab something from across a pond? You could build a bridge, or just lasso the object.

I’ve enjoyed the game tremendously. The puzzles aren’t all equally inspired, the controls can be fidgety — but the feeling of semi-omnipotence that comes with accessing the game’s vast dictionary more than makes up for these shortcomings. The only thing the game really lacks — as suggested to me by Ian Bogost — is a system of ethics.

Some puzzles do enforce conditions that resemble ethical restrictions. There’s a “heist” level featuring security guards whom you are not permitted to eliminate. But for the most part, Scribblenauts’ ethics are decidedly situational. In general you are allowed to wound, even kill, the most innocent of non-player characters (NPCs) without suffering any in-game penalty.

That’s not meant to be a criticism. The game is juggling quite a few balls as it is. But I’ve found that I have the most fun with Scribblenauts when I deliberately impose ethical restrictions on myself: Don’t attack human characters. Only use weapons in self-defense. Disarm or incapacitate rather than kill.

It occurred to me that it really wouldn’t be that hard to build an overarching ethical system into a future Scribblenauts sequel. So here’s my proposal for a morality mechanic in 5th Cell’s next big hit… Scribblenauts: For Great Justice.

The Justice Meter: In addition to the Budget Meter, which fills as you add objects to the level, For Great Justice would feature a Justice Meter. At the start of a level, the Justice Meter would be filled to 100%. Performing unjust acts, or allowing unjust acts to be perpetrated, would drain the meter. If the Justice Meter drops to nothing, you fail the level.

Events that would drain the Justice Meter: Killing a human NPC would instantly drain the Justice meter. Attacking a human NPC would drain it, but at a less drastic rate. Allowing two NPCs to hurt each other would also drain it, but less drastically still. Killing or attacking animal NPCs would drain the meter, but at a less drastic rate compared to the respective human NPC events. Allowing two animal NPCs to hurt each other would have, I think, no effect on the meter. Circle of life and all.

Special events: In addition, 5th Cell could design levels with specialized justice effects. You might need to find a way to stop a rich man stealing from an impoverished person — the Justice Meter draining all the while. Or a construction crew could be in the process of demolishing an orphanage and it’s up to you to disable their equipment. Loggers might need to be stopped from destroying a forest.

Personally I’d love to play a Scribblenauts sequel with these features. Games are largely about succeeding within a set of restrictions — so why not ethical ones?

Settings, and the Settings App

April 18th, 2009

In 1984, Susan Kare created the original Macintosh Control Panel. In a mere 315 pixels wide by 177 pixels high space, she captured every single system setting the user might ever care about. It was a compact, easily-understood and gorgeous interface.

It was also completely unsustainable.

As the Macintosh operating system grew in complexity, so too did the settings available to the user. First the Control Panel was subdivided into sections, then into separate system files. Now, we use multiple Preference Panes — some of which consist of multiple screens and sections themselves. (You can follow the history of the Mac’s system preferences at AppleInsider.)

On top of that, of course, applications have developed their own increasingly-complex preference interfaces. Adobe Illustrator alone features eleven preference “panes” to explore. Clearly, we’ve come a long way since System 1.0.

As I write this, the iPhone has been on the market for less than two years. It’s UI, while a work of art in almost every respect, is still in its infancy. Much of that interface is compact, easily-understood and gorgeous. And some parts will probably prove eventually to be unsustainable.

In particular, there’s the Settings app.

Apple’s official recommendation for third-party application settings is:

Settings that define preferred application behaviors, similar to preferences in desktop computer applications, are accessible in the built-in Settings application.

This guideline is rather short-sighted. It worked well when Apple’s original 18 apps were all the user had to worry about. But since the launch of the App Store, those have been supplemented by over 25,000 third-party programs. Obviously no one user has every one of those apps, but one has to wonder at what point the Settings app becomes too overloaded to be useful. Is it at 50 apps? 100? How many of these rows should I have to scroll through to find the settings I’m most interested in?

There are settings, and then there are settings. If a preference has to be set before the app can even be used — such as the mail account settings for the Mail app — and isn’t likely to be altered again, putting that setting in the Settings app may make sense. If, on the other hand, a preference is likely to be played with frequently — such as, say, text size for a list display — placing it within the app itself would make the preference more discoverable for the user.

Tweetie is a wonderful iPhone Twitter client, developed by Loren Brichter. Loren is one of the best Cocoa devs working today, and was kind enough to let me help beta test his Tweetie for Mac. Loren is also deeply committed to keeping “settings in the Settings app.” What does this mean for Tweetie on the iPhone? Well, when I want to try out one of Tweetie’s three themes, this is what I have to do:

  • Quit Tweetie and return to the home screen.
  • Locate and launch the Settings app.
  • Locate and select the Tweetie listing inside the Settings app.
  • Select my new preferred theme.
  • Quit the Settings app and return to the home screen.
  • Locate and launch Tweetie.
  • Evaluate the new theme to see if it’s to my liking.
  • If it’s not, I get to start over… with the first step above.

This is a lot of work for what really should be a simple option located within Tweetie itself. Reviewing the results of my choice requires me to be in Tweetie — which I can’t be if I’m using the Settings app.

The reason users are confused when the developer decides “settings are in the Settings app” isn’t because too few developers are sticking by that guideline — it’s simply because the Settings app is a separate app. When I’m using your third-party app, I’m almost by definition not thinking of any apps besides the one I’m using. The Settings app is not on my mind, because it’s just one of a number of other apps with which I’m not presently engaged.

There are times when placing settings in the Settings app can make sense. But making it an ironclad rule misses the point of having Human Interface Guidelines in the first place: to ensure that what’s easiest and most obvious for the user, wins.