I mentioned in an earlier post that you can break down the user interface into 3 types. Well, just recently, I discovered (or, better put, realized) there really is a distinct 4th kind of UI that is separate from the static-item-collection triad.
Sometimes, a piece of UI can represent a data object that neither exists as a singular instance of a data model item (e.g. a configuration screen for a gym shoe) or a collection of such items (e.g. a photo gallery of all running shoes). This 4th piece of UI can emanate from a more “evolved” kind of object, whose data doesn’t come directly from the database itself. Here is a common examples:
Suppose I wanted to build a chart of shoe sales (since we’re suddenly on the topic) for a local shoe store’s intranet. The chart can look or be anything, I don’t really care. Let’s say its a graph of the last 30 days of shoe sales (the x-axis will be days, the y-axis will be number of shoes sold). For kicks, let’s not even make it a bar or line graph…let’s say there’s not even a y-axis. You rollover a day with your mouse and the volume of a pre-recorded snippet of the employee-of-the-month’s flatulation indicates how many shoes have been sold. I don’t know…it doesn’t matter. It’s Flash and we can do anything. We’ve seemed to have gotten off track here.
Anyways, when I try to categorize it into one of the 3 aforementioned types, it doesn’t seem to belong anywhere. The chart itself certainly represents data in some form – so it is not static. It doesn’t represent a single shoe sale, but it does represent a collection of shoe sales. So, my first inclination is that I can force the 3rd type (the collection view) upon this kind of UI. But, it’s a kluge at best. The chart is a collection of shoe sales, but, more aptly described, its a collection of the count of shoe sales. In other words, if I were to model a data object behind it, I might describe a ShoeSaleDay object that holds attributes like, Count and the DayOfSale. Fine, case closed, right?
Well, when you consider a database for a shoe store, you probably wouldn’t have a ShoeSaleDay concept. You’d probably have a Shoes table and a Sales table. The Sales table would probably store information like the DateOfSale, a foreign key to a Customer table (who purchased it), etc. But, the concept of a ShoeSaleDay wouldn’t exist in its own table. And, therefore, it wouldn’t exist as a data model concept.
This kind of stuff happens all the time. The way you would typically gather a data object like ShoeSaleDay would be to write some SQL or did some underneath logic that grabbed and grouped counts from the Sales table. After some looping and thrashing, you’d come up with a ShoeSaleDay concept. In reality the ShoeSaleDay doesn’t exist in the core data model, but rather, it emanates from the data model + a bit of business logic. It’s really a concept of its own that can be created on-the-fly from the existing data model.
Of course, this isn’t simply limited to something like a count. Things like summations fall under this category too (e.g. instead of a total sales chart, a total net revenue chart per day, etc.). Any new kind of object concept that uses data model parts as ingredients and then requires a recipe to create it falls under this 4th dimension.