Process Driven Vs. Entity Driven UI Design
I used to enjoy writing HTML UIs, but then I had traumatic experiences with nested tables, CSS and cross browser compatibility and went cold on the whole experience. For a good five years or so I avoided the UI like the plague.
Since moving to a new job last year I’ve been much more involved with the “front-end” of the ASP.NET product that I work on. Things are much better than they were before. CSS support is good, and we are in the enviable position of having an internal product that we can define the requirements for (IE7). Now I find myself frustrated not by the tools so much as the approach to UI.
Our application has a UI which is notionally split into functional areas. Each area takes the form of a wizard type process, split into tabs. Each tab deals with populating data on a Domain Aggregate. The problem I find is that populating instances of classes collected by the Aggregate necessitates that each tab be further spilt into more components (sub-tabs or otherwise). This solution doesn’t really scale beyond Aggregates containing Entities more than a few layers deep, because no one wants pages with lots of levels of tabs.
These process type UIs work well when the data is simple and flat; for example at a previous job I worked on a project that had this style of UI. The goal of each stage of the UI was to collect data which would be used to perform a query whose results were displayed as the last stage.
I think the crux of the problem is that people try to cram edits of complex Aggregates into linear wizard type processes.
My current thinking is that when you are performing edits on complex Aggregates you have to forget the linear process and go to for more entity based approach. I’ve not implemented anything yet, but I’m thinking that instead of breaking down your UI into bloated processes you have a page (or pages) that allow you to search for entities, then navigate to a particular entity’s “edit” page. The edit page would just be a user friendly view of the Aggregate, exposing root entity fields, and providing navigation to sub entities and value objects own edit pages. Instead of providing context through the wizard’s tabs, a history type bread-crumb trail could keep a record of entities recently visited.
Anyway, just an idea at the moment. If I get some time to implement some of this I’ll update.
UPDATE
Here is an example. A simple customer order scenario. System contains customers, customers contain basic details and orders, orders contain items and oacking instructions. The traditional tabbed UI might look like this (but with straight lines)
So, the alternative might start like this:
I think a search page/results can be core to a lot of systems. It’s a paradigm that almost all users understand now. A unified search page that lets you search for multiple entity types from one location might be a good idea. Even combined results might be possible or desireable if you have cross-entity indices.
So, once we have search results we move onto viewing an entity, in this case the customer. All entity details pages could follow the same kind of pattern, maybe a summary, links to sub-entities and value-objects, and buttons to actuate operations on the entity.
The user has viewed the customer, and clicked on the orders link, this takes them to another page which renders a collection of the orders held within the customer. Clicking on a specific order might give us:
This seems like a lot more screens than the initial tabbed example, and it is. There are a number of key advantages though.
- Each screen is significantly simpler. There is no real design as such, just a visual representation of the entity.
- There is no navigation to worry about.
- As we are not constrained by navigation, and are not bounded by tabs we can navigate beyond the cul-de-sac presented in the tabbed example.
Expanding on the third point; when we are looking at an order, we can now click on the order to present generic information regarding that product. This presents a level of detail that would be practically impossible within the confines of a tabbed UI.
