Losing your identity

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.

  1. May 13, 2011 at 2:20 pm

    Hear, hear! (I imagine hearing a slow clapping echoing in a large auditorium with most of the audience looking bewildered.)

    I’d say your 9 times out of 10 remark is off by a few factors. Probably it’s more like 999 times out of 1000. I was literally rolling my eyes at “It’s there to ensure referential integrity, and it gives us a unique value to update the client on. Don’t you know aything about relational design?” My response would have been an even tarter “But the user doesn’t care about the details of referential integrity in relational database systems. Don’t you know anything about user interface design?”

    • peteohanlon
      May 13, 2011 at 2:26 pm

      If you had seen the UI they proposed, you would have seen that they knew nothing about UI design. The whole interface looked like it had been mocked up in Paint.

  2. Mike Brown
    May 13, 2011 at 7:39 pm

    Make that two people slowly clapping in the large auditorium. That story almost reminds me of the bozo’s in Starbucks telling Josh that he should read his article (I love referring to that as often as possible in the off chance that said bozos read my comment and realize that they are forever the laughing stock of XAML). I guess they assume that you’re doing UX because you couldn’t cut it as a developer.

    For the most part, I wish that developers would stop being so full of themselves. It’s almost like the euphoria of creation has given them a God complex (here Alec Baldwin would interject God Complex? I AM God!). When in reality if they took the time to listen just once in a while, they might actually learn something.

    • peteohanlon
      May 13, 2011 at 7:42 pm

      Tell me about it. It seems to be such a novel concept, the whole idea of actually asking the user how they work rather than just slapping something together.

  3. Raz
    May 30, 2011 at 8:21 pm

    Surly this is one of the main attributes of Agile…erm…the user

    • peteohanlon
      June 3, 2011 at 7:12 pm

      You’d think so, wouldn’t you?

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Train of Brain

All aboard.

The Canny Coder

Java 8 Functional Programming with Lambda Expressions


Adventures in theoretical computer science, with your host, chaiguy1337

Confessions of a coder

Confessions of a WPF lover


WordPress.com is the best place for your personal blog or business site.


Get every new post delivered to your Inbox.

Join 39 other followers

%d bloggers like this: