Re: XP and Big Interaction Design UpFront
- Petteri_Hiisil� wrote:
> Phlip wrote:I said, "I propose (entirely to make everyone need to
> > Did I say that?
> I'm afraid you did :)
> I don't know if you really meant that, though... But
> you left us with an
> impression that you did :)
hire more programmers like me) that programs should
version with skins, so each user population gets the
skin they like."
I did not say each skin had the same click path over
trivially different art and layout. I am aware some
pluggable skins provide that.
So, maybe if we had a boring data entry form, and we
configured it to support two locales, would that be a
No? Okay, how about calling the locale configuration
thing a "skin". Is something wrong with that?
Or how about a Wiki that supports both a stand-alone
server and a CGI server. The user can perceive the
difference. Are they "skins"?
Or suppose my onsite usability expert requested a user
interface surface with pluggable art and layout
modules. Would writing them test-first, and
constraining them with acceptance tests, be
(BTW the boring data entry form's two skins are
English and Sanskrit. Wild, huh?;)
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
- On Wed, 2004-09-01 at 11:57, Dave Cronin wrote:
> Most of the bad effects that we've seen from running research and theInteresting. My experience so far has been that if things like
> initial design phase (what we call the "Interaction Framework")
> alongside development have to do with premature technical decisions
> about things like platform, architecture, and data model. While I
> haven't worked with many true blue XP shops, my experience is that these
> things are difficult and expensive to modify or "refactor".
architecture and data model are built in an agile, incremental fashion
and the most important things are built first, refactoring later is much
cheaper than waiting for clarity. It takes a skilled team, though;
novices may be unable to defer questions like, "Should we use a
database?" My current team has managed to avoid answering that for eight
I'm not quite sure what you mean by platform; that's a broad term. If a
client is still unsure whether they want a web site or a custom wireless
handheld device, I'd agree it's probably too early to start the
front-end development. Or more generally, if it's too early in the
project to pick even two of the developers you'd need, it's too early to
On the other hand, although I've participated in a lot of half-baked
product discussions, I've never seen one where somebody was ready to put
money down and where I couldn't pull out at least a week of work that
was relatively stable. And after that, it's always my experience that
people can think of features far faster than I can build them.
On one project, for example, the first three stories were
* guest views home page
* user logs in
* user logs out
With all the shenanigans involved in setting up a new project, starting
development, and getting something onto production servers the first
time, this took two weeks. At which point enough research and design had
happened that there were several more cards ready.
Of course, all this is just my experience; it's a big world out there.
> And as far as those conversations between Cooper and Beck, I thinkAgreed!
> they were both doing their best to demonstrate the gulf between the
> viewpoints, which I suppose was appropriate back then when a lot of
> the industry was just coming to terms with both of these approaches. I
> think we've gotten to a point where it makes sense to look for some
> cross-pollination and middle ground.
In fact, since you're in the SF area, you should come by for lunch and
chat with the team, including the product designer. XP is hard to
imagine unless you've seen it working. Contact me off-list to arrange