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

RE: [agile-usability] Re: Could UI Engineering have lead to Wiki?

Expand Messages
  • Keith Nicholas
    Some stuff you can go right ahead and develop and have working software very quickly, however this often has a low amount of invention. We have a vision
    Message 1 of 28 , Sep 1, 2004
    • 0 Attachment
      Some stuff you can go right ahead and develop and have working software
      very quickly, however this often has a low amount of invention.

      We have a vision processing system....we have researchers who invent new
      ways of processing these images to work out new information.. We have
      control systems where we have researchers coming up with control
      algorithms.... we don't immediately try to express the ideas in
      software (sometimes we do if it's the quickest thing to explore an
      idea...). The domain of Machine Vision and the domain of Control Theory
      have their own ways and methods of inventing / designing things. These
      then get expressed in software. Then depending on how the feedback from
      that goes more changes may be made to the software or other techniques
      will be used to come up with solutions.

      I think the same kinds of thing applies with Interaction Design. Some
      stuff doesn't take too much to develop, you can very quickly apply well
      known ideas and principles (patterns) and get a good working piece of
      software. Sometimes you need to invent a new kind of interaction.
      Expressing this in software may or may not be the fastest way to develop
      this idea.

      Part of what influences this is... How good does it have to be? Do you
      really need to invent something new?


      Regards,

      Keith

      > -----Original Message-----
      > From: Ron Jeffries [mailto:ronjeffries@...]
      > Sent: Thursday, 2 September 2004 10:16 a.m.
      > To: agile-usability@yahoogroups.com
      > Subject: Re: [agile-usability] Re: Could UI Engineering have
      > lead to Wiki?
      >
      >
      > On Wednesday, September 1, 2004, at 5:50:28 PM, Jeff Patton wrote:
      >
      > > I haven't read back up this thread, so I'm coming in late.
      > I suspect
      > > Petteri described how one might design a wiki using goal directed
      > > design. By that I mean "invent" it. Ron, I suspect you are able to
      > > technically design a wiki given a working prototype - like
      > every other
      > > wiki you've seen before. The question is could you invent
      > something
      > > like a wiki in a few minutes?
      >
      > I'm not sure that is the question, but I accept that it is
      > /a/ question.
      >
      > My point was that the process Petteri described took a long
      > time just to describe, and very much longer to execute, and
      > that in the time it would take, one very likely has the
      > choice between having an idea at the end of the time, or an
      > idea plus a program that implements the idea. I believe the
      > latter is generally preferable.
      >
      > > If you had to invent something very appropriate for a
      > particular task,
      > > as appropriate as a wiki is to its task, how would you go
      > about it? If
      > > you start by thinking about the people who will be using the tool,
      > > what their goals are, and how they might best achieve their
      > goals, AND
      > > you think about those things before you write you first
      > line of code,
      > > you'd be doing design up front, and using a user-centered design
      > > approach at that. Interaction Design, User Centered Design, Product
      > > Design isn't about how you document requirements for
      > developers - it's how you design/invent those
      > > requirements.
      >
      > Yes. And there now exist developers who can develop things
      > almost as rapidly as they can be thought of -- far more
      > rapidly than is conventionally thought. That changes the
      > point of optimum between dreaming, and dreaming plus building.
      >
      > You know exactly what I'm talking about, I feel certain. How
      > long do you recommend people sit around musing about a way to
      > enter stuff into a web site before getting down to building
      > it? A few days? A week? A month? A year?
      >
      > > I'd be curious how you'd go about inventing something as
      > appropriate
      > > as a wiki? What steps would you go through to discover what a best
      > > solution might be?
      >
      > As far as I know, there are no "steps" for invention. I would
      > work intimately with people who had the problem, talking,
      > doing paper prototypes, and showing them running tested
      > software throughout. I'd try not to lock in technically or
      > otherwise, on anything.
      >
      > I'm not sure it would lead to a "best" solution, nor that a
      > "best" solution is possible, or even well-defined. I'm sure
      > it would lead to something that met the needs in cost and
      > function as well as the assembled multitudes were able to imagine.
      >
      > It would be my guess, by the way, that explaining a wiki is
      > somewhere
      > between impossible and pointless. Everyone I've ever
      > explained it to, or
      > heard of having it explained to them, didn't get it.
      > Everyone who tries
      > it, gets it.
      >
      > What would you do in a situation such as you described? How
      > different do you imagine it to be from what I'd do?
      >
      > Ron Jeffries
      > www.XProgramming.com
      > It is not the strongest of the species that survive, not the
      > most intelligent, but the one most responsive to change. --
      > Charles Darwin
      >
      > ------------------------ Yahoo! Groups Sponsor
      > --------------------~-->
      > $9.95 domain names from Yahoo!. Register anything.
      > http://us.click.yahoo.com/J8kdrA/y20IAA/yQLSAA> /dpFolB/TM
      >
      >
      > --------------------------------------------------------------
      > ------~->
      >
      >
      > Yahoo! Groups Links
      >
      >
      >
      >
      >
    • Frank Maurer
      From: Lauren Berry [mailto:laurenb@compacsort.com] Sent: Wednesday, September 01, 2004 4:20 PM To: agile-usability@yahoogroups.com Subject: RE:
      Message 2 of 28 , Sep 1, 2004
      • 0 Attachment
        Message
        From: Lauren Berry [mailto:laurenb@...]
        Sent: Wednesday, September 01, 2004 4:20 PM
        To: agile-usability@yahoogroups.com
        Subject: RE: [agile-usability] Could UI Engineering have lead to Wiki?


         > Unfortunately, the more usable solution is MUCH, MUCH, MUCH harder to
         > implement (remember: only 10 pages of code for the simple solution!), yet it
         > is *NOT* MUCH, MUCH, MUCH easier to use. So it makes sense to go for the
         > implementationally simpler solution.
         
        I think this is a very relevant comment.  would your user rather have a "pretty good" product (in terms of usability) now, or an "awesome" product in 3 months time? 
        [Frank Maurer] This is exactly a core difference: usability (the focus of interaction design, ..) versus business value (the focus of the agile community). These dimensions are not the same - although there is a big overlap.
         
        Frank
      • Jeff Patton
        ... question. I probably should have read the original question. ;-) ... just to ... would ... end of ... believe the ... I d agree. I spent the better part
        Message 3 of 28 , Sep 1, 2004
        • 0 Attachment
          --- In agile-usability@yahoogroups.com, Ron Jeffries
          <ronjeffries@X...> wrote:
          > I'm not sure that is the question, but I accept that it is /a/
          question.

          I probably should have read the original question. ;-)

          > My point was that the process Petteri described took a long time
          just to
          > describe, and very much longer to execute, and that in the time it
          would
          > take, one very likely has the choice between having an idea at the
          end of
          > the time, or an idea plus a program that implements the idea. I
          believe the
          > latter is generally preferable.

          I'd agree. I spent the better part of the day today building paper
          prototyoes. [BTW: _Paper Prototying_ from Carolyn Snyder's a very
          worthwhile book.] The testing with the customers went great. As a
          result of doing some simple role and task analysis, our UI prototypes
          were more right than I expected. The customer group had fun going
          through them; we got a lot of great feedback; the experience was
          pretty worthwhile. The whole process from drawing the prototypes
          through testing and feedback took a few hours.

          But while building thes prototypes I kept thinking to myself that it
          really wouldn't take me too much longer to build this stuff in
          code.

          > Yes. And there now exist developers who can develop things almost as
          > rapidly as they can be thought of -- far more rapidly than is
          > conventionally thought. That changes the point of optimum between
          dreaming,
          > and dreaming plus building.

          I buy that. I believe that many traditional interaction designers
          have too much experience with with the other kind of developers.

          >
          > You know exactly what I'm talking about, I feel certain. How long
          do you
          > recommend people sit around musing about a way to enter stuff into
          a web
          > site before getting down to building it? A few days? A week? A
          month? A
          > year?

          A few hours. Maybe a day or two. But, the dreaming continues while
          the building continues. Either by different people at the same time,
          or by developers who know how to do the dreaming in a productive way,
          and how to change hats. Think of how Fowler described changing hats
          from the refactoring hat to the coding/building hat. Once you
          realize you're changing hats, you can learn to do it pretty quickly.

          > As far as I know, there are no "steps" for invention. I would work
          > intimately with people who had the problem, talking, doing paper
          > prototypes, and showing them running tested software throughout.
          I'd try
          > not to lock in technically or otherwise, on anything.
          >
          > I'm not sure it would lead to a "best" solution, nor that a "best"
          solution
          > is possible, or even well-defined. I'm sure it would lead to
          something that
          > met the needs in cost and function as well as the assembled
          multitudes were
          > able to imagine.
          >
          > It would be my guess, by the way, that explaining a wiki is
          somewhere
          > between impossible and pointless. Everyone I've ever explained it
          to, or
          > heard of having it explained to them, didn't get it. Everyone who
          tries
          > it, gets it.
          >
          > What would you do in a situation such as you described?

          I think there _are_ steps - sort of. Not N steps that when followed
          always work, but rather lots of dependent techniques that when
          applied allow you to circle closer to solutions. User centered
          design stuff like roles and role models, personas, task models,
          protoypes, collaboration, and conversation. When in doubt, I pack my
          head full of interesting information gleamed from these techniques
          about the people the product serves and what I /really/ believe their
          goals to be, then I sleep on it. Invention often occurrs at some
          later time, accidentally. But, it's not so accidental when you
          consider the fertile ground you gave it to grow in.

          I think there are lots of other ways to create fertile ground ground
          for invention, and I'm confident you know lots yourself. [if anyone
          knows something about fertalizer creation it's Ron... ;-)] I kinda
          like this UCD stuff because it acknowledges there is something you
          can do and provides some techniques that seem to be working - at
          least for me.

          > How different do
          > you imagine it to be from what I'd do?

          I think you're like most "level 3" people - I think that's what
          Alistair would call you. You're smart enough, you listen well
          enough, and think clearly enough that you do what seems to be the
          most appropriate thing, and it often works out right. If it doesn't
          you learn and adjust. I just don't think most folks are like you -
          at least not yet. Just as XP gives some "wax-on-wax-off" sorts of
          guidelines for developers that ultimately help them evolve past the
          practices into thinking more clearly about their craft, I belive UCD
          provides a similar mental framework for designers to invent best
          solutions to user's problems. I don't belive it's the only way -
          just as I don't believe it's necessary to develop good software test-
          first. But, just as I wouldn't write code without using a unit
          testing framework, I wouldn't design without out applying at least
          rudimentary UCD approaches.

          Sorry for the long winded response - and thank you for your response.

          -Jeff

          >
          > Ron Jeffries
          > www.XProgramming.com
          > It is not the strongest of the species that survive, not the most
          intelligent,
          > but the one most responsive to change. -- Charles Darw
        • Lauren Berry
          [Frank Maurer] versus business value (the focus of the agile community). [Lauren] i d say the focus of EVERY bussiness - surely? ... From: Frank Maurer
          Message 4 of 28 , Sep 1, 2004
          • 0 Attachment
            Message
            [Frank Maurer] versus business value (the focus of the agile community).
            [Lauren] i'd say the focus of EVERY bussiness - surely?
            -----Original Message-----
            From: Frank Maurer [mailto:maurer@...]
            Sent: Thursday, 2 September 2004 11:30 a.m.
            To: agile-usability@yahoogroups.com
            Subject: RE: [agile-usability] Could UI Engineering have lead to Wiki?

            From: Lauren Berry [mailto:laurenb@...]
            Sent: Wednesday, September 01, 2004 4:20 PM
            To: agile-usability@yahoogroups.com
            Subject: RE: [agile-usability] Could UI Engineering have lead to Wiki?


             > Unfortunately, the more usable solution is MUCH, MUCH, MUCH harder to
             > implement (remember: only 10 pages of code for the simple solution!), yet it
             > is *NOT* MUCH, MUCH, MUCH easier to use. So it makes sense to go for the
             > implementationally simpler solution.
             
            I think this is a very relevant comment.  would your user rather have a "pretty good" product (in terms of usability) now, or an "awesome" product in 3 months time? 
            [Frank Maurer] This is exactly a core difference: usability (the focus of interaction design, ..) versus business value (the focus of the agile community). These dimensions are not the same - although there is a big overlap.
             
            Frank

          • Jon Kern
            Messagei ll exhibit poor etiquette here by doing a cannonball into this long thread. (Been so busy i am 200+ unread posts behind... and the topic was a
            Message 5 of 28 , Sep 1, 2004
            • 0 Attachment
              Message
              i'll exhibit poor etiquette here by doing a cannonball into this long thread. (Been so busy i am 200+ unread posts behind... and the topic was a headline grabber :=)
               
              In some sense, I would argue that you cannot even ask this loaded (?) question -- unless, you pose it with a twist.
               
              If a business need requested the features and functions that a wiki exhibits, gave a hint at the users, and a glance at the budget, then I hope that UI engineering would have arrived at the simple solution that is a wiki, as ward knows it :=)
               
              1) If UI engineering would not have arrived at the wiki-like solution, then go and fix the engineering principles
               
              2) This might be a great test!
               
              Would UI engineering create Google?
              How about IM clients?
              I hope to Goodness it wouldn't create MS Word...
               
              3) Who says there wasn't UI engineering involved??
               
              Thanks for indulging my barging in post... Sorry if it repeats others'

              -- jon

              -----Original Message-----
              From: Lauren Berry [mailto:laurenb@...]
              Sent: Wednesday, September 01, 2004 11:16 PM
              To: agile-usability@yahoogroups.com
              Subject: RE: [agile-usability] Could UI Engineering have lead to Wiki?

              [Frank Maurer] versus business value (the focus of the agile community).
              [Lauren] i'd say the focus of EVERY bussiness - surely?
              -----Original Message-----
              From: Frank Maurer [mailto:maurer@...]
              Sent: Thursday, 2 September 2004 11:30 a.m.
              To: agile-usability@yahoogroups.com
              Subject: RE: [agile-usability] Could UI Engineering have lead to Wiki?

              From: Lauren Berry [mailto:laurenb@...]
              Sent: Wednesday, September 01, 2004 4:20 PM
              To: agile-usability@yahoogroups.com
              Subject: RE: [agile-usability] Could UI Engineering have lead to Wiki?


               > Unfortunately, the more usable solution is MUCH, MUCH, MUCH harder to
               > implement (remember: only 10 pages of code for the simple solution!), yet it
               > is *NOT* MUCH, MUCH, MUCH easier to use. So it makes sense to go for the
               > implementationally simpler solution.
               
              I think this is a very relevant comment.  would your user rather have a "pretty good" product (in terms of usability) now, or an "awesome" product in 3 months time? 
              [Frank Maurer] This is exactly a core difference: usability (the focus of interaction design, ..) versus business value (the focus of the agile community). These dimensions are not the same - although there is a big overlap.
               
              Frank


            • Petteri Hiisilä
              ... Yes, I spend most of my time either talking to end users or thinking about their goals. And also I spend most of my time talking to engineers. As I wrote
              Message 6 of 28 , Sep 2, 2004
              • 0 Attachment
                Hugh Beyer wrote:
                Yes, Wiki is a great, very goal-oriented piece of invention. Someone must have had a goal-directed mind to come up with something like that. We use it as our documenting tool at the moment, and the documenting speed has at least tripled. Almost everybody use it.

                And yes, goal-directed design excercise brings up solutions like that, and better. User-centered design always doesn't. There's a BIG difference. E-mail wasn't invented by stuying envelope usability, or asking snail-mail users how the envelope should be improved. We need to understand deeper motivations and frustrations to be really really creative.

                I'm not saying that UI engineering or user-centered methodology can't do that. A lot still depends on the designer's personal abilities. A formal design process based on and directed by a deep understanding of human goals and motivations can greatly improve your chances of success. 
                I assume you mean "user-centered design doesn't always" result in solutions like that?
                 
                Even so, I think your view of user-centered design is too narrow. What are the goals that you are directing your design towards? You can't know unless you talk to them. Note that Wiki is an example of people designing for themselves and people like them, which isn't the case for most of us.


                Yes, I spend most of my time either talking to end users or thinking about their goals. And also I spend most of my time talking to engineers. As I wrote before, they sit next to me.  I'm sorry if don't make myself clear. It's kinda hard with email.

                I'd be ready to argue, that almost any user-centered / goal-directed / hat-invented process works as long as in the beginning you spend 80 % of your brain processing time on thinking very very hard, how your design will fulfill some real human users real needs in a realistic day. Very practical thinking. It's not just the process. It's the attitude, mindset, way of seeing things. I don't have any backup for this idea, and I'm not willing to present any. But I see this pattern in most methods that aim to humanize technology, and it has been working brilliantly in every single project that I've done. And the opposite hasn't.

                 - Petteri

                    Hugh
                 


              • Keith Nicholas
                This is what XP is.... fufill a real need - Story scheduled by customer lots of thinking about design expressed as deliverable software Only difference
                Message 7 of 28 , Sep 2, 2004
                • 0 Attachment
                  This is what XP is....

                  fufill a real need - Story scheduled by customer
                  lots of thinking about design expressed as deliverable software

                  Only difference here is how much time you need to do this.

                  The challenge to interaction designers is can you do it in small
                  amounts of time in an incremental way? Same question was put to Big
                  Design Up Front people in the software design world....effective
                  techniques and thinking mindsets came about that allowed for very
                  quick delivery of software

                  Can you come up with new thinking that will allow for very quick
                  incremental interaction designs? If not, Im sure thats what will
                  happen....It will all be agilized. :-)

                  Regards,

                  Keith



                  ----- Original Message -----
                  From: Petteri Hiisilä <petteri.hiisila@...>
                  Date: Thu, 02 Sep 2004 11:59:47 +0300
                  Subject: Re: [agile-usability] Re: Could UI Engineering have lead to Wiki?
                  To: agile-usability@yahoogroups.com

                  I'd be ready to argue, that almost any user-centered / goal-directed
                  / hat-invented process works as long as in the beginning you spend 80
                  % of your brain processing time on thinking very very hard, how your
                  design will fulfill some real human users real needs in a realistic
                  day. Very practical thinking. It's not just the process. It's the
                  attitude, mindset, way of seeing things. I don't have any backup for
                  this idea, and I'm not willing to present any. But I see this pattern
                  in most methods that aim to humanize technology, and it has been
                  working brilliantly in every single project that I've done. And the
                  opposite hasn't.

                  - Petteri
                • Desilets, Alain
                  [Alain] ... it ... [Lauren] I think this is a very relevant comment. would your user rather have a pretty good product (in terms of usability) now, or an
                  Message 8 of 28 , Sep 2, 2004
                  • 0 Attachment
                    Message
                    [Alain] 
                     
                      > Unfortunately, the more usable solution is MUCH, MUCH, MUCH harder to
                     > implement (remember: only 10 pages of code for the simple solution!), yet it
                     > is *NOT* MUCH, MUCH, MUCH easier to use. So it makes sense to go for the
                     > implementationally simpler solution. 
                     
                    [Lauren] 
                    I think this is a very relevant comment.  would your user rather have a "pretty good" product (in terms of usability) now, or an "awesome" product in 3 months time? 
                     
                    [Alain]
                     
                    I think you misunderstand what I meant by "MUCH, MUCH, MUCH harder to implement". The question is more:
                     
                    Would your user rather have a "pretty good" product now, or invest into one year of development with no assurance that the "awesome" product can be done?
                     
                    The reason it's not clear that it can be done is that dynamic HTML is not standard across browsers. So far, the only WYSIWIG HTML editing tools I have seen that run inside a browser can only run inside IE.
                     
                    I think the market has already answered that question. A google search for allinurl: wiki shows that there are over 13 million pages out there that are served by wiki clones. Not bad for something that started out as 10 pages of perl code (BTW: allinurl: asp = 250 million pages and allinurl: jsp = 43 millions pages). On the other hand, I don't know of too many sites (none actually) that are served by a server that allows WYSIWYG editing inside the browser.
                     
                    ----

                    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

                     

                     
                     


                  • Desilets, Alain
                    [John] If a business need requested the features and functions that a wiki exhibits, gave a hint at the users, and a glance at the budget, then I hope that UI
                    Message 9 of 28 , Sep 2, 2004
                    • 0 Attachment
                      Message
                      [John]
                      If a business need requested the features and functions that a wiki exhibits, gave a hint at the users, and a glance at the budget, then I hope that UI engineering would have arrived at the simple solution that is a wiki, as ward knows it :=) 
                       
                      -- [Alain]
                      I believe a UI engineering process that focuses on optimising usability instead of business value probably would not (read my posting dated 9/1/2004 7:38 for details of that argument).
                      ---- 
                       
                      1) If UI engineering would not have arrived at the wiki-like solution, then go and fix the engineering principles 
                       
                      -- [Alain]
                      The fix is to make sure that you don't focus just on usability and that the vision for the system be created by a multidisciplinary team that collectively knows about the whole problem-solution space (business, users, UI designers and developpers). This is characterisitc of some interaction design methodologies (CD and GDD in particular), but I have read a lot of threads on this list recently that seemed to focus on usability only. So I don't think that this wisdom is well accepted in the UI design community.
                      ----- 
                       
                      3) Who says there wasn't UI engineering involved??
                       
                      -- [Alain]:
                      Well, let's find out. Who knows Ward well enough to ask him the question and have a good chance of getting a reply (I don't)?
                      ----
                    • Lauren Berry
                      ... From: Desilets, Alain [mailto:alain.desilets@nrc-cnrc.gc.ca] Sent: Friday, 3 September 2004 12:43 a.m. To: agile-usability@yahoogroups.com Subject: RE:
                      Message 10 of 28 , Sep 2, 2004
                      • 0 Attachment
                        Message
                         
                        -----Original Message-----
                        From: Desilets, Alain [mailto:alain.desilets@...]
                        Sent: Friday, 3 September 2004 12:43 a.m.
                        To: 'agile-usability@yahoogroups.com'
                        Subject: RE: [agile-usability] Could UI Engineering have lead to Wiki?

                        [Alain] 
                         
                          > Unfortunately, the more usable solution is MUCH, MUCH, MUCH harder to
                         > implement (remember: only 10 pages of code for the simple solution!), yet it
                         > is *NOT* MUCH, MUCH, MUCH easier to use. So it makes sense to go for the
                         > implementationally simpler solution. 
                         
                        [Lauren] 
                        I think this is a very relevant comment.  would your user rather have a "pretty good" product (in terms of usability) now, or an "awesome" product in 3 months time? 
                         
                        [Alain]
                         
                        I think you misunderstand what I meant by "MUCH, MUCH, MUCH harder to implement". The question is more:
                         
                        Would your user rather have a "pretty good" product now, or invest into one year of development with no assurance that the "awesome" product can be done?  
                         
                        [Lauren] yes i did understand, I completely agree, i was going for best case - worst case of course is the product is no better and is delivered late! I imagined everyone would have realised this was not guaranteed.
                         
                         
                      • Hugh Beyer
                        From: Jeff Patton [mailto:jpatton@acm.org] Sent: Wednesday, September 01, 2004 9:00 PM To: agile-usability@yahoogroups.com Subject: [agile-usability] Re: Could
                        Message 11 of 28 , Sep 2, 2004
                        • 0 Attachment
                          From: Jeff Patton [mailto:jpatton@...]
                          Sent: Wednesday, September 01, 2004 9:00 PM
                          To: agile-usability@yahoogroups.com
                          Subject: [agile-usability] Re: Could UI Engineering have lead to Wiki?
                          --- In agile-usability@yahoogroups.com, Ron Jeffries
                          <ronjeffries@X...> wrote: 
                          . . . 
                          > As far as I know, there are no "steps" for invention. I would work
                          > intimately with people who had the problem, talking, doing paper
                          > prototypes, and showing them running tested software throughout.

                          I think there _are_ steps - sort of.  Not N steps that when followed
                          always work, but rather lots of dependent techniques that when
                          applied allow you to circle closer to solutions.  User centered
                          design stuff like roles and role models, personas, task models,
                          protoypes, collaboration, and conversation.  When in doubt, I pack my
                          head full of interesting information gleamed from these techniques
                          about the people the product serves and what I /really/ believe their
                          goals to be, then I sleep on it.  Invention often occurrs at some
                          later time, accidentally.  But, it's not so accidental when you
                          consider the fertile ground you gave it to grow in. 

                          I think there are lots of other ways to create fertile ground ground
                          for invention, and I'm confident you know lots yourself.  [if anyone
                          knows something about fertalizer creation it's Ron... ;-)]  I kinda
                          like this UCD stuff because it acknowledges there is something you
                          can do and provides some techniques that seem to be working - at
                          least for me.   
                          Right. What's key, is to bring the understanding of the technology and the user together. How you do that is up to you. Ron does it by getting out there and having lots of interaction with actual users. Jeff is using techniques such as roles and personas to articulate his understanding.
                           
                          It's fine to work off an unarticulated understanding of your users if you're alone or in a small team where everyone's working closely with each other and with the users. The more formal and explicit representations are useful as ways to talk to each other about what you're finding out; to record what you discover so you can come back to it later; and to explain to other stakeholders why you're doing what you're doing. A not inconsiderable advantage of having a room full of representations of the user is that it's real easy to show a skeptical manager why your design makes sense.
                           
                          I think you're like most "level 3" people - I think that's what
                          Alistair would call you.  You're smart enough, you listen well
                          enough, and think clearly enough that you do what seems to be the
                          most appropriate thing, and it often works out right.  If it doesn't
                          you learn and adjust.  I just don't think most folks are like you -
                          at least not yet.  Just as XP gives some "wax-on-wax-off" sorts of
                          guidelines for developers that ultimately help them evolve past the
                          practices into thinking more clearly about their craft, I belive UCD
                          provides a similar mental framework for designers to invent best
                          solutions to user's problems.  I don't belive it's the only way -
                          just as I don't believe it's necessary to develop good software test-
                          first.  But, just as I wouldn't write code without using a unit
                          testing framework, I wouldn't design without out applying at least
                          rudimentary UCD approaches. 
                          I would call what Ron describes user-centered design. UCD isn't about any particular technique, it's about designing the system from an intimate understanding of how the user works. Ron's describing a low-overhead way to do that involving lots of back-and-forth conversations and rapid iterations.
                           
                              Hugh
                           
                        • Chris Pehura
                          I use techniques and processes for invention and creativity. Refer to Innovation Creation ... From: Hugh Beyer [mailto:beyer@incent.com] Sent: Thursday,
                          Message 12 of 28 , Sep 3, 2004
                          • 0 Attachment
                            I use techniques and processes for invention and creativity. Refer to Innovation Creation
                            -----Original Message-----
                            From: Hugh Beyer [mailto:beyer@...]
                            Sent: Thursday, September 02, 2004 9:36 PM
                            To: agile-usability@yahoogroups.com
                            Subject: RE: [agile-usability] Re: Could UI Engineering have lead to Wiki?

                            From: Jeff Patton [mailto:jpatton@...]
                            Sent: Wednesday, September 01, 2004 9:00 PM
                            To: agile-usability@yahoogroups.com
                            Subject: [agile-usability] Re: Could UI Engineering have lead to Wiki?
                            --- In agile-usability@yahoogroups.com, Ron Jeffries
                            <ronjeffries@X...> wrote: 
                            . . . 
                            > As far as I know, there are no "steps" for invention. I would work
                            > intimately with people who had the problem, talking, doing paper
                            > prototypes, and showing them running tested software throughout.

                            I think there _are_ steps - sort of.  Not N steps that when followed
                            always work, but rather lots of dependent techniques that when
                            applied allow you to circle closer to solutions.  User centered
                            design stuff like roles and role models, personas, task models,
                            protoypes, collaboration, and conversation.  When in doubt, I pack my
                            head full of interesting information gleamed from these techniques
                            about the people the product serves and what I /really/ believe their
                            goals to be, then I sleep on it.  Invention often occurrs at some
                            later time, accidentally.  But, it's not so accidental when you
                            consider the fertile ground you gave it to grow in. 

                            I think there are lots of other ways to create fertile ground ground
                            for invention, and I'm confident you know lots yourself.  [if anyone
                            knows something about fertalizer creation it's Ron... ;-)]  I kinda
                            like this UCD stuff because it acknowledges there is something you
                            can do and provides some techniques that seem to be working - at
                            least for me.   
                            Right. What's key, is to bring the understanding of the technology and the user together. How you do that is up to you. Ron does it by getting out there and having lots of interaction with actual users. Jeff is using techniques such as roles and personas to articulate his understanding.
                             
                            It's fine to work off an unarticulated understanding of your users if you're alone or in a small team where everyone's working closely with each other and with the users. The more formal and explicit representations are useful as ways to talk to each other about what you're finding out; to record what you discover so you can come back to it later; and to explain to other stakeholders why you're doing what you're doing. A not inconsiderable advantage of having a room full of representations of the user is that it's real easy to show a skeptical manager why your design makes sense.
                             
                            I think you're like most "level 3" people - I think that's what
                            Alistair would call you.  You're smart enough, you listen well
                            enough, and think clearly enough that you do what seems to be the
                            most appropriate thing, and it often works out right.  If it doesn't
                            you learn and adjust.  I just don't think most folks are like you -
                            at least not yet.  Just as XP gives some "wax-on-wax-off" sorts of
                            guidelines for developers that ultimately help them evolve past the
                            practices into thinking more clearly about their craft, I belive UCD
                            provides a similar mental framework for designers to invent best
                            solutions to user's problems.  I don't belive it's the only way -
                            just as I don't believe it's necessary to develop good software test-
                            first.  But, just as I wouldn't write code without using a unit
                            testing framework, I wouldn't design without out applying at least
                            rudimentary UCD approaches. 
                            I would call what Ron describes user-centered design. UCD isn't about any particular technique, it's about designing the system from an intimate understanding of how the user works. Ron's describing a low-overhead way to do that involving lots of back-and-forth conversations and rapid iterations.
                             
                                Hugh
                             

                          • Dave Cronin
                            In my experience, true invention is the spark that leaps across the gap which deductive/analytical thinking cannot. So in this way, there is no process to
                            Message 13 of 28 , Sep 7, 2004
                            • 0 Attachment
                              In my experience, true invention is the spark that leaps across the gap
                              which deductive/analytical thinking cannot. So in this way, there is no
                              process to achieve invention.

                              There are, however, many effective techniques for supporting the
                              creative process by keeping it somewhat targeted, predictable and by
                              tracking a solution's justification, fitness and ramifications.

                              Supporting creativity with strong process and technique is critical if
                              you consider yourself to be a professional at being inventive. The
                              alternative is almost guaranteed churn and disorder. Which is (while
                              possibly romantic to the "artist") not at all effective in the mostly
                              rationalist world of design.



                              > -----Original Message-----
                              > From: Ron Jeffries [mailto:ronjeffries@...]
                              > Subject: Re: [agile-usability] Re: Could UI Engineering have
                              > lead to Wiki?
                              >
                              > On Wednesday, September 1, 2004, at 5:50:28 PM, Jeff Patton wrote:
                              > > I'd be curious how you'd go about inventing something as
                              > appropriate
                              > > as a wiki? What steps would you go through to discover what a best
                              > > solution might be?
                              >
                              > As far as I know, there are no "steps" for invention. I would
                              > work intimately with people who had the problem, talking,
                              > doing paper prototypes, and showing them running tested
                              > software throughout. I'd try not to lock in technically or
                              > otherwise, on anything.
                              >
                              > I'm not sure it would lead to a "best" solution, nor that a
                              > "best" solution is possible, or even well-defined. I'm sure
                              > it would lead to something that met the needs in cost and
                              > function as well as the assembled multitudes were able to imagine.
                              >
                            • Chris Pehura
                              Here s an innovation process. Refer to www.triz-journal.com ... From: Dave Cronin [mailto:dave@cooper.com] Sent: Tuesday, September 07, 2004 11:15 AM To:
                              Message 14 of 28 , Sep 7, 2004
                              • 0 Attachment
                                Here's an innovation process. Refer to www.triz-journal.com
                                -----Original Message-----
                                From: Dave Cronin [mailto:dave@...]
                                Sent: Tuesday, September 07, 2004 11:15 AM
                                To: agile-usability@yahoogroups.com
                                Subject: RE: [agile-usability] Re: Could UI Engineering have lead to Wiki?

                                In my experience, true invention is the spark that leaps across the gap
                                which deductive/analytical thinking cannot. So in this way, there is no
                                process to achieve invention.

                                There are, however, many effective techniques for supporting the
                                creative process by keeping it somewhat targeted, predictable and by
                                tracking a solution's justification, fitness and ramifications.

                                Supporting creativity with strong process and technique is critical if
                                you consider yourself to be a professional at being inventive. The
                                alternative is almost guaranteed churn and disorder. Which is (while
                                possibly romantic to the "artist") not at all effective in the mostly
                                rationalist world of design.



                                > -----Original Message-----
                                > From: Ron Jeffries [mailto:ronjeffries@...]
                                > Subject: Re: [agile-usability] Re: Could UI Engineering have
                                > lead to Wiki?
                                >
                                > On Wednesday, September 1, 2004, at 5:50:28 PM, Jeff Patton wrote:
                                > > I'd be curious how you'd go about inventing something as
                                > appropriate
                                > > as a wiki?  What steps would you go through to discover what a best
                                > > solution might be?
                                >
                                > As far as I know, there are no "steps" for invention. I would
                                > work intimately with people who had the problem, talking,
                                > doing paper prototypes, and showing them running tested
                                > software throughout. I'd try not to lock in technically or
                                > otherwise, on anything.
                                >
                                > I'm not sure it would lead to a "best" solution, nor that a
                                > "best" solution is possible, or even well-defined. I'm sure
                                > it would lead to something that met the needs in cost and
                                > function as well as the assembled multitudes were able to imagine.
                                >


                              Your message has been successfully submitted and would be delivered to recipients shortly.