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

Re: When does presentation layer come in?

Expand Messages
  • Nick Gassman
    ... Agreed. And Robert talked about close collaboration, and that will also contribute. I m just starting with this stuff, and trying to figure out how it
    Message 1 of 283 , Aug 1, 2008
      --- "aacockburn" wrote:
      > Robert Biddle wrote:
      > >
      > > It occurs to me there is no one right answer to this, because
      > > good products can start from anywhere.
      > Thanks, Robert, you are of course correct.

      Agreed. And Robert talked about close collaboration, and that will
      also contribute.

      I'm just starting with this stuff, and trying to figure out how it
      should work for us. I've learned a lot in the last few weeks, and
      have a lot further to go (and I have to say, it's quite fun doing

      I do have a clear sense from what I've read and heard and discussed
      with people, that there's a tendency in some Agile approaches to push
      back on the interaction design. For me, it's a question of working
      out, for any given project, what's the best approach. When does
      having a rough screen idea help to move things forward, and when
      would it hinder? Given that you have to get the interaction design as
      right in the final delivery as you do the code (and given that you
      might need to change either at any point).

      All I'm talking about here is scrawling some layouts and ideas on a

      > To get back to the point I was trying to raise ...
      > > what shocked me, as many programs as I've written in my life,
      > > but this time being the sponsor and not the programmer, is how
      > > upsetting it is to me to have to work with a marred visual
      > > design for a time, even when I know it will get fixed
      > > "eventually".
      > I am presenting here, not a problem to be solved, but a reaction
      > for consideration from a real sponsor and focal user on a
      > real project.
      > It is of course possible to respond with, "You shouldn't feel
      > that way", or "You feel that way because you're doing it all
      > wrong", but that doesn't address the matter at hand - I do feel

      Alistair, it is of interest, and there is indeed no point saying that
      you shouldn't feel like that. What it shouldn't do is affect your
      approach to what needs to be done. Is your reaction to the marred
      visual design different from whatever the coding equivalent would be
      (if there is one)?

      I suspect that if I moved from a visual design bias to a coding bias,
      I might feel the same way about the code - but when I'm working with
      designs I always expect them to change, and I do indeed observe your
      reaction in others. From their point of view they refer to it as me
      changing my mind, or unable to make my mind up. I would expect and
      hope that your upset would decrease over time, as you become more
      accustomed to the role. It will be interesting as well to see if it
      affects your views on the timing in which to introduce the
      interaction design into an Agile project.
    • George Dinwiddie
      ... William, why do you say apparently not? Is not the text appearing on the screen part of working software no matter whether the text is compiled into
      Message 283 of 283 , Aug 21, 2008
        William Pietri wrote:
        > The team decides the highest priority is to fix that. So the whole team
        > spends the week rummaging through the content management system,
        > rewriting copy, changing labels, clarifying wording, and so on. Not a
        > line of code is written; no software is produced.
        > Upon release, key metrics improve significantly. Users are happier,
        > signups are more frequent, retention goes up. Millions of extra dollars
        > will be made over the next year. By external measures, it is the most
        > useful week of work all year.
        > Would the business call that a week with progress? Yes. Would the team
        > call that progress? Yes. Would that Agile Manifesto? Apparently not.

        William, why do you say "apparently not?"

        Is not the text appearing on the screen part of "working software" no
        matter whether the text is compiled into the object code or read out of
        some data store?

        Is this not an example of "satisfy[ing] the customer through early and
        continuous delivery of valuable software?"

        Is this not a case of "deliver[ing] working software frequently?"

        Is this not an example of "business people and developers [working]
        together daily?"

        Is this not an excellent example of a "team reflect[ing] on how to
        become more effective, then tun[ing] and adjust[ing] its behavior

        Your other example, where "eventually, after many months of work, they
        decide they can release," seems to violate several principles,
        particularly, "Agile processes promote sustainable development. The
        sponsors, developers, and users should be able to maintain a constant
        pace indefinitely."

        - George

        * George Dinwiddie * http://blog.gdinwiddie.com
        Software Development http://www.idiacomputing.com
        Consultant and Coach http://www.agilemaryland.org
      Your message has been successfully submitted and would be delivered to recipients shortly.