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

507Re: Could UI Engineering have lead to Wiki?

Expand Messages
  • Jeff Patton
    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/

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

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


      > Ron Jeffries
      > www.XProgramming.com
      > It is not the strongest of the species that survive, not the most
      > but the one most responsive to change. -- Charles Darw
    • Show all 28 messages in this topic