I'm working on an internal website for our employees. [Apologies if this background is too vague, but this isn't a public-facing website.] This site tracks a huge amount of data made up of many different entities with complicated relationships and thousands of user-input values.
Our users come from many different departments, and each needs to look at the data in a slightly different way in order to make decisions or carry out their job. Often this data has to be input by one department and then read by a different one.
We currently have several ways to find the data you are looking for including a search on the most common objects, and a summary page for the top level objects (which includes a further summary of objects they contain). This summary page is incredibly dense with information, even though it is separated into tabs.
It is also currently a point of contention. Recently several people have requested more information to be added to the various summaries. The data they are asking for is all present in our system, but you have to drill-down through a couple layers of child objects to find the tab and data in question.
I understand the benefit of presenting more details at the top level (and saving time and effort hunting for buried details), but there is a finite amount of space on the summary page, and if we show every detail that every department feels is important it will cease to be a summary and just be the entirety of all the objects.
How can I make the data each department cares about easier to access without flattening our data model (and making it worse for everyone)?
Some possibilities that have been shot down (but could be reconsidered):
- We have the ability to present the summary as a user-customizable table so they can decide which columns they are about. However, some of the requests deal with things like the ability to download attached documents or view child objects without digging, and table doesn't help in those cases. Additionally, the list of possible columns to display is absurdly huge.
- We could give each department a unique page and view of the data tailored for them. However, our dev team is too small and this much extra work is impossible to complete given our current backlog. Also, some people are part of more than one department so deciding which view they get isn't trivial.
- We could scrap our data model or rework it to better allow for these different requests and change the entity relationships, but again, our dev team is too small, and every time I suggest it I get a lot of dirty looks.
Option 2 seems to be getting a lot of support, which I can understand. The problem is that I don't see a way to create the view customizations we need without requiring more work than we have time for.
For example, our data is a very strict hierarchy. Each node in the tree usually has a couple branches, which in turn have a couple more branches, and so on for about 4-5 levels.
One department wants to be able to see a customer and a brief summary of their order history. A different department wants to be able to see all of the serial numbers for all of the widgets ever ordered by a single customer. Both aren't available instantly because it takes a non-trivial amount of time to traverse the hierarchy with the number and variety of database tables that have to be joined.
The current page is a compromise between these two extremes where the user get as many details as we can without hurting the loading time too much, but they still have to dig for some of the widget details. It is too slow and hard to skim for the department that wants the summary, and it takes too long to drill down for the department that wants the details.
The data model has small changes on occasion, and option 2 would mean maintaining an additional 2-5 pages when a new node or branch type is introduced. Likewise for maintaining a custom API to provide a window on the data. (These issues with the model are why option 3 is on the list.)
If option 2 is the way to go, I guess I'm looking for something that will run fast, be easy to maintain, and be simple to use/customize. But, maybe I'll have to settle for two out of three?