I'm working on a desktop application for retouching images. So, there are numerous numeric fields to enter parameters like the exposure value or the color temperature.
We have two options when the user enters a digit in a numeric field:
Does anyone have any recommendations for choosing the best strategy?
It depends a.o. on the type of users the application is aimed at (occasional user or pro). The best strategy would be to prototype both solutions and test them with users.
In general, immediate feedback (option 1) is preferable, as long as the image processing doesn't prevent the user from interacting with the application. The user interface should give the user the chance to easily correct mistyped values. If adjusting the image requires some processing time, then you could consider adding a small delay between user input and automatic image adjustment. This could be combined with accepting explicit validation (for impatient users).
YohanYlab, designers for interactionwww.ylab.nl
Thanks for your answer.
Do you think a prototype can be enough accurate to simulate this kind of behavior?
Adding a delay seems an interesting track. In your opinion, what would be best delay value (something around 300ms)?
Thank in advance.
Yes, a prototype will be accurate enough. The prototype doesn't need to actually do any image processing. You can simulate the behavior with pre-rendered images.
A 300 ms delay sounds as a good guess to start with. It will be easy to tweak this variable in a prototype.
Take a look at Picnic (http://www.picnik.com/app#/home) if you're not aiming at 'heavy' users. Picnic manages to give immediate feedback on all the standard image manipulations.
Gilles, usually image processing is a heavy consumption execution. I think it would end up being very time consuming and resource hogging to constantly show updates. Instead it is usual to create a thumbnail or lower resolution ( the idea is to have an image that is smaller in number of pixles ) copy of the original picture and show the updates on that. Doing so will allow the user to see what their changes accomplish and not have to commit them until they are sure. Otherwise you will also have to commit changes and then undo the entire process if the user changes their mind. That would give you a O(n^2) operation and be very costly. If the user changes their mind with a smaller resolution copy, it can just be deleted and you save processing time.
Gilles,As a user of tools to retouch and edit photographs, I would like to see immediate changes for simple things like exposure, brightness etc.The only place where a thumbnail would work for me, is in more complex scenarios, for e.g. Creating a HDR.
people who work on images will usually work on many at a stretch. The extra click to commit each change is an unnecessary overhead. Compare with how photoshop does it. probably your best competitor in this game.
Both Photoshop and Ilustrator uses a "preview" before commiting changes. And the preview must be selected, the actual changes are only committed after you click "ok". Of course how quickly the changes occur depends on the processing being done and or size of the image. When you design for something like this, you have to remember that you are not the end user, so you have to be aware of not only what something like photoshop does, but why it does it that way. If you make updates that effect the original image on the fly without that so called "extra click", then how will you allow the user to disregard changes? They will either have to go to undo everytime they test something or they are stuck with what they choose. Photoshop shows a preview of adjustments on the fly but the user still has to select the "ok" button before committing. If they choose "cancel" instead the changes are dropped.
Then look at how filters are handled. Both PS and Gimp use a modal window with a smaller version of the image. HDR is a complex process but you would be surprised at just how complex even seemingly simple processes are. A Gaussian blur, for instance, processing cost is dependent on both the width and height of an image, so showing actual updates for each number entered could start to slow the system down as each number is entered because the changes would need to finish before the next number is calculated. Thus causing a que to form, with the result that the end user experiences a lag and unresponsive system. So while maybe an actual thumbnail would be too small, a seragate of the original image may be necessary to keep the system responsive while the actual adjustments are being made.
I agree with Abhijith,
And its good to hear his opinion because I have/still am doing part time consulting for a similar app and instant feedback is what I recommended for the exact reason that Abhijith said. I change something and I want to see my change because I am looking at the screen changing sliders or perhaps entering a value. The app required me to click on a checkbox to first activate and I missed it every time... and as I remember from the usability study I ran on it several years ago so did the potential customer.