1

We are developing a software application to control a medial device. It is used for capturing images, which are then then analyzed. The operator of the device has to manually align the device in three axis, and this is not trivial to do. To do this, the operator looks at the computer screen which shows a live feed of the camera inside the device. The feed shows some guides to help with alignment overlaid on the feed.

The operator can manually trigger a capture using a button on the joystick of the device, after which the live feed basically freezes so the operator can judge if the alignment really is ok. We call the screen with the live feed the 'scan' page, and the screen with the captured still the 'accept' page. There are only very small textual changes in the screen at that moment: a string at the top left changes, and the label on a button in the lower-right changes from 'Scan' to 'Accept'. However, because the user triggered the transition manually, this has never been an issue.

Recently, we developed a feature that allows the system to automatically capture an image as soon as it determines that the alignment (and some other parameters) is ok. If that is the case, it will automatically transition to the 'accept' stage with the frozen image. In our hallway testing, this turns out to be a very weird experience. Most of our testers say that they think the application just froze and was broken.

We have tried to fade in a text (in a decent font size and with good contrast) over the bottom of the image saying "auto captured" and fade that out again after a few seconds. Nobody noticed. We tried introducing a flash effect, but that just looked like flicker (and, not supported by testing but in impression, seems to only enhance the impression of having a broken application.)

So... We are looking for suggestions on how to make it clear to our users that the application did in fact not freeze, but simply assisted them to get the best image possible. Any ideas what else we might try?

For clarity: the application itself runs on a normal computer, which may or may not have sound enabled.

  • We're just capturing a single image, which then needs to be reviewed and accepted or rejected (and then re-taken). After accepting, they are processed with lots of image processing (which takes a couple of seconds). The actual capture is basically instantaneous. – André Apr 10 '14 at 10:30
  • What if you have a [really big] label that says "Captured", or whatever. That way they can just look over to the screen and know that it has been captured. If they want to overlay to go away, they can click a button to fully inspect the image without obstruction. – TruthOf42 Apr 10 '14 at 20:32
1

A shot in the dark but anyways :)

Image 1 is Scan page, image 2 is Accept page, image 3 is Scan page with a miniature of the recently captured image from Accept page.

The basic idea is to give feedback that something is being captured (image 2) but even when the image has been taken, give feedback of what was being done and captured (image 3).

enter image description here

  • If a lot of images are being captured, they can be placed from top to bottom on the right side. If they interfere with the Scan page, make it possible to hide them with a button. – Henrik Ekblom Apr 10 '14 at 8:41
0

My guess is that your users "feel" that the application crashed because, once the still has been taken, the Accept Page substitutes the Scan Page, which implies 2 issues:

  • it makes the screen modal with two states: the Scan Page and Accept Page, forcing the user to know the current state of the screen.
  • You don't seem to have a clear transition from one state to the other and this is not trivial because you're not sure to have sound and the user can miss the flash or the shutter (you're not sure that the user can give full and continuous attention to the workflow).

Since having modal screen is discouraged in most cases, I would suggest to dedicate an area of the screen to the Accept Page without hiding the Scan Sage, like the mockup below.

enter image description here

Every time the machine takes automatically a still, you can use a shutter/flash and an animation to show that the still goes to the accept area. This way,

  • if the user misses the shutter/flash, she will not feel that the application stuck (since the Scan Area will still be up and running) and still find her stills in the Accept Area;
  • the user will be able to take more than one still select the one she prefers (I assume the user has a way to click or tap the still to accept).

Then, it's up to you where you put the Accept Area and how you organize it.

0

You could combine your flash with a camera type "click" sound to indicate capture, but I don't know if your particular equipment supports sound.

Perhaps there is a way that you can expand upon the flash idea though. How about making an animation that mimics a mechanical shutter closing and then opening again, something like the image below?

enter image description here

EDIT:

Since Animation looks like it will also be complicated, how about doing a simple graphic overlay to indicate that the mode has changed? From your use case you don't want anything that may obscure the actual image, so how about adding film roll graphic top and bottom of your still image?

enter image description here

  • Thanks for the suggestion. We've considered this. I have clarified a bit on what hardware this actually runs: a normal computer which may or may not have sound enabled. Sound may help, but we can't just rely on that. – André Apr 10 '14 at 8:01
  • @André What is your UI developed with? Are animations easily possible for you to develop (as with something like WPF), or is it difficult / time consuming to do something like this (e.g. with winforms) – Franchesca Apr 10 '14 at 8:57
  • It is build with Qt in C++. We're using the widgets framework for this (not QML), so animations are possible but time consuming. Something simple like a flash is doable, but the shutter might already be tricky to pull off in a reasonable time frame. – André Apr 10 '14 at 9:11
  • @André Hmm... How about putting a simple graphic overlay onto the screen to indicate that the mode has changed? I will update my answer with a more detailed suggestion... – Franchesca Apr 10 '14 at 9:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.