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

RE: [agile-usability] Digest Number 296

Expand Messages
  • Gardner, Jaynee B
    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
    Message 1 of 20 , Dec 5, 2005
    • 0 Attachment
      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.

      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.


      One more thing: recall that many of the oddball 'expectations' that we
      currently perpetuate (the QWERTY keyboard, file naming conventions, the
      little "X" in the upper right corner) were invented because of systems
      constraints that no longer exist. They too were new at one time.




      -----Original Message-----
      From: agile-usability@yahoogroups.com
      [mailto:agile-usability@yahoogroups.com]
      Sent: Monday, December 05, 2005 1:38 PM
      To: agile-usability@yahoogroups.com
      Subject: [agile-usability] Digest Number 296

      ------------------------ Yahoo! Groups Sponsor --------------------~-->
      Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet
      Life.
      http://us.click.yahoo.com/KIlPFB/vlQLAA/TtwFAA/dpFolB/TM
      --------------------------------------------------------------------~->

      There are 5 messages in this issue.

      Topics in this digest:

      1. RE: Learning a new UI
      From: "Larry Constantine" <lconstantine@...>
      2. RE: Learning a new UI
      From: "Larry Constantine" <lconstantine@...>
      3. RE: Learning a new UI
      From: "shel kimen" <kimen@...>
      4. RE: Learning a new UI
      From: "Jim Kauffman" <jkauff@...>
      5. RE: Learning a new UI
      From: "shel kimen" <kimen@...>


      ________________________________________________________________________
      ________________________________________________________________________

      Message: 1
      Date: Sun, 4 Dec 2005 12:35:31 -0500
      From: "Larry Constantine" <lconstantine@...>
      Subject: RE: Learning a new UI

      Randy wrote:
      =====
      > But if you base your designs on this alone, is there not a danger that

      > you
      may just
      > perpetuating existing second-rate design? Just because we all know
      something,
      > and do it, doesn't mean there may not be a better way, wouldn't you
      agree?

      This, I believe, was the rationale for the Dvorak keyboard, which
      probably means the issues aren't that simple.
      =====

      Yes, well the Dvorak keyboard story so often cited is instructive in
      this regard. The Dvorak keyboard layout is indeed more efficient in the
      hands of a fully-trained user, but for most accomplished QWERTY typists,
      the very modest gain is not worth the massive hours of retraining to get
      back up to where they were. (As a 35 wpm hunt-and-peck typist in my 30s,
      I decided to learn touch typing. It took nearly 6 months for me to get
      up to the same speed without peeking.) Dvorak users also report
      difficulty when confronted with a QWERTY layout, which is far more
      common.

      The lesson is that we must always look at the big-picture systems
      implications, not just raw efficiency or instantaneous intuitability. My
      view as a designer is that non-standard designs need to be a LOT better
      AND easily learned to justify departing from well established
      convention, particularly where users have invested heavily in learning
      the old way.

      --Larry Constantine, IDSA





      ________________________________________________________________________
      ________________________________________________________________________

      Message: 2
      Date: Sun, 4 Dec 2005 12:35:31 -0500
      From: "Larry Constantine" <lconstantine@...>
      Subject: RE: Learning a new UI

      Jim wrote:

      > Several years ago I helped design a computerized version of a
      > nation-wide academic test. We were tasked to deliberately design a UI
      > that was unlike Windows or the Mac UI, to avoid giving an advantage to

      > participants who
      were
      > computer-proficient. The test began with a sample session with an
      integrated
      > tutorial, which gave extra assistance to users who were struggling to
      complete
      > the sample tasks. The tutorial was mastery-based, so users could not
      > go on
      to
      > the test itself until they had demonstrated an acceptable mastery of
      > the
      UI.

      Intriguing technique. It reminds me of an issue in testing novel
      designs. A team I have been working with devised some very novel and
      potentially highly efficient new interaction techniques for a production
      environment. No claim to intuitability is being made; the primary design
      driver is user efficiency and reliable interaction. The only way to
      reasonably test such features for usability is to pre-train users with
      the basic technique (keeping track of how much it takes to gain a
      certain proficiency) before testing in context.

      --Larry Constantine, IDSA
      > -----Original Message-----
      > From: agile-usability@yahoogroups.com
      [mailto:agile-usability@yahoogroups.com] On Behalf
      > Of Jim Kauffman
      > Sent: Sunday, 04 December 2005 9:11 AM
      > To: agile-usability@yahoogroups.com
      > Subject: RE: [agile-usability] Learning a new UI
      >
      > > -----Original Message-----
      > > From: agile-usability@yahoogroups.com
      > > [mailto:agile-usability@yahoogroups.com] On Behalf Of Larry
      > > Constantine
      > > Sent: Saturday, December 03, 2005 4:00 PM
      > > To: agile-usability@yahoogroups.com
      > > Subject: RE: [agile-usability] Learning a new UI
      > >
      > > The elevator-speech condensation is that the user must recognize
      > > novel elements as such, actively engage in anticipating (guessing)
      > > behavior, and immediately try out and confirm the anticipation. The
      > > result is stable persistent learning without further practice.
      >
      >
      >
      > Jim K.
      >
      >
      >
      >
      >
      >
      > Yahoo! Groups Links
      >
      >
      >
      >
      >





      ________________________________________________________________________
      ________________________________________________________________________

      Message: 3
      Date: Sun, 4 Dec 2005 09:34:26 -0500
      From: "shel kimen" <kimen@...>
      Subject: RE: Learning a new UI

      >>We were tasked to deliberately design a UI that was unlike Windows or
      >>the
      Mac UI



      That's fascinating. What happened with the test? Did you ever get any
      post-test feedback?



      ./s



      [This message contained attachments]



      ________________________________________________________________________
      ________________________________________________________________________

      Message: 4
      Date: Sun, 04 Dec 2005 16:39:39 -0500
      From: "Jim Kauffman" <jkauff@...>
      Subject: RE: Learning a new UI

      No, we weren't given any feedback, but the high school students who
      tried the UI rated it "easy to learn and use". One out of ten
      participants had some trouble with it, but she had never used a computer
      or played a video game.
      Unfortunately, her verdict was "it's easy to use--I'm just stupid."

      Jim K.


      _____

      From: agile-usability@yahoogroups.com
      [mailto:agile-usability@yahoogroups.com]
      On Behalf Of shel kimen
      Sent: Sunday, December 04, 2005 9:34 AM
      To: agile-usability@yahoogroups.com
      Subject: RE: [agile-usability] Learning a new UI



      >>We were tasked to deliberately design a UI that was unlike Windows or
      >>the
      Mac UI



      That's fascinating. What happened with the test? Did you ever get any
      post-test feedback?





      [This message contained attachments]



      ________________________________________________________________________
      ________________________________________________________________________

      Message: 5
      Date: Sun, 4 Dec 2005 17:00:44 -0500
      From: "shel kimen" <kimen@...>
      Subject: RE: Learning a new UI

      >>Unfortunately, her verdict was "it's easy to use--I'm just stupid."



      Ouch. I mean, really. Makes me so sad. Anyway, thanks for the story. ./s







      [This message contained attachments]



      ________________________________________________________________________
      ________________________________________________________________________



      ------------------------------------------------------------------------
      Yahoo! Groups Links




      ------------------------------------------------------------------------
    • Larry Constantine
      ... The E in HFE stands for engineering. Engineers solve problems. Engineering about solving problems within the constraints of available technology and
      Message 2 of 20 , 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.

        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.

        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.

        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.

        > 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.

        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
        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
        Message 3 of 20 , Dec 6, 2005
        • 0 Attachment
          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.

          -- Alain:
          As a person who had to use speech interfaces for a while (because of Repetitive Strain Injury) and who built a number of speech interfaces, I can attest to what Larry is saying.

          On paper, a continuous speech recognition system with 95% accuracy sounds great, but in practice it justg doesn't work. Just imagine a keyboard that:

          A) Lags behind what you type by 5 words.

          B) Screws up one out of 5 words. And by "screw up", I don't mean a few characters. I mean that you type "beach" and the keyboard types "bitch" instead. Oh, and because of A), you don't get to see the error until 5 words later.

          C) Types gibberish whenever you happen to have a cold.

          D) Makes loud clanking noises that allow your neighbours.

          How long would you put up with such a keyboard?

          Today's speech interfaces CAN be very useful, but only in limited context like:

          - people who can't type (ex: RSI, paraplegics)
          - people who WON'T type (ex: "REAL lawyers/doctors don't type!")
          - people who are in hands and/or eyes busy situation (ex: people driving cars)

          Alain Désilets, MASc
          Agent de recherches/Research Officer
          Institut de technologie de l'information du CNRC /
          NRC Institute for Information Technology

          alain.desilets@...
          Tél/Tel (613) 990-2813
          Facsimile/télécopieur: (613) 952-7151

          Conseil national de recherches Canada, M50, 1200 chemin Montréal,
          Ottawa (Ontario) K1A 0R6
          National Research Council Canada, M50, 1200 Montreal Rd., Ottawa, ON
          K1A 0R6

          Gouvernement du Canada | Government of Canada




          ----
        • Joshua Seiden
          ... Josh replies: Buxton also said (at your last forUSE conference) something like this: as long as we are interacting with the computer using a mouse, we are
          Message 4 of 20 , Dec 6, 2005
          • 0 Attachment
            Larry wrote:

            > 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.

            And:

            > Bill Buxton distinguishes imitating physical reality in
            > GUI design from using externally learned skills and
            > associations within the framework of effective interaction
            > idioms.


            Josh replies: Buxton also said (at your last forUSE conference) something
            like this: as long as we are interacting with the computer using a mouse, we
            are interacting with the world using the equivalent of the point of a single
            chopstick. That gives us the manipulative power of a fruitfly!

            To be fair, this was in the context of a discussion of the limits of general
            purpose devices and general purpose computing.

            JS
          • Dymond, Robin
            Well, you won t find me trading my mouse for a touch screen and a chop stick any time soon! I agree with Larry, our systems are built within a context, the
            Message 5 of 20 , Dec 7, 2005
            • 0 Attachment
              Well, you won't find me trading my mouse for a touch screen and a chop
              stick any time soon!

              I agree with Larry, our systems are built within a context, the idea of
              building an enterprise app with something other than a keyboard and
              mouse is quixotic.

              How come no one in this group is discussing ideas on integrating
              usability and agile?

              Agile is rapidly gaining adoption across the software industry, for
              example Microsoft has recently become a strong proponent of Scrum and is
              promoting it with their development tools. How are you integrating agile
              methods with usability ideas on a daily basis? Are you? Or do you have
              waterfall processes, in which the IAs do usability as part of the
              "Design" process, with mockups from photoshop, that may or may not
              become actual software?

              This group has been a bit of a disappointment. I think there is lots of
              work to be done. Usability practitioners will benefit from better
              integration with agile teams building better software quickly. But teams
              will adopt Agile with or without usability practitioners or their ideas
              on board.

              But maybe, with all of the good feedback agile teams get from working
              closely with a customer, usability is inherent, and IAs are largely
              irrelevant for most projects?

              Thoughts?

              Robin Dymond

              -----Original Message-----
              From: agile-usability@yahoogroups.com
              [mailto:agile-usability@yahoogroups.com] On Behalf Of Joshua Seiden
              Sent: Tuesday, December 06, 2005 7:45 PM
              To: agile-usability@yahoogroups.com
              Subject: RE: [agile-usability] QWERTY, mouse, and novel input


              Larry wrote:

              > 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.

              And:

              > Bill Buxton distinguishes imitating physical reality in
              > GUI design from using externally learned skills and
              > associations within the framework of effective interaction
              > idioms.


              Josh replies: Buxton also said (at your last forUSE conference)
              something
              like this: as long as we are interacting with the computer using a
              mouse, we
              are interacting with the world using the equivalent of the point of a
              single
              chopstick. That gives us the manipulative power of a fruitfly!

              To be fair, this was in the context of a discussion of the limits of
              general
              purpose devices and general purpose computing.

              JS






              Yahoo! Groups Links







              The information contained in this e-mail is confidential and/or proprietary
              to Capital One and/or its affiliates. The information transmitted herewith
              is intended only for use by the individual or entity to which it is
              addressed. If the reader of this message is not the intended recipient,
              you are hereby notified that any review, retransmission, dissemination,
              distribution, copying or other use of, or taking of any action in reliance
              upon this information is strictly prohibited. If you have received this
              communication in error, please contact the sender and delete the material
              from your computer.
            • Josh Seiden
              ... [snip] ... There are certainly some frustrations associated with the group. One of them is the monthly discussion of the relevance of UX. Another is the
              Message 6 of 20 , Dec 7, 2005
              • 0 Attachment
                > This group has been a bit of a disappointment. I
                > think there is lots of
                > work to be done. Usability practitioners will
                > benefit from better
                > integration with agile teams building better
                > software quickly. But teams
                > will adopt Agile with or without usability
                > practitioners or their ideas
                > on board.

                [snip]

                > But maybe, with all of the good feedback agile teams
                > get from working
                > closely with a customer, usability is inherent, and
                > IAs are largely
                > irrelevant for most projects?
                >
                > Thoughts?

                There are certainly some frustrations associated with
                the group. One of them is the monthly discussion of
                the relevance of UX. Another is the implication that
                UX practitioners should be grateful for a seat at a
                table with folks that don't see value in their work.

                For me, comments like are deeply disrespectful, and
                illustrate a major hurdle to closer collaboration--the
                basic lack of shared experience and trust among the
                players.

                That lack of shared experience will always be a
                hindrence to this discussion group. (Discussion lists
                don't create the shared experience we need. Project
                work does.) It would be interesting, Jeff, to take a
                poll to assess how many folks on this list have
                actually collaborated on an Agile/UI project.

                Personally, I'm here to learn about working in an
                Agile context, but have never worked in one. I wonder
                how many Agilists on this list have ever worked with a
                dedicated UX professional.

                JS
              • shel kimen
                It would be interesting, Jeff, to take a poll to assess how many folks on this list have actually collaborated on an Agile/UI project. I am an IA/Interaction
                Message 7 of 20 , Dec 7, 2005
                • 0 Attachment

                  It would be interesting, Jeff, to take a poll to assess how many folks on this list have
                  actually collaborated on an Agile/UI project.

                   

                  I am an IA/Interaction Designer/Internet Strategist/Etc…. Since about 1995. Many different hats many different projects, 90% web with some .Net, mobile, and custom devices thrown in the mix.

                   

                  I’ve had one Agile dev experience, which was only part Agile b/c the client hadn’t finalized the dev environment while we (as consultants) went ahead defining use cases and general scenarios, trying to break it all into ‘stories’ anticipating an agile environment. I had extreme difficulty in creating space to establish a UX strategy, and it was tough to break out of my training in long exploratory concept phases. I noticed that on another project, another team (of consultants) with the same client were working very well to integrate usability, ux, and agile – they created what seemed to be smart and quick feedback loops that seemed to work. I never got to complete the project on our side – which is probably just as well – but I was enjoying ‘thinking differently’ . It was refreshing, rational, and a nice challenge.

                   

                  I was fascinated by Agile as a concept/philosophy and joined this list to try to understand the points of intersection – particularly relating to strategy and feedback. To Josh’s point – that has not happened and probably would not without a project.

                   

                  Now we are all very busy, and I certainly am not quite ready to jump up and lead a project – definitely not before 2006. But it would be interesting to pick some pro-bono something interesting to try and tackle, so those of us who want to learn more about Agile or more about UX in a team environment can have that opportunity.

                   

                  ./s

                   

                   

                • Desilets, Alain
                  There are certainly some frustrations associated with the group. One of them is the monthly discussion of the relevance of UX. Another is the implication that
                  Message 8 of 20 , Dec 7, 2005
                  • 0 Attachment
                    There are certainly some frustrations associated with
                    the group. One of them is the monthly discussion of
                    the relevance of UX. Another is the implication that
                    UX practitioners should be grateful for a seat at a
                    table with folks that don't see value in their work.

                    For me, comments like are deeply disrespectful, and
                    illustrate a major hurdle to closer collaboration--the
                    basic lack of shared experience and trust among the
                    players.

                    -- Alain:
                    Interesting...

                    I have not read anything on this list that to my eyes, questioned the
                    relevance of either U* or Agile.

                    I HAVE read a lot of discussion about which parts of these two
                    approaches work well together, and how they can be modified to take
                    advantage of each other.

                    As a U* or Agile practicionner, you should not come to this list and
                    expect that "what you know to be true" will be accepted without
                    question. In fact, you should be prepared to revise "what you know is
                    true", as a result of what you find here.

                    As far as I can tell, the positions held by both U* and Agilists on this
                    list are far more nuanced than the views of their respective
                    constituancies. In other words, the Agilists on this list are more
                    user-centered than most Agilists out there. And most U* people on this
                    list are more Agile than most U* professionals out there.
                    ----

                    That lack of shared experience will always be a
                    hindrence to this discussion group. (Discussion lists
                    don't create the shared experience we need. Project
                    work does.) It would be interesting, Jeff, to take a
                    poll to assess how many folks on this list have
                    actually collaborated on an Agile/UI project.

                    Personally, I'm here to learn about working in an
                    Agile context, but have never worked in one. I wonder
                    how many Agilists on this list have ever worked with a dedicated UX
                    professional.

                    -- Alain:
                    I for one work with one ollegue who is an HCI person all the time, and I
                    really appreciate his contributions to my projects.
                    ----
                  • Ron Vutpakdi
                    ... We have before, just not recently. You might want to check the archives. ... A number of people are integrating agile and usability successfully. One
                    Message 9 of 20 , Dec 7, 2005
                    • 0 Attachment
                      --- In agile-usability@yahoogroups.com, "Dymond, Robin"
                      <robin.dymond@c...> wrote:
                      >
                      > How come no one in this group is discussing ideas on integrating
                      > usability and agile?
                      >
                      We have before, just not recently. You might want to check the archives.

                      > How are you integrating agile
                      > methods with usability ideas on a daily basis? Are you? Or do you have
                      > waterfall processes, in which the IAs do usability as part of the
                      > "Design" process, with mockups from photoshop, that may or may not
                      > become actual software?

                      A number of people are integrating agile and usability successfully.
                      One method is to basically be one iteration or otherwise just slightly
                      ahead of the developers while trying to keep an eye out for a general
                      idea of what might be coming down the road.

                      On the usability and design side, a lot of practices involve scaling
                      activities appropriately.

                      On the development side, one practice seems to involve learning how to
                      engage and consult usability rather than assuming that they don't matter.

                      >
                      > This group has been a bit of a disappointment. I think there is lots of
                      > work to be done. Usability practitioners will benefit from better
                      > integration with agile teams building better software quickly. But teams
                      > will adopt Agile with or without usability practitioners or their ideas
                      > on board.

                      So it's just the usability practioners and designers who have to
                      adapt, and not the whole team?

                      >
                      > But maybe, with all of the good feedback agile teams get from working
                      > closely with a customer, usability is inherent, and IAs are largely
                      > irrelevant for most projects?
                      >

                      Design still does matter as does usability. So does everyone learning
                      how to work together as a team and draw from the best of everyone's
                      skills so that the whole team is more than the sum of the individual
                      members.

                      I don't normally see teams where customers, through their feedback
                      effectively design the internal or backend architecture. Why should
                      the interface be any different? Yes, the feedback and input matter,
                      are highly important, and should be used to influence the design.
                      But, that doesn't mean that you want to give the customer the task of
                      designing the interface for you.

                      Ron
                    • Ron Vutpakdi
                      ... driving cars) ... Just as an aside: the doctors and psychologists that I know who use speech to text for dictation do so because it s faster for them to
                      Message 10 of 20 , Dec 7, 2005
                      • 0 Attachment
                        --- In agile-usability@yahoogroups.com, "Desilets, Alain"
                        <alain.desilets@n...> wrote:
                        > Today's speech interfaces CAN be very useful, but only in limited
                        context like:
                        >
                        > - people who can't type (ex: RSI, paraplegics)
                        > - people who WON'T type (ex: "REAL lawyers/doctors don't type!")
                        > - people who are in hands and/or eyes busy situation (ex: people
                        driving cars)
                        >

                        Just as an aside: the doctors and psychologists that I know who use
                        speech to text for dictation do so because it's faster for them to
                        dictate reports rather than typing (not that they can't type). They
                        can do so while walking around or even just sitting at their desk, but
                        speaking is faster than typing.

                        In their cases, with a special dictionary and training, the
                        recognition is generally better than 95% since the vocabulary used is
                        considerably more limited than full speech.

                        Many doctors and psychologists still dictate reports/evaluations to a
                        phone service which then uses a person to transcribe the reports.

                        Ron
                      • Ron Vutpakdi
                        ... I have (as far as usability and design goes). But, then again, I m also on another list where there are occasional flashes of usability is irrelevant
                        Message 11 of 20 , Dec 7, 2005
                        • 0 Attachment
                          --- In agile-usability@yahoogroups.com, "Desilets, Alain"
                          <alain.desilets@n...> wrote:
                          > -- Alain:
                          > Interesting...
                          >
                          > I have not read anything on this list that to my eyes, questioned the
                          > relevance of either U* or Agile.

                          I have (as far as usability and design goes). But, then again, I'm
                          also on another list where there are occasional flashes of "usability
                          is irrelevant" from the interaction designers on the list. In both
                          cases, I see it as a mixture of infantile "us vs. them," "I know
                          everything so I don't need you," "this sandbox is not big enough for
                          the two of us," or "you don't get to play in my sandbox" attitudes.

                          It's harder to get to the point of working together well if one starts
                          with that attitude. Respect and valuing what everyone can bring to
                          the table is what teams need to use everyone's strengths.

                          I have worked on non-agile and agilish projects. And, I like to think
                          of myself as being a fairly agile designer / usability guy since I
                          adapt what I do to meet what the teams want/need/can handle. But,
                          things work best when the teams adapt as well.

                          Ron
                        • Desilets, Alain
                          ... From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of Ron Vutpakdi Sent: Wednesday, December 07, 2005 2:33 PM I have
                          Message 12 of 20 , Dec 7, 2005
                          • 0 Attachment
                            -----Original Message-----
                            From: agile-usability@yahoogroups.com
                            [mailto:agile-usability@yahoogroups.com] On Behalf Of Ron Vutpakdi
                            Sent: Wednesday, December 07, 2005 2:33 PM
                            I have (as far as usability and design goes). But, then again, I'm also
                            on another list where there are occasional flashes of "usability is
                            irrelevant" from the interaction designers on the list.

                            -- Alain:
                            For sure, you get the occasional posting of this sort on all lists
                            (including this one).

                            My point is that this list does not exhibit more of those types of
                            messages than your average mailing list.

                            Therefore, if you come to this list and feel that your discipline (be it
                            U* or Agile development) is being dismissed, you are probably not coming
                            to it with an open mind.
                            ----
                          • Desilets, Alain
                            Therefore, if you come to this list and feel that your discipline (be it U* or Agile development) is being dismissed, you are probably not coming to it with an
                            Message 13 of 20 , Dec 7, 2005
                            • 0 Attachment
                              Therefore, if you come to this list and feel that your discipline (be it
                              U* or Agile development) is being dismissed, you are probably not coming
                              to it with an open mind.

                              -- Alain:
                              BTW: in the above I didn't mean you, Ron Vutpakdi (I know you have an
                              open mind ;-)). I meant the generic you, as in "if someone comes to this
                              list and feels etc..."
                              -----
                            • Ron Vutpakdi
                              ... Darn, just before I was going fire off an angry reply. ;-) Seriously, I think that part of this discussion highlights what I ve thought for many years
                              Message 14 of 20 , Dec 7, 2005
                              • 0 Attachment
                                --- In agile-usability@yahoogroups.com, "Desilets, Alain"
                                <alain.desilets@n...> wrote:
                                >
                                > Therefore, if you come to this list and feel that your discipline (be it
                                > U* or Agile development) is being dismissed, you are probably not coming
                                > to it with an open mind.
                                >
                                > -- Alain:
                                > BTW: in the above I didn't mean you, Ron Vutpakdi (I know you have an
                                > open mind ;-)). I meant the generic you, as in "if someone comes to this
                                > list and feels etc..."
                                > -----
                                >
                                Darn, just before I was going fire off an angry reply. ;-)

                                Seriously, I think that part of this discussion highlights what I've
                                thought for many years (starting back when I was primarily a
                                developer): the hardest part of software development (in a team) isn't
                                the technology, the architecture, or the interaction design: it's the
                                people aspect of working in a team and working with those outside of
                                the team proper.

                                Seems to me that cross cultural communication and understanding is one
                                of the biggest challenges where the "cross cultural" could be the
                                result of different disciplines, cultures, languages, locations,
                                and/or previous experiences. I'm currently slamming my head against
                                this particular brick wall. Most of the developers that I'm working
                                with are in Scotland and have never worked with an interaction
                                designer before. So I've got the discipline, location, culture, and
                                previous experience divide to bridge (some would also argue that
                                Scottish English counts as a different language than American English
                                :-) ).

                                More face to face time and experience working together would really help.

                                On a more relevant note, how many people here have worked on an agile
                                development team split across 6+ time zones? Any suggestions? We
                                really need the equivalent of a shared team room where we can put up
                                task/story cards and such, and SharePoint (uggh) just isn't cutting it.

                                I thought about trying to do a virtual one in Canvas, but that limits
                                who can effectively update the "wall".

                                Ron
                              • Jade Ohlhauser
                                And here I thought you had stopped following this list, Robin :) * I think a challenge to this discussion is that the knowledge a lot of people desire is about
                                Message 15 of 20 , Dec 7, 2005
                                • 0 Attachment
                                  And here I thought you had stopped following this list, Robin :) *
                                   
                                  I think a challenge to this discussion is that the knowledge a lot of people desire is about the details. I personally believe it's not the big ideas that make the most difference on real world projects, it's the hundreds of little things.
                                   
                                  Let me put it another way. A while ago I was at the (good) CANUX conference in Banff (http://www.flickr.com/photos/tags/creativecanux/). There was various presentations on various subjects, but the ones that really stood out for me were the case studies. I saw their analysis studies, their interesting life-size cardboard personas covered in multi-color post-its, etc. To me those "facts" were more interesting and more useful than the academic arguments.
                                   
                                  Unfortunately I don't have any suggestions for this list re: that.
                                   
                                  Anyway, Ron said:
                                   
                                  "... the hardest part of software development (in a team) isn't
                                  the technology, the architecture, or the interaction design: it's the
                                  people aspect of working in a team and working with those outside of
                                  the team proper."
                                  I agree, one topic I'd enjoy going into deeper is documentation. At our shop documentation and mockups/prototypes are a key part of the relationship between usability and development and the agileness of both. We started down this road with the wiki discussion. Anyone else?
                                   
                                  Jade Ohlhauser
                                  Product Manager
                                  RPM Software                                 
                                  www.rpmsoftware.com 403-265-6727 x704
                                   
                                   
                                   
                                   
                                  * Disclaimer: we worked together for a year and a half, but it felt much longer (in a good way)
                                   
                                   


                                  From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of Dymond, Robin
                                  Sent: Wednesday, December 07, 2005 8:36 AM
                                  To: agile-usability@yahoogroups.com
                                  Subject: RE: [agile-usability] QWERTY, mouse, and novel input

                                  Well, you won't find me trading my mouse for a touch screen and a chop
                                  stick any time soon!

                                  I agree with Larry, our systems are built within a context, the idea of
                                  building an enterprise app with something other than a keyboard and
                                  mouse is quixotic.

                                  How come no one in this group is discussing ideas on integrating
                                  usability and agile?

                                  Agile is rapidly gaining adoption across the software industry, for
                                  example Microsoft has recently become a strong proponent of Scrum and is
                                  promoting it with their development tools. How are you integrating agile
                                  methods with usability ideas on a daily basis? Are you? Or do you have
                                  waterfall processes, in which the IAs do usability as part of the
                                  "Design" process, with mockups from photoshop, that may or may not
                                  become actual software?

                                  This group has been a bit of a disappointment. I think there is lots of
                                  work to be done. Usability practitioners will benefit from better
                                  integration with agile teams building better software quickly. But teams
                                  will adopt Agile with or without usability practitioners or their ideas
                                  on board.

                                  But maybe, with all of the good feedback agile teams get from working
                                  closely with a customer, usability is inherent, and IAs are largely
                                  irrelevant for most projects?

                                  Thoughts?

                                  Robin Dymond

                                  -----Original Message-----
                                  From: agile-usability@yahoogroups.com
                                  [mailto:agile-usability@yahoogroups.com] On Behalf Of Joshua Seiden
                                  Sent: Tuesday, December 06, 2005 7:45 PM
                                  To: agile-usability@yahoogroups.com
                                  Subject: RE: [agile-usability] QWERTY, mouse, and novel input


                                  Larry wrote:

                                  > 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.

                                  And:

                                  > Bill Buxton distinguishes imitating physical reality in
                                  > GUI design from using externally learned skills and
                                  > associations within the framework of effective interaction
                                  > idioms.


                                  Josh replies: Buxton also said (at your last forUSE conference)
                                  something
                                  like this: as long as we are interacting with the computer using a
                                  mouse, we
                                  are interacting with the world using the equivalent of the point of a
                                  single
                                  chopstick. That gives us the manipulative power of a fruitfly!

                                  To be fair, this was in the context of a discussion of the limits of
                                  general
                                  purpose devices and general purpose computing.

                                  JS






                                  Yahoo! Groups Links







                                  The information contained in this e-mail is confidential and/or proprietary
                                  to Capital One and/or its affiliates. The information transmitted herewith
                                  is intended only for use by the individual or entity to which it is
                                  addressed.  If the reader of this message is not the intended recipient,
                                  you are hereby notified that any review, retransmission, dissemination,
                                  distribution, copying or other use of, or taking of any action in reliance
                                  upon this information is strictly prohibited. If you have received this
                                  communication in error, please contact the sender and delete the material
                                  from your computer.

                                • Desilets, Alain
                                  Seriously, I think that part of this discussion highlights what I ve thought for many years (starting back when I was primarily a developer): the hardest part
                                  Message 16 of 20 , Dec 7, 2005
                                  • 0 Attachment
                                    Seriously, I think that part of this discussion highlights what I've
                                    thought for many years (starting back when I was primarily a
                                    developer): the hardest part of software development (in a team) isn't
                                    the technology, the architecture, or the interaction design: it's the
                                    people aspect of working in a team and working with those outside of the
                                    team proper.

                                    Seems to me that cross cultural communication and understanding is one
                                    of the biggest challenges where the "cross cultural" could be the result
                                    of different disciplines, cultures, languages, locations, and/or
                                    previous experiences. I'm currently slamming my head against this
                                    particular brick wall. Most of the developers that I'm working with are
                                    in Scotland and have never worked with an interaction designer before.
                                    So I've got the discipline, location, culture, and previous experience
                                    divide to bridge (some would also argue that Scottish English counts as
                                    a different language than American English
                                    :-) ).

                                    More face to face time and experience working together would really
                                    help.

                                    -- Alain:
                                    Righto. To quote from the Agile manifesto:

                                    "Individuals and interactions over processes and tools"

                                    This is the only way to bridge the various culture gaps involved in a
                                    software project.
                                    ----









                                    Yahoo! Groups Links
                                  • Larry Constantine
                                    ... we ... single ... On many occasions while sharing dimsum I have been impressed by what can be accomplished with chopsticks. ;-) --Larry Constantine, IDSA
                                    Message 17 of 20 , Dec 8, 2005
                                    • 0 Attachment
                                      > Josh replies: Buxton also said (at your last forUSE conference) something
                                      > like this: as long as we are interacting with the computer using a mouse,
                                      we
                                      > are interacting with the world using the equivalent of the point of a
                                      single
                                      > chopstick. That gives us the manipulative power of a fruitfly!

                                      On many occasions while sharing dimsum I have been impressed by what can be
                                      accomplished with chopsticks. ;-)

                                      --Larry Constantine, IDSA
                                    • Larry Constantine
                                      ... Another interesting example. Audio noting to the chart, whether supported by speech-to-text software or human transcription is a must-have function in
                                      Message 18 of 20 , Dec 8, 2005
                                      • 0 Attachment
                                        Ron Vutpakdi wrote:

                                        > Just as an aside: the doctors and psychologists that I know who use
                                        > speech to text for dictation do so because it's faster for them to
                                        > dictate reports rather than typing (not that they can't type). They
                                        > can do so while walking around or even just sitting at their desk, but
                                        > speaking is faster than typing.
                                        >
                                        > In their cases, with a special dictionary and training, the
                                        > recognition is generally better than 95% since the vocabulary used is
                                        > considerably more limited than full speech.
                                        >
                                        > Many doctors and psychologists still dictate reports/evaluations to a
                                        > phone service which then uses a person to transcribe the reports.

                                        Another interesting example. Audio noting to the chart, whether supported by
                                        speech-to-text software or human transcription is a must-have function in
                                        modern medical informatics, but that does not mean it is truly efficient or
                                        sufficiently reliable to meet real medical practice objectives. Because of
                                        the high potential for errors (95% accuracy sounds good until you turn it
                                        around: 1 out of 20 words is wrong), transcribed audio does not become part
                                        of the legal patient record until the dictating clinician reviews and signs
                                        off on the transcription. Reviewing for errors and correcting is a somewhat
                                        tedious process and itself quite error prone, particularly as clinicians
                                        typically do so at a later time when the context is no longer fresh in their
                                        heads. Transcribed audio, even after review, correction, and sign-off, has a
                                        significantly higher error rate than directly entered notes and orders.

                                        I don't know if the analysis has been done in medical settings, but in other
                                        contexts, when all activities in the process are taken into
                                        account(including slowed speech, repetition and correction on the fly,
                                        review and editing), the effective total throughput is almost invariably
                                        less than even slow direct keyboard entry. We can process up to about 400
                                        wpm when heard and rapid speech clocks at nearly 200 wpm, although 120-160
                                        is considered tops for persuasive communication. The best commercial
                                        "trained" speech-to-text systems are typically only good to about 100 wpm.
                                        But, users typically find they can spend as much time correcting errors as
                                        dictating (some report as much as 2-3 times). So effective throughput drops
                                        to well within the range of typical typing (30-60 wpm).

                                        That said, it can still be more efficient use of the clinician's time if
                                        notes and orders can be dictated while moving between patients or while
                                        riding the subway. (Although HIPAA compliance may become an issue in the
                                        latter case.)

                                        I think audio notes and orders could actually diminish in use over time, at
                                        least in the short run, because the new generation of clinicians has grown
                                        up with computers. My personal physician does all his own notes and orders
                                        directly into the medical system, typing away at 100+ words/minute. When I
                                        commented, he mentioned growing up with computers and video games, then
                                        added that being a musician also helped!

                                        --Larry Constantine, IDSA
                                      • Desilets, Alain
                                        I don t know if the analysis has been done in medical settings, but in other contexts, when all activities in the process are taken into account(including
                                        Message 19 of 20 , Dec 8, 2005
                                        • 0 Attachment
                                          I don't know if the analysis has been done in medical settings, but in
                                          other contexts, when all activities in the process are taken into
                                          account(including slowed speech, repetition and correction on the fly,
                                          review and editing), the effective total throughput is almost invariably
                                          less than even slow direct keyboard entry. We can process up to about
                                          400 wpm when heard and rapid speech clocks at nearly 200 wpm, although
                                          120-160 is considered tops for persuasive communication. The best
                                          commercial "trained" speech-to-text systems are typically only good to
                                          about 100 wpm. But, users typically find they can spend as much time
                                          correcting errors as dictating (some report as much as 2-3 times). So
                                          effective throughput drops to well within the range of typical typing
                                          (30-60 wpm).

                                          -- Alain:
                                          In one of the projects I worked on (computer-assisted transcription of
                                          the debates at the House of Commons of Canada), we did some WOZ
                                          experiments with professional transcribers and found that we broke even
                                          when the speech recognition system had an accuracy of around 85%. In
                                          other words, when accuracy was above 85%, it took less time to correct
                                          errors in the transcription than to transcribe from scratch for the raw
                                          audio.
                                          ----
                                        • elise_urbanek
                                          ... From a linguistics point of view, FYI, they re considered different varieties of the same language. :)
                                          Message 20 of 20 , Dec 25, 2005
                                          • 0 Attachment
                                            --- In agile-usability@yahoogroups.com, "Ron Vutpakdi" <vutpakdi@a...>
                                            wrote:
                                            >
                                            > Darn, just before I was going fire off an angry reply. ;-)
                                            >
                                            > Seriously, I think that part of this discussion highlights what I've
                                            > thought for many years (starting back when I was primarily a
                                            > developer): the hardest part of software development (in a team) isn't
                                            > the technology, the architecture, or the interaction design: it's the
                                            > people aspect of working in a team and working with those outside of
                                            > the team proper.
                                            >
                                            > Seems to me that cross cultural communication and understanding is one
                                            > of the biggest challenges where the "cross cultural" could be the
                                            > result of different disciplines, cultures, languages, locations,
                                            > and/or previous experiences. I'm currently slamming my head against
                                            > this particular brick wall. Most of the developers that I'm working
                                            > with are in Scotland and have never worked with an interaction
                                            > designer before. So I've got the discipline, location, culture, and
                                            > previous experience divide to bridge (some would also argue that
                                            > Scottish English counts as a different language than American English
                                            > :-) ).


                                            From a linguistics point of view, FYI, they're considered different
                                            'varieties' of the same language. :)
                                          Your message has been successfully submitted and would be delivered to recipients shortly.