A note on javascript-y user interface

Posted by Martin P in Development, Lessons learned      No comments

Apr
29

The use of javascript is pretty ubiquitous now. Even without considering the full-scale ‘webapp’, it is commonplace to find javascript doing client-side field validation, if nothing else.  One feature that javascript enables that I’ve rather liked in the past is for fields to be hidden and subsequently presented only in the right context.  So, if one considers a single survey form, which may ask the question; Who is the hottest? a: Scarlett Johansson ; b:Nicole Kidman ; c: Other.  Only when ‘Other; is selected does a text entry field appear for the user to elaborate.

Now in this simple example, its probaby a little over-complicated, but it would be easy to envisage a form such such UI logic would clear (unclutter) the screen, enhancing user experience.

But I think now that idea can be taken too far.  I have just spent a little too much time working out how to configure a monitoring tool (Hyperic) to help maintain a DCM4CHEE DICOM archive.  Hyperic is a great choice because it shares the same application server layer (JBoss – although I had a little issue with conflicting JRE versions which apparently will be addressed in the next version ), and is, overall, a fine product.  But, geek as I am, I tried configuring collection intervals without resorting to the documentation.  In each page where I thought there may be a route through to the config, no route was obvious.

Long story short,  the config route only arose after I selected a specific metric to indicate that I wanted to ‘do’ something with it.  On the plain page, there was little clue that indeed that page is the one I need, so instead of digging deeper, I went elsewhere, to equally no avail. In the end, a peek at the documentation gave me the clue – if I select a metric, the config will apear. Admittedly, if I’d paid a little more attention I would have spotted where to go but this is a note on properties of UI generally and not (NOT) any criticism of Hyperic.

A short sharp lesson in building new-paradigm applications.  I don’t know if it is naturally intuitive to have visual clues around a UI or just what we (I) have become accustomed to over the last couple of decades.  But it is regardless where I (as an Hyperic user) stand at the moment.  I need lots of visual clues about what is available on each page of the application.  That is why simple drop-down menus worked so well.  Give me a week, and maybe I’ll need less.  A month, and even less.   One for follow-up.

How can we be sure proprietary software is safe?

Posted by Martin P in Open Source      2 comments

Apr
2

When software goes awry at a bank, no-one is hurt. A warehouse system may turn HAL but at the end of the day, maybe a little fruit goes off, or TVs fall off the back of lorry. Healthcare is one of the few environments where software has the power to do actual harm. That should be taken seriously.

How often does that happen? Who can say? Most healthcare institutions wouldn’t be too keen on publicising such a thing voluntarily. Only when matters go to court do incidents really get exposed.

The case is tragic, but some points stand out:

Singh’s lawyers allege the company knew about a software error that caused the catheter to overheat. Edwards didn’t warn hospitals of potential hazards, they say.

… but one can’t expect everything to be perfect, you say…

However, Sigh’s case is not the first time problems were reported with the monitor.

In my day job, I work with a lot of software proprietary vendors. Getting software from two different vendors to work in concert can be a challenge, and while it isn’t (for now) common, I have certainly experienced occasions of ‘Mexican Standoff’, with two (or more) vendors denying responsibility for an interface blip. On one occasion, I had external consultants come in the sniff the network to determine that, in fact, the connection that vendor A said was being rejected, in fact, wasn’t even being requested. We never did resolve that issue – the RIS involved is now defunct (although the vendor remains one of the biggest around) and the CR was replaced for other reasons.
How is that relevant? In each case, the vendor has control over crucial quality information. That isn’t an issue if the vendor has a sense of responsibility but lets get real – vendors are there to make money – nothing else. In that situation, someone, somewhere, is going to avoid responsibility.

Of course, I could say that making software Open Source fixes this problem – and to a large extent, it does, but that doesn’t answer the whole issue. I’m not sufficiently bigoted about open source to suggest that OSS holds all the answers. OSS and proprietary software must (and indeed, will) co-exist in any rational world and those who resist that will (IMHO) either change, or regret it.

So the safeguards must apply to both. The safeguards at present, are clearly lacking for even those devices to which they apply. There is a lot of quite simply rotten software around that puts patient care at risk (and, by the way, that includes OSS as well as proprietary). That’s the question. I don’t have an answer.

Human Visual System

Posted by Martin P in PACS General      No comments

Apr
1

Just to illustrate a point I’ve made already that the human visual system is complex and even now not fully understood, IHE has a cute article on change blindness.  In the absence of complete understanding, and given that Radiology is largely a visual process, there should be no compromise on the quality of data, of equipment, of software, or environment.  Unfortunately, money makes the world go around, and very often, there is.