Bento

Wednesday, 14 November 2007

Daniel Jalkut has some astute observations regarding Bento, FileMaker’s new “personal database”:

What inspired this? I can imagine a few scenarios. Bento looks a lot like what might have come about if some strategists at Apple were sitting around planning the future of the iWork suite of applications. They scroll down the list of “office suite” applications and check them off as they ship. Word Processor? Check. Presentation? Check. Spreadsheet? Check. Then somebody pulls out their dusty copy of ClarisWorks and says, “Wait a minute. We forgot the database!”

No question Bento looks a lot like an iWork app — the template picker for a new Bento library is a dead ringer for the template pickers for new documents in Keynote, Pages, and Numbers. Jalkut continues speculating:

So the iWork team at Apple starts putting their work into the “database for everyday use.” It looks a lot like the other iWork applications in form and function. Things are going brilliantly when somebody gets whiff of the news over at FileMaker and starts screaming bloody murder. Because FileMaker is the database subsidiary of Apple, you can be damn sure that if Apple ships a consumer-oriented database app, they want to be the ones to ship it!

Possible. It’s also equally possible that Bento has been an original product from FileMaker all along, and that its visual similarities to iWork apps are just that, visual similarities. There are a slew of recent apps from indie developers that take visual cues from the UI of the iWork suite; there’s no reason to think FileMaker’s developers aren’t just as likely to do the same with a brand new app.

Another possibility that springs to my mind, though, is sort of the opposite of Jalkut’s scenario: that perhaps Bento began life with the idea of it being included in iWork, but it was rejected and spun out on its own. Rejected not because it wasn’t good, but because it overlaps too much with Numbers. Much of what Numbers can do is really ad-hoc database design and storage. E.g., one of Numbers’s default templates is “Event Planner”; one of Bento’s is “Event Planning”. Both Numbers and Bento have default templates titled “Expenses”.

That’s not to say that anyone who already uses Numbers couldn’t make good use of Bento, too. They do different things, and even where they overlap, they do things in different ways. But that they overlap at all, at such a basic level (“I’d like to create a list of records”) makes it clear that Bento works better as a standalone product than as a possible fourth iWork member.

Conceptually, Bento stands apart from all three iWork apps in a fundamental way: it is not document-based. Keynote, Pages, and Numbers all follow the basic document-centric model: you create documents, and then save them as files, assigning each one a file name and a location in your hierarchical file system.¹ No such thing in Bento. In Bento, there’s one main Bento window, and when you create a new library — which is the basic top-level “new database” in Bento — it appears as a source list item in the main Bento window.

Bento has no open or save dialog, and there’s no such thing as a Bento document. You can import and export libraries to and from Bento, but there are no documents to manage. In this way, Bento is more like Mail or Yojimbo than an iWork app. In the same way that you, the user, never need to worry about where and how your mailbox files are stored on disk by Mail, you never need to worry about where and how your Bento libraries are stored on disk. If you drag a library from Bento’s source list to the Finder, it exports a .csv file with the data from that library.

I’m a huge fan of this library-based (rather than document-based) concept for applications. From the user’s perspective, it boils down to creating the illusion that data lives inside the application’s main window rather than living as files in the file system that the user must name, locate, remember, and manage by hand. I’m not sure that would work for any of the iWork apps — much of the business of using presentation, word processing, and spreadsheet software is the business of exchanging documents with other people. For Bento, though, it’s perfect.

Behind the scenes, Bento must store your data somewhere on disk, of course. That somewhere is ~/Library/Application Support/Bento/bento.bentodb, which is a bundle containing an SQLite database and a Media folder for storing pictures, movies, and music stored in Bento libraries. I presume Bento is using Core Data (which is backed by SQLite), but regardless, it’s certainly not using a FileMaker-style database. [Update: It’s not using Core Data, at least judging by the schema.]

A few other tidbits:

• Jalkut points out that the Bento .app bundle contains, presumably inadvertently, a release notes document with information pertaining to Bento’s development. It’s at ~/Applications/Bento.app/Contents/Resources/English.lproj/release_notes.html. In addition to good old-fashioned nosiness, it’s worth reading for some insight into the app’s design. For example, “Opening the exported file in Microsoft Excel is the primary goal of exporting CSV, as the file format is centered around the behavior application. Thus Excel should serve as the standard for how our exported CSV is read.”

• If you poke around Bento’s .app bundle, you can glean that the app’s code name was “Gluon”. The name change to Bento may have been fairly recent — the Bento-specific classes and command in the app’s AppleScript dictionary are in the “Gluon Scripting” suite. (And it looks like the AppleScript support, at least judging by the dictionary, is serious. Numbers, on the other hand, doesn’t even have an AppleScript dictionary.)