Loading ...
Sorry, an error occurred while loading the content.

RE: [agile-usability] Digest Number 297

Expand Messages
  • Gardner, Jaynee B
    ... limited menu? ... to ... Engineering about solving problems within the constraints of available technology and materials. Creative thinking in design,
    Message 1 of 2 , Dec 6, 2005
    • 0 Attachment
      >Jaynee wrote:

      >> 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
      limited menu?
      >> Some combination thereof (voice their selection)? Do the inputs even

      >> 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"
      to
      >> the system and could have been imported?) Do we even need a
      >> 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.
      Engineering about solving problems within the constraints >of available
      technology and materials. Creative thinking in design, engineering, and
      development, particularly in the
      >agile world, is about working within real budgets, schedules, and
      platforms.

      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" a
      visual 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 solutions
      to customers and users now. Someday, yes, voice
      >input may evolve to where it is both sufficiently reliable and faster
      overall than the much maligned QWERTY keyboard,
      >but researchers have been promising that day to be just around the
      corner 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 roundly
      criticized, yet have proved surprisingly robust as general
      >purpose HMI devices. Research has found that nothing else works quite
      as well for so many purposes under so many
      >conditions, although other mechanisms may be better in highly specific
      circumstances. 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,
      sitting-at-a-desk-type, accustomed-to-messing-with-computers-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 more
      >> 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
      rule gets violated.

      >These sorts of "borrowings" from the physical world are also very
      appealing but often prove less apt than they seem at
      >first glance, particularly in production environments. It is far easier
      to click on a button to toggle it than to slide
      >it up like a wall switch. As HFEs (again, engineers), we need to know
      about the differences in performance
      >characteristics in various interaction idioms and take these into
      account 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 from
      using 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 (not
      side-by-side as Redmond is prone to do), but
      >whether a slider or rocker button or paired up-down buttons are better
      depends on the details of the task and the user
      >performance objectives.

      >--Larry Constantine, IDSA
    • Desilets, Alain
      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
      Message 2 of 2 , Dec 6, 2005
      • 0 Attachment
        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.

        -- Alain:
        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
        Whiz-Bang implementation.
        ----
      Your message has been successfully submitted and would be delivered to recipients shortly.