507Re: Could UI Engineering have lead to Wiki?
- Sep 1, 2004--- In email@example.com, Ron Jeffries
> 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 timejust to
> describe, and very much longer to execute, and that in the time itwould
> take, one very likely has the choice between having an idea at theend of
> the time, or an idea plus a program that implements the idea. Ibelieve 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 asdreaming,
> 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
> recommend people sit around musing about a way to enter stuff intoa web
> site before getting down to building it? A few days? A week? Amonth? 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 workI'd try
> intimately with people who had the problem, talking, doing paper
> prototypes, and showing them running tested software throughout.
> not to lock in technically or otherwise, on anything.solution
> 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 tosomething that
> met the needs in cost and function as well as the assembledmultitudes were
> able to imagine.somewhere
> It would be my guess, by the way, that explaining a wiki is
> between impossible and pointless. Everyone I've ever explained itto, or
> heard of having it explained to them, didn't get it. Everyone whotries
> it, gets it.I think there _are_ steps - sort of. Not N steps that when followed
> What would you do in a situation such as you described?
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 doI think you're like most "level 3" people - I think that's what
> you imagine it to be from what I'd do?
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
> It is not the strongest of the species that survive, not the most
> but the one most responsive to change. -- Charles Darw
- << Previous post in topic Next post in topic >>