Part History Report

Part History Report

The Part History Report is meant to be one of the more widely used pages on the app for a wide range of reasons—but it was hard to quickly comprehend, and it was clunky. There was the intended "drill-down" functionality of the data, but it was a continous scroll of serial number/station/tasks/process data, then scroll down to the next set. Large amounts of tasks or process data always disconnected the user from its source, "What station is this again? What serial number am I on?"

Part History Report Original Part History Report - 2016

Imagine a single serial number goes through a dozen stations. And in each of those stations there are 1-20 tasks. And a pertcentage of those tasks each bears process data. That is a lot of scrolling and searching—especially if you are looking for a single piece of data from a particular task at one of any number of stations. Very easy to miss what you are seeking.

So instead of vertical-scroll-thinking from a horizontal plane, what about some vertical thinking and look across the horizontal plane?

Part History Report The Same Part History Elements, Different Experience - 2016-2017

That is, instead of stacking the data in continuous chunks, make three panels side-by-side. First panel list all the serial numbers. When selecting a serial number the second panel displays all the stations that serial number went through. Select a station. The third panel displays all the tasks for that serial number at that particular station. Icons indicate if a task bears process data and clicking the icon displays a modal with the process data for that task, in that station, for that serial number.

This makes it very easy to see a list of serial numbers, spot a reject and immediately drill down to the rejected task. Click, click, there it is.

Content Is King!

One of the things I remember well from a previous boss was him saying, "Content is king." What he was referring to I don't recall, but in communications—content is king. This led me to looking at data differently and how it almost always is presented—bold labels and subordinate content—and usually with a subordinate weight and smaller font. This seems to me—BACKWARD! Labels and headers are meant to lead you to the content you seek, then should fade away—not constantly poking you in the eye or needlessly vying for your attention.

Part History Report Restyled Part History Report - 2019

It was at this point when I started pushing a "Content Is King" philosophy, reversing the common practice. Labels are but servants to lead to the King, then bow out-of-sight, until called upon. THE KING IS MUCH MORE IMPORTANT THAN THE SERVANT. The content is much more important than its labels. I started making labels and headers subordinate to the content not only in data grids, as shown, but also and especially in configuration forms.