library manager
Working at StorageTek I designed and built a PHP prototype of the Library Manager. This one is all my fault. I did the interaction design, the graphic design (following their corporate standards), and the PHP, HTML and CSS coding.
A bit of background: StorageTek builds “libraries”. A library is a piece of hardware, typically about the size of hall closet, the contains one or more robotic arms, tape drives, and storage for dozens to hundreds of magnetic tapes. Yes in the bowels of IT at large organizations, data is still being written to tape, because tape is cheap. Much cheaper than disks.
This application was designed for IT storage professionals. A typical use would be diagnosing why a backup job failed overnight. Did the tape break, is it full, lost or mislabeled? The image one, above, shows the “dashboard” page that users see immediately after logging in. It’s attempts to show the system status at glance, high-lighting any hardware failures in the library.
Previous attempts to create a graphical user interface for this system had been little more than a web front end to the CLI. This had predictably mediocre results, as the grammar of a CLI is different than a GUI. A CLI command typically takes the form “verb arguments objects”, like mount volume XXXX drive YYYY. The CLI relies on the user to know what tapes are available, and how to identify them.
A GUI takes a different approach. The grammar for most graphical interfaces is “see and click”. In my design the application presents a list of tapes, and lets you act on them, move them to new storage cells, eject them from the library, or load one into a tape drive.
I left StorageTek, under my own power, shortly before the company was acquired by Sun. After my departure, the group used my prototype to guide them in building the actual GUI.
One of the interesting challenges of the project was determining the vocabulary of the application. The CLI used a lot of made up “engineer-words”, like “volser” a concatenation of “volume” and “serial number”. A “volser” is the unique ID assigned to a tape. It is expressed as a bar code for the robot, and a number on the label of the tape. These kind of made up works are pretty comomn in an CLI, were brevity is required, but don’t work well in a GUI. So there was this general need to refactor the vocabulary for the new application, but what words to keep, and which to change?
In the application, I avoided the ambiguous term “volume” in favor of the more specific “tape”. The engineering team would mix the terms “tape” and “volume” about 50-50, but the users I talked to would always said “tape”. So the crazy talk of “volser” became “tape ID”.
An interesting counter example is the term “scratch”. A “scratch tape” is one that can be written to. It’s either a new blank tape, or one where the data it contains can be overwritten. I originally thought this was more engineer speak, like a scratch disk in Linux, and I translated this to “blank tape”. However, the IT pros didn’t understand this, they called them “scratch tapes”, and I learned this was industry jargon, and as such the preferred term for the application to use. It was fun figuring out which terms needed improvement, and which were best left alone.
One last word about the php prototype. I had three goals in mind when I created it. First, I used it to do some usability testing with members of the LTUG (the Large Tape User’s Group). (The organizations employing the users were large, the users themselves were average size.) I also created it to document the design. Functional specs have nothing over prototype for explaining how a design works. Third it was an excuse to learn some PHP. Funny little language, reminded me of CFML.