“We need to add another column there”. Do you hear this phrase often coming from business people or developers? Just add another column and that’s it! I’ve heard this so often that I’ve decided to write about it.
There are two common scenarios I observed – adding a column to a grid table in UI or to the database table. Any of these may be a good idea and a totally awesome solution. This is not an issue as such. The problem is – it gets abused too fast too easy and too often. Usually I have an issue with people asking me to add column to a table (either UI or database) because the table is already overloaded and looks like a heap of all kinds of data for all possible cases. Adding more columns makes it even more overloaded, and probably slower as well. So that at some point people start getting scared when they see the monster table for the first time or when they need to change it or to work with it.
I think that the main reason for the described situation is that the people asking to add columns to some table simply don’t come up with any other solution for their problem. They are probably already used to work with huge overkill tables and monstrous interfaces, with tables which don’t fit horizontally to a wide screen monitor… they are used to something like Excel, scrolling in all directions through a data grid packed with weird data. They think in Excel tables (giving this article a title), so that if more data has to be stored or displayed, their reaction is – “oh, we need that column as well”. For business people the database is often a black box with something like monstrous Excel tables. For some developers (who quite often need to take care of the UI) the table in UI is like a database table or view, so another UI for the same scary “Excel table” in the background.
Apart from that, I really think that people asking developers to do something should define the requirements or problems to solve, but never the solutions! “We just need add another column” is not a requirement. The requirement is to store and to display something. Adding a column is one possible solution, but insisting on implementing this solution is simply trying to do someone else’s job.
Decent databases should be designed by the people who have clue about databases, their design, their performance, clustering, data mining, data migration, etc.
Decent user interfaces should be designed by the people who have clue about the design of user interfaces, usability, and so on. By the professionals.
Those who are not professionals in this area should not decide about the implementation. However, the reality looks different.
Often columns are added to the tables but the values are not applicable to most of the data rows. For example, a table ‘Articles’ which stores all items of an online store – article id, title, price, listed since, etc. An article can be: book, cd, dvd, blue ray disc, etc. Adding here a column ‘ISBN number’ would be simply wrong for that fact that only books have that piece of information. Why not to create a dedicated ‘Books’ table instead, with book-only properties? If it’s a relational database, just add a foreign key to ‘Articles’ and you’re set up. The ‘Books’ table becomes a kind of extension of an ‘Article’ table for books. This would keep the parent table slim and won’t pollute it with doubtful columns with which most data rows have nothing to do with.
Check out the picture on the right side! I’ve found it on the internet and it demonstrates nicely the issue this article is about. Does your company’s app looks like this one?
There is no table on this funny picture, but there are a lot of fields with cryptic names, allowing to set all possible kinds of properties and flags, which are really needed probably once in a year or are simply kept for legacy reasons. Most likely these are the names of the database table columns storing the data. In my experience, the interfaces in internal company’s applications suffer most from being overloaded, polluted and overcomplicated. Business people say – we need to display this piece of data there, developers silently do it as requested, and after this cycle repeats dozens of time, the UI looks like a mess everybody hates but everybody gets used to.
When it comes to displaying the tables with query results (like an overview of all articles, orders or customers), these can be very wide. So how about displaying only the most important data in the table (just few columns, like: name, surname, date of birth, post code), and offer all the details in a separate module? Maybe a “details” window, which opens via double-click on a data row? Or in a tooltip, which comes when user moves mouse over an icon displayed in the data row? This would not only make the table slim, but will allow user to focus on most important stuff instead of distracting user with all kind of cryptic flags and properties the casual users have no idea about.
Think of something like search at amazon or ebay. You don’t get a data grid with all kinds of details on found articles and cells containing buttons to order them. You get an overview with multi-line result rows with the essential information – name of an article, price, rating, picture. For the rest there is a dedicated article page, from where you can order it. Think about it the next time you’ll be in charge of a user interface.
Level Up Code, January 2014