I know some of you guys must be working in plants that handle enormous amounts of data. I’m looking for some suggestions on what you do to make the data more presentable for a user without causing sensory overload.
For instance, let’s say we have a soup factory. At any given point in time, we could be making 50 different kinds of soup and in different can sizes. We have empty cans, unsealed cans, and full cans ready for palletizing. We store the location and status of every can in our database, and have stored literally tens of millions of cans.
So, what have you done to effectively present this data to the user? For instance, Joe wants to know how much chicken soup is in the plant. He clicks on a chicken icon, and then…? It would be easy to create a table, but I don’t want it to be too accountant-ish. It would be great if he could click on the chicken, and get a feel within seconds if he thinks he might have to schedule an extra shift that weekend, if he is running out of chicken soup labels, etc, and then mine the data more thoroughly if necessary. Does that make sense?
The main rule in monitoring any big plant is - divide and conquer. If you have too many objects to display individually on an overview (and it sounds like it!) you have to work out how to categorise them. Maybe you can group them by plant area, with summaries for different areas e.g. number empty, being filled, awaiting palletising etc. Clicking on the button for an area would display the area in more detail.
As a rule of thumb I try never to have more than 3 layers in the plant hierarchy i.e. a plant overview, then area overviews, then area detail pages. I tend to have 2 buttonbars: the first holds the buttons for the plant overview and sub-areas; the second appears just above (or below) the first when a user clicks on a sub-area button and displays a number of area detail buttons.
I have implemented some pretty large systems with this methodology. Having such a flat hierarchy means that an operator is never more than 2 clicks away from any plant area detail page. You can also use the sub-area buttons to display the alarm state of that area, meaning that the operator is always aware of the system alarm state without needing an alarm table showing every possible alarm on every window.
Thanks Al. I have been very careful about structuring my tables so I can mine the data any way I want. I can start at the plant overview and drill down to an individual can of soup if I wanted to just by clicking on the objects. That part is fine. And, I am using some pretty nice animation for machine status and alarming.
But, how do you present the actual production totals? Do you just use a table? One of the charts or graphs? A progress bar? Animation? An HTML doc? What have users preferred? Right now I am using some cascading list components that sort of does the job, but it still looks like something an accountant would do. Just fishing for some new ideas.
First determine what kind of “levels/groupings” of summaries (month, day, shift, product) you need and how fixed/dynamic do these need to be. The key will be queries that produce small sets of useful summary data (these may be complex).
For very dynamic/user customizable views I would use the Reporting plugin Row Selector. It generates an expandable tree based on whichever columns you choose (shift, product, date groupings, etc). The user can drill down, selecting whichever level of the tree they choose, including multi-selection. This component can “feed” any dataSet, so you can use it with Charts, tables, or the reporting plugin.
Charts are a good way to quickly indicate trends and data outside the norm. You can do things like a fixed monthly summary, with the option of the user selecting individual days (calendar, dropdown, etc). In this case the user shouldn’t be “drilling down”, scrolling, or hunting for something like they might with a data logging application. Each query should return a user digestible summary. I like stacking them on a window, going from general to more specific (usually date range).
2a. You can also use labels on the window for aggregate values. For example, you might have a dropdown list to choose a supervisor or product line. A chart indicates summary data and the labels show: best, worst, average, etc. You can implement this with separate queries or aggregate expression functions.
The Reporting Plugin works well if you want to dynamically generate aggregate functions, even with multiple levels of grouping or “running totals”. It is ideal if you need to print it out or users expect a professional looking format. I like to use tables with summary (aggregate) data in the header or footer. I’ll even embed simple graphs within.
The Status Chart can give a quick graphic representation of discreet values. The more common usage contrasts digital to analog graphs (fans running next to temp graph), but it can be very useful if you can summarize down to “good/bad/ok” types of data such as daily production exceeded x amount, acceptable amount of downtime, etc.
If all else fails, go with your tables. They have the advantage of user sortable headers and can deal with “less organized” data. You can create a very informative, nice looking summary with conditional row coloring and image substitution (screenshots in the help file).
Very good information, guys. Like I said, I haven’t played around much with charts yet, but I’ll see what I can work up over the next few days. If I can intelligently design my tables so they can create their own custom reports and views anyway they want, that would be perfect.