Data modeling the iPhone

Why not.

If you happened to catch our presentation on Zen Flash Application Development, we showed a few slides of interfaces broken down into the 3 general kinds of UI.

We used green to show collections, red to show items, and yellow to show UI that was neither an item or collection. The idea is that you can create a very accurate sketch of a data model based solely on UI.

I believe that the easier you can breakdown your UI into the data model components, the easier that piece of UI is to use. When you’re more connected with how the data works underneath, you’re more confident in what’s going to happen when you interact with the UI at the surface.

Here’s how you can break down a few screens on the iPhone. Notice as you traverse the interface, you can uncover more information about the data model.

The iPhone contact list as items and collections.

Click an album item in the album collection…

Now we uncover more information about the album. Click the playlist icon at the upper right…

Now we uncover a new relationship between albums and a collection of songs.

Granted, all this “uncovering” is kind of obvious. Who doesn’t know an album has a title and a collection of songs in it? But, the core idea is that we can do this kind of data modeling with any kind of application interface. And, it becomes particularly benefitial to interfaces and data models that may not be so familiar to us.

4 responses to “Data modeling the iPhone

  1. In this case I don’t agree. If you dig through the fields in itunes it seems more like albums are handled more like a SELECT * FROM TRACKS WHERE ALBUM LIKE blah rather than a more normalized album table approach. I say this only because the table approach would make things function a lot better than they currently do for albums in itunes–the current system has caused me lots of problems trying to get DJ mixes recognized as whole albums.

  2. Hey anonymous-

    Interesting point. Perhaps they ought to data model it in the way I suggest, although I’m sure they have their reasons…

    One of the inevitable things about data modeling from the interface is that as you start looking at more and more screens, the data model will change. Had I looked at the iTunes functionality, I’d have to reconsider the data model, just as you did.

  3. Yeah… i was just trying to point out that a good UI like itunes is often capable of masking the underlying data via its very simplicity.

  4. “Good UI like itunes is often capable of masking the underlying data via its very simplicity.”

    I can’t argue with this statement at all. I’m sure there must be a reason they don’t normalize. But I think, in general, when you can map an application’s data model pretty closely from its UI you’re going to have a much more pleasant coding experience, and, in your case, user experience.

Comments are closed.