The purpose of this window is to allow a user to select two inventory items and merge them together. A deceptively simple task that becomes more complicated when all the relevant use cases start coming into focus. Which item should absorb the other? What if some information is correct on one, but not the other? What if one item has all the correct information for a few data types but only half or none of the other data?

Merge Inventory

This new window was designed to replace a single-click, behind the scenes merge that was not selective and would simply search for duplicated identifiers (an situation that was once rare before database constraints banished them, thankfully) and appended all information in the youngest record to the oldest record in all found duplicate sets. This was a bug fix that looked like a feature, and when users clicked on that menu item, they already expected to see something with choices and options like what is mocked up here, but were not getting it. The contemporary use case that most brings user interest in this proposed feature is for items that appear unrelated to the application – the user wants to tell the app which records are duplicates.

The iteration shown here is the more complex of two flavors, this being the one for course material items. The actual, on the shelf inventory items are children of course material item records that are managed by different staff and are treated as single records whereas the actual inventory of that record is almost always comprised of a new iteration and a used iteration. The new and used iterations are what actually gets merged together when necessary, and this process needs to remain transparent to the people interacting only with the parent record.

This was one of those sad occasions where several hours where spent designing a UI for functionality that was never implemented due to time constraints.

What could have been done differently?

Did you see it? One of the use cases I threw out is not supported by this interface. You can move or ignore any of the data types from the abandoned record, but you cannot replace any particular data type on the remaining record.

I might also, in retrospect, throw out the word append in favor of something more simplistic like keep. The end users of this software are not IT professionals and append is not a word that gets thrown around in average conversation. It’s one of those words that devs will use so often we forget it might send a user to a dictionary, which no interface should do.