Recently I’ve had time to revisit the question of identity columns (or sequences if you like). A client had come up with a screen that they really wanted us to incorporate in to their application, and the design of it had been done by some of their business analysts. One of the fields that was present on the screen was a unique identifier. Now, being a bit of a nosy so and so, I wanted to know where the unique identifier came from and was told that it was just an identify column padded out to 9 digits with the letter C in front of it (apparently C stood for client). This lead me to have an interesting discussion with the analysts:
Me: Why are we taking up valuable screen real estate with this field?
Analyst: It’s on there so the user knows the id of the customer.
Me: Fair enough. Can they search on this field?
Analyst: No.
Me: Does the client know their id value?
Analyst: No
Me: So, what purpose does this field have?
Analyst (in a sneering tone): It’s there to ensure referential integrity, and to give us a unique value to update the client on. Don’t you know anything about relational design?
Now, at this point, you might imagine that I was less than pleased with the design based on my questioning it, but why was I so put off by this field? First of all, when you are designing a screen, you have to ask yourself what the user will be doing with the screen. How will they interact with it? What do you need to put on there to let the user do their job? By putting an identifier on the screen that had no other purpose than to hold the identifier they were going to update the record against, the analysts had made a classic UI design. This, by the way, is why you need to have a User experience expert on your project, and why users, not just analysts, should have input into the UI.
By putting this field onto the screen, the analyst had given it an importance that it didn’t have. It’s a distraction for the user; always try to put on the screen the information that they need to do their job, and give them an easy flow through to discover additional information if they need it. With newer technologies like Silverlight and WPF, it’s incredibly easy to design attractive screens that show and hide information in visually appealing ways, so it’s a shame not to take advantage of these features while you can.
Don’t get me wrong, there can be a case for putting identifiers on a screen. If the user can search on the identifier, or the client could be reasonably expected to know the identifier, then it’s perfectly valid to have these on the screen. Nine times out of ten though, if the value is an auto-generated identity or sequence and it’s sole purpose is to enable referential integrity, then you don’t need to display it.
Please remember, when you have a piece of UI design in front of you, question everything. Ask why things are taking up valuable screen real estate. Ask if there are other options, such as flyouts, that could be used to present the additional information in none-intrusive ways. Most importantly of all, ask the users what they need to see – they are the experts after all.
