Reverse-engineering data models from an interface, and the 3 types of interfaces

Examine any data-driven application – an HTML site like, a rich Flash application like’s store, a portfolio of cutting-edge Flash sites like, user-generated networking sites like YouTube or – any data-driven application. If you look closely enough (but maybe not too closely), you’ll notice two things:

  1. You can always reverse-engineer a data model associated to that particular application just by playing around with its interface, and similarly…
  2. You can break down the components of an interface such that each component can be placed into one of three different categories (we’ll get to this a bit later).

Let’s take the first observance: You can reverse-engineer a data model by just looking at an application’s interface. Let’s do it. In a separate browser, go to – or if you’re lazy, just picture the site in your head. Like many e-commerce applications, its homepage has a bit of navigation at the top, a bit on the left, and a whole lot of content in the middle. But, what is this stuff? Where does it come from? Well, I could spend weeks observing each and every page of, thinking about where all this content belongs – but for sanity’s sake let’s take something simple.

I go to, and search for books on “Flash design.” I’m then presented with a search results page with a listing of books (when I did it just now, I am shown books 1-12 of 1,134 titles that might match my interest). On this search results page, I see the first 12 listings of Flash books. My data-philic eye tells me that, probably, these books came from a table of books in the gigazmo database.

The left navigation shows me links to categories of books that happen to be related to the search term “Flash design.” I see links like “Business & Investing (137), Gay & Lesbian (2), Arts & Photography (335)” and not surprisingly “Computers & Internet (569).” I’m pretty Internet saavy…. I know that these numbers in parentheses represent the number of books that both match the search term “Flash design” and also happen to belong to these categories. I can quickly surmise that perhaps’s database also has some concept of category – perhaps a categories table. And, perhaps, each book in the books table has a category ID associated to a category in the categories table (or perhaps there’s some bookCategory table that stores book and category ID pairs so that a book can be associated to many categories much like a category obviously contains many books). I don’t know this for sure – but I’m guessing so. And if I were inquisitive enough, I’d go hunting to see if any of these “Flash design” books were categorized in more than one place. For the purposes of this post, I really don’t care.

So, when thinking through it again, I notice that the link “Business & Investing (137)” is a little interface element that really represents a category object. And, the “(137)” really represents its relationship to books (specifically, a count on the number of “Flash design” books that relate to the “Business & Investing” category). Somewhere under the covers of the application, a category object was bound to this little link – and because I’ve deduced that categories are related to books, I can see why it make sense (and is technically possible) that the “Business & Investing” link can also display the number “137.” I can get that information because there are 137 “Flash design” books related to “Business & Investing” in the database.

You can start extrapolating this exercise all throughout I now click on a book on “Flash Design” — say…. “Flash Application Design Solutions” (available for just $34.99 at!) and I’m presented with a fully detailed page about this particular book. The data object associated to this detail page is no different than the data associated to the listing of this book on the previous page. The only difference is that there’s more information – more information about this book is now displayed to the user. For instance, there’s a 5-star graphic next to text that reads “(1 Customer review)” toward the top of the page. My data-focused brain now says, “Hey, maybe there’s a table in the database called CustomerReview that relates to the books table.” Later down the page, I actually see the full review, (“Ah… there’s a description field inside of this CustomerReview table”) with an author’s name (“Hmm… there could be an Author or UserReviewer table associated to the CustomerReview table”).

I can continue this exercise for hours and hours on the website. Quickly, I can sketch out a pretty robust data model of the database. Now, I might eventually have to “refactor my thinking” – perhaps the Author or UserReviewer table turns out to just be a Users table – the same users that can write reviews also login to purchase items from the site.

Now, I might not be 100% correct – the data model I come up with, after hours and hours of observing the interface might not be exactly what’s truly under the covers. But, certainly, the general gist of the data model will be the same. And, I can do this exercise with any other data-driven application. The homepage of tells me there’s probably a “FavoriteSites” table that contains a collection of sites (with URLs, an associated thumbnail image, a title, perhaps a relationship to a Companys table – a collection of companies that create the sites showcased on FWA and so on and so forth). Again, upon further probing and navigating, I might find I need to refactor my initial data model – but again, pretty soon I can come up with something that I think is pretty close to the truth.

When you do this enough, another idea begins to emerge. You can break down all the interface parts (or components, if you wish) into three categories:

  1. An interface component that represents a particular single item in your proposed data model.
  2. An interface component that represents a collection of these simliar items in your proposed data model… or,
  3. An interface component that really doesn’t have any direct connection to the data model. Maybe you can call it a static interface component.

Go back to and observe. The search results page for “Flash design” contains the first 12 relevant books related to the search term. You can think of this entire interface component as a particular visual representation of 12 members of the Books table – in other words, a book collection’s view. Each one of these members represent a singular book item’s view. Similarly, the category links on the left simply represent a view of a collection of categories. Each link represents a view of a particular category. And, if you really want to get particular, the number of related books in a category (i.e. “(137)”) actually represents a view of a collection of books again. But, instead of displaying a list of book titles or book cover images, the display is just the total number of books.

Going into a book’s detail page, the entire book content area interface represents a view of a singular book item again. And, within this interface are a whole bunch of progressively modular views – the (“1 customer review”) link represents a view of the collection of customer reviews related to the singular book (it just so happens this collection only contains 1 customer review).

But, what do I make of the links “See larger images” and “Share your own customer images” that lie underneath the book’s cover image? They are presumably on every book’s detail page… do they represent a particular item in a data model? Well, no. They fall into the third category – they really aren’t a part of the data model, but really only exist on the interface level. Sure, if you click on it, they may take you to a new page that has more data-modelly type stuff on it. But, inherently, they don’t represent a view of an item or a collection of items in our data model. They are static, non-data related interface components.

Now, data related interface components don’t just end with basic detail and list pages. Take, for example, form elements. Search forms also fall in line the same way. Instead of displaying the contents of a particular item or collection of items, they manifest as fields that user’s can use to input into. When you are asked to supply your shipping and billing address before checking out, the form is nothing more than, say, a UserItem view that will add (or update) a new user upon submission. And, you can similarly deduce data model relationships from a search form because they usually represent themselves as drop-down lists or a row of checkbox items. A drop-down list of states from a user profile page tells us that there is a states table associated to a particular user, and the resulting states drop-down list is nothing more than a particular visual representation of a collection of states.

When you do this exercise in-depth, you can start to decompose and demistify what’s going on behind the scenes. In truth, application interface design is nothing more than a physical representation of a data model, letting you bob and weave through the relationships of a data model through sensory interactions. And the 3rd category of interface components (static, non-data specific ones) anchor much of that needed flexibility in interface design (anything from a static logo header image to interactive elements that let you manipulate or change the application to a different state).

And, it doesn’t just work with HTML apps, but Flash apps as well (where it really becomes more interesting). Because of the fluidity and flexibility of a Flash app, it might be a bit less obvious how to break down the application’s data model from the interface. But, it can be done just the same – Behind all the tweening and blurring and sleight-of-hand, Flash interfaces can be broken down into the same three buckets – interface components that represent a particular data item, interface components that represent a collection of a particular data item, and interface components that are inherent to only to the interface itself.

For instance, picture a series of images of historical books interspersed along a timeline with a draggable slider- a typical, slick little piece of Flash-work. From a data-modeling perspective, we can think of the entire view as simply an BookCollection view – it just so happens that the individual BookItem views in this BookCollection view only display a BookItem‘s image. The slider itself can be thought of as static (non data-related), even though it functions to manipulate the visual collection of images as you drag it. Notice also that the data this timeline piece represents is no different than the data that an HTML table of book images would represent. It’s just that, in Flash, we have so much more flexibility as to what the visual interpretations of our data objects can be.

So, what does this all really mean? In particular, it stresses the importance of data modeling in application development. You can find a trillion different ways to build an interface against an existing data model – but not the reverse. And, when you start to break down what appears to be a complex application, you start to see that there’s a whole lot of order to the chaos.

In future posts, I’ll talk about what this means in a few other ways:

  1. How to parlay these ideas into building a data-driven framework for Flash apps (something that I’m working on and have off-and-on blabbed about several times in this blog)
  2. Why I generally dislike “componentizing” interface elements into reusable components (because it makes it more difficult to conceptualize the connection between an application’s data model and its interface)
  3. How this kind of thinking relates to more application-architectures like Cairngorm or ARP.