Reading
|
PanelSoft User Interfaces and Usability for Embedded Systems |
Feedback to 'Modes and the User Interface' - Murphy's Law, May 2005Regarding the macro mode on digital cameras, there is a good reason why this is used. Most digital cameras use what is called a passive autofocus system, which basically is a "try and see" method of autofocussing: the camera adjusts the focal length through a range to find the sharpest image, much like a human would do. This obviously takes some time to do as the lens must be physically adjusted, the digital image read out and evaluated, etc. Adding a macro mode allows the lens to work over a much smaller distance. For example, when macro is off, the lens doesn't have to move through the close-up range, and when on, it need not check the more distant range. This saves considerable time in the autofocus process. And since the autofocus delay is usually the largest component of shutter lag (which manufacturers are always trying to minimize), limiting focal distance reduces shutter lag considerably. Of course, it is a trade-off vs. ease of operation. Some cameras (typically film point-and-shoot) use an active auto-focus method, where it bounces a signal off the object to measure subject distance. This method can be quite fast and would work well for a modeless macro system, but it has its own set of drawbacks: easily fooled by off-center subjects, windows, etc., less accurate, limited working distance, higher cost to implement, etc. Range finders seem much less common in the world of compact digital cameras. Since they already have a digital sensor and sophisticated microprocessor/DSP, they can do the auto-focus without any additional hardware. Of course, this leads to the shutter lag problem! The only digital cameras that can autofocus really fast seem to be the DSLRs and other high-end models that have a dedicated autofocus system in addition to the main imaging sensor. In the case of the compact digital camera, the trade-off for the manufacturer is between making the macro always present and eliminating the confusion and decreasing the shutter lag. Since the vast majority of the customers aren't shooting macro images but are very annoyed by shutter lag, I think they made the right decision. But none of this takes away from the points in your article about making modes match user actions, etc Jon HarrisGood Article. A small slip - The example of a watch - seting time needs a mode switch. Otherwise accidentlaly pressing the set switches will inadvetently change the time. Concept is clear , but the exmaple is not valid. (other examples are perfect). Arun Kumar Niall's Response: I thought through the accidental change, and I wonder how valid that is. On a wrist watch, it is very easy to accidentally press a button, but the example I used was a clock, where I believe that hitting a button accidentally would be unlikely. I have used many digital clocks, but I can never recall accidentally putting one into the 'change-time' mode, which would be the result of accidentally pressing one of the buttons in the current design, so I do not think I would accidentally change the time if the design was modified to the one suggested in the article.Mr. Murphy, I just came across your article via an ACM newsfeed. Right on! I am passionate about good, clean software design as well (so much so that I have put together a modest website to espouse the idea). One example that you might enjoy is the elevator panel outside the State Library of Tasmania. You can see my description of it along with a terrible photograph of it here (http://cleancode.sourceforge.net/wwwdoc/gallery/TasLibElevator.html), but basically the numbers on the board go from top to bottom whereas the floors are numbered--like all other elevators--from bottom to top. Michael Sorens, University of Phoenix Niall's response: Excellent site. The elevator example is a case using an incompatible mapping between the interface and the real world. I make a brief reference to this issue in an older article, 'Principles of User Interface Design' available at http://www.embedded.com/2000/0012/0012ia1.htm. |
|
|