nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Dashboard advantages?

vsca

Hello all! My boss has expressed some enthusiam about creating dashboards for our operators (JMP 13).

The issue is that our operators need a lot of different information on screen at once, and this seems best formatted as a data table. Off the top of my head, other than a table, I can't think of any better way to organize the 10+ relevant data columns for the 40+ rows of active processes.

Graphical dashboards seem like a good way to organize a smaller, more focused data set, but I'm not seeing any advantage to switching my users' scripts from a table to any of the example dashboards. My question is, if the user needs a whole screen-sized data table's worth of information at a glance, can a dashboard implementation improve upon a simple data-table generating script?

Accepted answers

All comments

pmroz

You could also use JSL to create table boxes which contain various col box objects. From the script index:

Names Default To Here( 1 );
New Window( "Mountains",
 tb = Table Box(
 sb = String Col Box( "Mountain", {"K2", "Delphi", "Kilimanjaro", "Grand Teton"} ),
 nb = Number Col Box( "Elevation (meters)", {8611, 681, 5895, 4199} ),
 pb = Plot Col Box( "", {8611, 681, 5895, 4199} ) )
);

tb << Set Row Borders( 1 ) << Set Column Borders( 1 ) << Set Shade Alternate Rows( 1 );

gzmorgan0

VCSA,

I saw your post last night, and was anxiously waiting to see other responses. Whether to use a dashboard in JMP or a web page vs a table is, it depends.

If the 400+ scripts, each require a dynamic data extraction, and looking at several reports, I cannot imagine clicking one at a time all 400+ and all getting a proper review. However, if the the technician is looking up just one or two items, then maybe a table is okay.
If a technician is only looking up one or several processes at a time, I'd use a dashboard or window or web widget to drill to narrow the list instead of scrolling a table.
Compared to a table, I prefer graphics, animation( an auto player), flyovers, and graphics to display key information. I don't know if you have the platform process capability on your version of JMP but this is a good example of a display of a very complex table (128 parameters/columns and multiple lots) in a single graph. With labled points and/or adding a mosebox for On Click action this can be effective. Then add a custom filter for the process. this can be very effective. I realize you are likely not looking at Cpk, this is just an example to visualize. Suppose you are looking at trend reports. You can create an expression column of the trends, and use that column as a label. The plot the 40x10 on GraphBuilder. If the data needs to be updating then some automatic program needs to update the table periodically, so the data is fresh. Colors nd sumbols coudl flag issues.

That said, I have a caution, a scenario I have seen numerous times: an engineer learns JSL or Python and creates a nice simple app that gives the technicians access to data and plots. The boss loves it and praises it and asks for more and keeps asking for more. A good GUI/dashboard takes several iterations and time to refine and support. So beware, especially if you haven't built a GUI, this can take an unexpecetd amount of time and become an ongoing support issue.

Good luck!

128 Variables many lots and wafers

mikedriscoll

Ah gzmorgan0, you forgot to cite your source: https://xkcd.com/1319/

vsca

It's only a few scripts, it's just that there are several relevant columns of values to display.

Your example of a Cpk box-and-whisker plot is useful and is the closest I've seen so far to my case. It looks like I would still need to show one of those for each column, and my values from one row to the next are very different making it difficult to use the same scale for everything, but maybe not so different from your example. I'll look at how my data would appear in that format.

Thank you for the cautionary note, I'll be sure not to underestimate the time/support required! Are there any more suggestions for my case?

vsca

Also the technician isn't expected to examine every row in detail each time, my table uses color-coded results to draw attention where needed.

stephen_pearson

We have used a 3 tier system. As you say some results need more focus than others.
For processes which were within the expected range we look at less frequently, only to review for drift or other such patterns.
For processes with minor deviations a report can be created which aggregates theses deviation to check how long they have been happening to prioritise investigation.
For process which are critical to safety or product quality these are the top level and shown first.

In this way you can have a dynamic report which shows by default the most urgent/valuable data, with the option to expand it to the second and third levels. It takes more work to define but then much less work for the end user to get to the key information.

gzmorgan0

VSCA,

The other responses are good. So just a few more notes:

Deviation from baseline is an important metric. Consider a process variable that trends with a usage factor, like the amount of material processed, it has absolute limits and a history of performance by amount of material processed since last maintenance or parts replacement. Metrics should include absolute deviation or distance to spec and a metric of deviation from the baseline wear. I have seen numerous indictaor reports that focus on the spec indictors but no flag for something unusual. You don't want a review where a technician states "VSCA's report didn't flag me so I didn't look." So I guess this caution is "do not aggregate too much" or "indicators should flag deviations from baseline."
Just like CPK you can standardize to control limits or delta to baseline, so a boxplot of standardized scores could be plotted vs. process.
Attached is an example script of using a different type of graph as a flyover. Run the script and hover over a state to see a historical trend. This can be done with points on any graph.
Attached is a picture of an animation of a many parameter trend type report, not a dashboard, but built with JMP applicaton builder.

Figure10_7_fs.png

Flyoverpics.jsl