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

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

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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.