ID Synonyms or Naming your IDs

Introduction

When developing software, we regularly add incremental numbers to our data, usually for relational purposes and often for use within a database. If you are like me, then a primary key is often the starting point. Much of the time, these numbers are not exposed to our users because, frankly, they don’t really need to know them. When we do expose them, the users generally know what they represent – it may be a single case (header) number or a transactional type such as an invoice or part number.

So far so good, it doesn’t matter if the number becomes incredibly long. If the user needs to refer to it, they probably just look at the last few digits for matching and they can always cut and paste anyway right? Well, yes absolutely, though it does get harder for them to quote the numbers to each other and over the phone, but generally everyone is happy enough.

However, there are rare occasions when the users themselves are the ones who have to build and relate transaction numbers and sometimes in a multiway format. I have users who are required to relate multiple transactions to single documents and multiple documents to single transactions. In general terms, this is a many-to-many relationship – bread and butter for developers and database administrators I suspect but not so easy for users to understand or operate.

"Filters" I hear you say.

Yes of course, once the relationships are made/attached and the data is all in suitable order, the users can see their results adequately when filtered, right? Well yes to a degree and no whilst they are making those relationships., Filtering does help but only once they have their data all correctly organised. Even then, it is hard to relate multiway relationships simply via a UI so the average user can see which documents are attached to which transactions and vice versa. It quickly becomes visibly confusing.

The idea that is the subject of this article is simply to name your transactions with common nouns.

On the left is an example of ID numbers in a grid and on the right, the same data but using nouns.

So, for example, let us say a PDF document is shown for 771936 and with that document, the transaction numbers 771932 and 771925 are also shown as being attached to that document.

So, we would be showing that PDF (on a separate screen in my instance) and the fact that it has transactions 771936,771932 and 771925 attached.

Or, if using this idea, the document could just note that ZELDA, DAWN and KESHA is attached to it. I know which I find easier to say and remember.

This method has proven to reduce errors and speed up the users' understanding. It is worth noting that the ID numbers will just keep getting longer and thus harder.

In addition to this, when a user has a query that they need to escalate to a supervisor they, and the supervisor, find it much easier to relate to than a list of numbers that people commonly make mistakes with (mainly by transposing two digits).

For the curious, the above example has paper clip icons, these represent documents attached, red means more than one and the user can hover or click them to see more ifto. This paperclip principle is also used for the other way within the grid but I am keeping the subject as simple as possible here. Also, the small blue icon in the column header can be clicked to alternate between showing the names and the ID numbers.

So How Is It Done?

Obviously, we cannot have millions of nouns. What I did was to compile a fixed list of 10,000 nouns from publicly available lists. The nouns are selected by using a simple modulus of 10,000 from the ID number.

So, if your ID number was 10,001 and it had the name JERRY, then so too would 20,001.

Therefore, it’s NOT FOOLPROOF.

This basic calculation method may or may not be suitable for your particular instance and so you may have to come up with a different criterion. In my circumstance, the numbers will not be more than 10,000 apart and a duplication of the name would not be fatal. In addition, the nouns are only useful to a point but proper filtering once the data is properly attributed also contributes to understanding.

Is That It?

Not quite.

Simply sticking an alphabetic list in and relating it via ID numbers I found wasn’t quite good enough.

If you can organise your list of names such that they are start with a different letter consecutively, then the user is less likely to confuse them. My names list is organised in sequences of A-Z and although multiple users are committing at the same time regularly two instances of the same initial letter would rarely meet on screen.

Also, I adopted "ragged right" approach. It is my experience that people read vertical lists easier if the words are not of uniform length. Again, I also organised the data in a ragged right order by referring to their lengths. If you want to see the difference, just pop up an editor and create a list of words where they tend to align at the left and right, it will be harder to read and discern individuals from.

At this point, I would ask that if anyone has any neat ideas for representing many to many relationships (especially transactions related to documents) then I for one would find it of interest. 😊

This is an area I would like to improve upon. Although my users seem happy, new ones are often fazed with the problem at the start.

Background

I have written and currently support a legal costing program package where a wide variety of documents need to be analysed and have data recorded against them. It is for this software that I implemented this idea during my efforts to simplify what is basically a complex problem to represent.