Buttons, Buttons, and More Buttons

Shuttle controls, image courtesy of http://www.nasa.gov

I've done you the favour of reproducing the "Customization" window from one of our larger PACS installations. You may have to click on the image to see the details. Depicted below is the window that allows us to change the tools on the toolbar and on the "context", or the right-click menu.

This particular screen capture shows how we change the settings for the "CRDX" modality. A drop-down gives you access to changing the other modalities. Our list has 29 modalities, although we probably actually access about 10 of these. Now, given that there are 89 tools, which can either be present or absent, each modality can have 2^89, or 6.1897002 × 10^26 available tool arrangements, so with 29 modalities, we therefore have 9.08696418 × 10^776 possibilities. OK, we don't use all the modalities, as I admitted, and if you look closely at the tools, many relate to digital mammography, and some are different facets of tools that are usually combined, such as "Flip Horizontal", "Flip Vertical", and the "Rotate" clusters. Moreover, I won't ever use a significant number of these functions. But that still leaves us with millions and millions of possible configurations.

To add to the joy of this particular product's setup, each modality has its own "Screen Layout" control, with all these options:

The little bar of 5 screens can be preset, but this is all you can access from within the viewer itself. Most other products give full control from a much simpler button or pair of buttons on the viewer:

To add further to our joy, there is a complete palette for digital mammo controls:

Buttons, buttons, buttons.

I've bemoaned this sort of thing for years, as my regular readers know quite well. Give me a streamlined package that lets me do my job without this level of distraction. So how did we get to this mess, and how do we get out of it? I discussed this with my friend and guru, PACS Ferret, whom I stole from the big U down the road, and he set me straight on a few things. There are stark differences in the way things are done in academia and in private practice. I view myself as more or less typical of a private practice PACS user. I need to power through my studies with the greatest accuracy and the least distraction possible. In the academic world, a place I haven't visited for quite a while, much time is taken for teaching, and research. The cases are often pre-read by residents. Some of those obscure tools might have a place.

This explains to some degree where all the tools came from. Some site calls up the vendor and said, "we need a left-handed spanner," and Shazam, there it is on the desktop. This might work well here and there, but if the solution to creating a GUI is to give the suckers what they want, everything any one of them might want, you end up with the astronomical number of control permutations (or is that combinations?) calculated above. There has to be a better way.

The solution to this mess is multi-factoral. First, send me $700 Billion, and then I'll.... Oh, wait, wrong mess. No, first, there needs to be a cleanup of sorts, with consolidation of multiple duplicate or near-duplicate functions, and more intelligent design overall. But beyond this, there may well need to be a whole new approach. PACS Ferret suggests a modular approach. There could be plug-ins or entire modules devoted to certain audiences. Perhaps the mammography module would include all the important tools for this modality. The academic version could include every tool known, including a picture-in-picture window to monitor the residents and see if they are goofing off. The private practice version would be streamlined, of course, but could have modules for high-level visualization as required, be they for cardiac imaging, virtual colongraphy, or whatever. I'm suggesting that these components blend in seamlessly with the PACS GUI, rather than spawn as add-on programs as we often see today.

With the modular approach, one PACS could be made to fit all, much more easily than what we see today. Of course, this doesn't address the functionality of the GUI itself, which is a related but different story.

You can never be too rich or too thin (that one has been disproven, by the way), but you certainly can have too many buttons. There are ways to keep this under control, which some vendors understand and some don't. However, I have to realize that there are those rads out there who probably want some of the things I consider superfluous, so we need to find a way to accommodate them. Throwing in everything but the kitchen sink on every version just won't cut it, but maybe, just maybe, the modular approach could keep your sink out of my playground.

Addendum:

One of my friends from the large PACS company above told me about the "CNTL-Right Click" text menu of tools:

Having used the program for several years now, I had no idea this existed. Maybe I need to do a CNTL-SHIFT-Right-Click and see if that brings out some Easter Egg or maybe wipes the disk.

This "new" approach is slightly helpful to access a tool that I might use once a year. I will have already organized my Right-Click tools to include those I use the majority of the time.

Another Addendum

A representative from a big PACS company had this to say about my post:

There is no doubt that many PACS vendors continue to carry the sins of the past (90's) in which tools were added at a single request, but with maturity of products and the market expectation, I believe that we see far more constraint these days when considering tools. For instance, does the tool meet the needs of more then one user, how can that outcome be achieved within the context of an existing tool etc. . I could discuss with you the analysis done to actually determine tool usage across (hundreds of) installations and you would feel justified in your opinion, given the 10-90 rule (10 % of tools are used 90% of the time) However, from my perspective, the blog was a bit misleading because it failed to set any type of control in the example picture, that complex library of tools shown can be controlled via proviledges, that once set, reduce the 'plethora of tools" the user sees, That window was that the "ALL tools" window for general management versus the tabbed libraries which focus on specific toolsets. The control RMB was put in place to allow users to set minimal icon based menus but still have acess to other tools that are needed on occaision. This will in theory also reduce the need to edit the menu as often? My point...

Respectfully, I agree with your overall assessment, but feel that it doesnt necessarily reflect newer/emerging products that have learnt from the sins of the past. We PACS vendors are trying to get smarter by listening instead of thinking.

And indeed I'm finding this to be the case. The change is slow, but sure.