RE: [agile-usability] Digest Number 297
>Jaynee wrote:limited menu?
>> Of course, my vote is to find a way to throw out the keyboard
>> altogether (Dvorak, QWERTY, or otherwise) and find a different means
>> of input to a system. We often get so bogged down with the pros and
>> cons of a particular implementation, when the best answer is "C: none
>> of the above". For example, rather an a keyboard of any kind, could
>> the user speak the inputs? Select them from large GUI buttons on
>> Some combination thereof (voice their selection)? Do the inputs evento
>> need to be introduced into the system by a human? (How often do we
>> require repeat inputs from a user when the data are already "known"
>> the system and could have been imported?) Do we even need aEngineering about solving problems within the constraints >of available
>> human-in-the-loop at all?
>> This is the kind of creative thinking that we HFEs need to teach to
>> those in an Agile development world.
>The E in HFE stands for engineering. Engineers solve problems.
technology and materials. Creative thinking in design, engineering, and
development, particularly in the
>agile world, is about working within real budgets, schedules, andplatforms.
I agree that creative thinking needs to operate within existing
constraints. However, in more than two decades of doing this, I have
consistently found that creative thinking is nearly absent in any
context. If I could have 1/10 of the money back that I have seen
squandered while a development team wrestled their way through the "best
wrong answer" because they had already decided that the creative answer
was out of scope or would bust the schedule or budget, I could retire
rich. And that is merely development dollars and does not even count the
massive savings in follow-on implementation found in reduced training,
efficient work flows, and reduced help-desk efforts that we could
realize if only we both developed and engineered more creatively.
>When I teach design classes, there is always someone who "solves" avisual and interaction design problem by invoking the >seductive
catchall of voice input. But changing from one medium to another does
not solve design problems, as each medium >has its own inherent
limitations and creates its own design issues.
Actually, I intended that as merely an example of thinking outside of
the usual keyboard input paradigm. I agree that voice input has a long
way to go, and no, merely exchanging media does not solve design
problems. (Isn't the re-creation of a paper form into an on-screen
fill-in-the-blanks also nothing more than a media exchange?) The real
point is, when it comes to what I require of a user to interact with my
system, Everything should be on the table. Going in, there should be no
assumptions that a particular piece of data is necessary, that is must
necessarily be input by a user, or that it should necessarily be input
by a user via a keyboard (of any type). Those may all become elements
of my design because of the engineering constraints, but as I understand
Agile development, they should never start out as assumptions.
>As designers and developers, our responsibility is to deliver solutionsto customers and users now. Someday, yes, voice
>input may evolve to where it is both sufficiently reliable and fasteroverall than the much maligned QWERTY keyboard,
>but researchers have been promising that day to be just around thecorner for many decades--and we are still far from
>having a truly practical general purpose solution.Agreed. Buck Rogers does not work here.
>Interestingly, both the keyboard and mouse have been roundlycriticized, yet have proved surprisingly robust as general
>purpose HMI devices. Research has found that nothing else works quiteas well for so many purposes under so many
>conditions, although other mechanisms may be better in highly specificcircumstances. I am beginning to suspect that they >may be quite
fundamental and basically sound general purpose technologies that, like
steering wheels, will be around and >widely used in substantially the
same form for a very long time. Indeed, our dependence on them keeps
growing, as cursive >handwriting and mechanical drawing fade into the
background and become less essential skills for modern life.
I would not want to make this a general assumption in any possible work
environment, however. In the limited office-type,
environment, sure. Right now, the work environment I am designing for
involves an aircraft maintainer whose hands (both of them) are already
dedicated to other tasks, and interfacing with a keyboard disrupts his
natural work flow. Also, keep in mind that the keyboard was considered
'robust enough' until the mouse came along; although the advent of the
mouse did not eliminate the keyboard. I would predict that if/when
voice input or some other means of input becomes useful, it will not
replace either the keyboard or the mouse.
>> To me, mapping the UI to the known expectations of the user is morerule gets violated.
>> about mapping to real world events: for example, if I have a switch
>> that moves something up and down, then my GUI should actuate in like
>> manner - pushing the GUI switch "up" should move the item UP. Seems
>> obvious until you realize how many times in real life that simple
>These sorts of "borrowings" from the physical world are also veryappealing but often prove less apt than they seem at
>first glance, particularly in production environments. It is far easierto click on a button to toggle it than to slide
>it up like a wall switch. As HFEs (again, engineers), we need to knowabout the differences in performance
>characteristics in various interaction idioms and take these intoaccount in our designs.
The ideal place to pitch Usability testing! Because sometimes, we
simply cannot know which will be easier/faster/more effective until we
put it into the hands of the users in their operating environment, and
measure what happens.
>Bill Buxton distinguishes imitating physical reality in GUI design fromusing externally learned skills and associations >within the framework
of effective interaction idioms. The structure principle, for instance,
argues for putting the
>control that moves something up above the one that moves it down (notside-by-side as Redmond is prone to do), but
>whether a slider or rocker button or paired up-down buttons are betterdepends on the details of the task and the user
>--Larry Constantine, IDSA
- If I could have 1/10 of the money back that I have seen squandered while
a development team wrestled their way through the "best wrong answer"
because they had already decided that the creative answer was out of
scope or would bust the schedule or budget, I could retire rich. And
that is merely development dollars and does not even count the massive
savings in follow-on implementation found in reduced training, efficient
work flows, and reduced help-desk efforts that we could realize if only
we both developed and engineered more creatively.
I have had the exact opposite experience. I have seen many teams waste
time and money by failing to start with the
SimplestThingThatCouldPossibly work, and going right away for a