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

Re: [XP] Re: When does interface design occur?

Expand Messages
  • Phlip
    ... Everyone else always does the code inside the GUI wrong. (-; ... It s the SOP question for Lean Software Development. It s coaxiomatic with our YAGNI and
    Message 1 of 73 , Oct 6, 2007
      Brian Victor wrote:

      >> As the best GUI guy on the team, I would leave them at it and go back to
      >> work. Being the GUI guy does _not_ mean design.
      > This is interesting. What does being the GUI guy mean to you?

      Everyone else always does the code inside the GUI wrong.


      >>> Is the iteration planning meeting the appropriate place for discussing
      >>> design issues?

      >> Are they making irreversibly expensive decisions with the least amount of
      >> data?
      > Excellent question.

      It's the SOP question for Lean Software Development. It's coaxiomatic with
      our "YAGNI" and "business value order" ideals.

      > Sometimes the decision seems expensive within the
      > context of an iteration because the card has a relatively high estimate.
      > However, it gives me a sense of proportion to consider that the story is
      > a mere subset of a one-week iteration. So the answer to your question
      > is no.

      Right - you are within your 1-week horizon. Don't make hard decisions, now,
      about an iteration you predict may happen in a month.

      >> Next, is the GUI very easy to change?
      > Not as easy as I wish it were, but we've done fairly significant changes
      > within the scope of one iteration.

      This is a major irony here. In the days of VB6 and lite HTML, the GUI was
      absurdly easy to change. You just repainted it, rewired what you did, and
      kept going. The inner code, without tests, was super-hard.

      Nowadays, if we TDD the innards, they are super-easy to change. And even if
      we try to TDD the GUI, it's still as hard as refactoring a database!

    • Charlie Poole
      Hi Rick, Yes, in fact so do I. When I said I try to think about alternate UIs, I was thinking of Fit as one of them. I treat the acceptance test implementation
      Message 73 of 73 , Oct 16, 2007
        Hi Rick,

        Yes, in fact so do I. When I said I try to think about alternate
        UIs, I was thinking of Fit as one of them. I treat the acceptance
        test implementation as a sort of alterate UI for the application.

        I just left Fit out so as not to muddy the waters. :-)


        > -----Original Message-----
        > From: extremeprogramming@yahoogroups.com
        > [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Rick Mugridge
        > Sent: Tuesday, October 16, 2007 2:35 AM
        > To: extremeprogramming@yahoogroups.com
        > Subject: Re: [XP] Re: When does interface design occur?
        > Hi Charlie,
        > I do something similar to what you're describing, but instead
        > express them as storytests. Then they can be used to drive
        > development of the domain layer as well as understand and
        > discuss domain issues. I find this works well for more
        > complex domains, which is where much of my work is. I
        > attended Jeff Patton's session on usability at XP2007 and saw
        > examples where the domain is simple and well understood and I
        > can see that it makes sense to start with the UI. But in the
        > domains I work in, there is usally an evolution of the
        > ubiquitous language. And often changes arise from questions
        > from the programmers when they're noticing interesting
        > redundancy that has not been seen from the business perspective.
        > I use DomainFixture (in FitLibrary) to express the
        > storytests. This uses nested tables and uses some similar
        > conventions to a UI (such as property-value pairs). It's a
        > picture of the domain objects and their associations and the
        > actions that are carried out on them.
        > But some people are happier once they see a real UI. I prefer
        > to leave the real UI (and persistence) until the domain for
        > that part settles.
        > I've not found that the UI changes things especially at the
        > domain level, beyond where it spurs new ideas about what the
        > system should do.
        > Cheers, Rick
        > Charlie Poole wrote:
        > >
        > > Hi Adrian,
        > >
        > > > For me the development of the UI helps define the metaphors and
        > > > domain language that you develop to solve the customers problem.
        > > > Leaving it until the end can often mean you end up with
        > code that's
        > > > very hard to adapt to produce the best possible UI for the domain.
        > >
        > > I've been reading this thread in a bit of puzzlement. Your comment
        > > helped me to focus in on what has been bothering me, so
        > I'll chime in
        > > here, without any intent of disagreeing with you.
        > >
        > > I often work with customers in terms of a hypothetical UI when I'm
        > > trying to define what the underlying application needs to do.
        > > This might look like UI Design to someone who watched us,
        > since we do
        > > sketch various gui-like interfaces, but I don't think of it
        > that way.
        > > My goal is to figure out what the customer wants to do, not
        > produce a
        > > UI Design.
        > >
        > > Ultimately, there will be a UI, of course, and the work we did in
        > > surfacing the desired interaction with the application will
        > help a lot
        > > in designing that UI, but what we are doing initially is
        > (usually) not
        > > creating a UI - we are creating a visual language for talking about
        > > the application.
        > >
        > > I should add that I don't work this way with /all/ customers. Many
        > > folks are more comfortable with this approach, while others seem to
        > > give me more information when I use different terms. I
        > disagree with
        > > those who say that users can't think in any terms but the user
        > > interface - in fact, it seems like a disrespectful statement.
        > >
        > > The discussion I have been reading seems to have varied between the
        > > two separate (to my mind) activities of talking about the
        > UI as a way
        > > of understanding customer needs and actually designing a
        > UI. I think
        > > that's what was perplexing me.
        > >
        > > Charlie
        > >
        > >
        > [Non-text portions of this message have been removed]
        > To Post a message, send it to: extremeprogramming@...
        > To Unsubscribe, send a blank message to:
        > extremeprogramming-unsubscribe@...
        > ad-free courtesy of objectmentor.com
        > Yahoo! Groups Links
      Your message has been successfully submitted and would be delivered to recipients shortly.