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

Re: When does presentation layer come in?

Expand Messages
  • aacockburn
    ... Not to ignore the rest of your post, but this particular question has been interesting to me lately. I grew up in the Smalltalk MVC era, 1987 - 1994,
    Message 1 of 283 , Jul 29, 2008
    • 0 Attachment
      --- In agile-usability@yahoogroups.com, "Charles B. Kreitzberg"
      <charlie@...> wrote:
      >
      > You have touched on, what I think is a really important issue.
      >
      >
      >
      > It's been my experience that many developers have been
      > taught that the presentation layer comes last. As a Ux
      > designer I feel that is a serious error. I once lost a battle
      > with a client when I argued that we should design the UI first,
      > at least as a concept. As a result, the project we delayed
      > an entire year when the architecture proved inadequate to meet
      > the UI needs.

      Not to ignore the rest of your post, but this particular question
      has been interesting to me lately.

      I "grew up" in the Smalltalk MVC era, 1987 - 1994, when we would
      design via API to the app, running functions from the workspace
      window, then fit a UI to request/deliver that API to the viewer.

      There was a parallel, UI-prototype driven school operating in
      the early 1990s.

      Since 2000, particularly with the web, focus shifted to UI
      mockups, lo-fi, etc., and nowadays almost no client wants to
      operate from an API, they all want to operate from screen shots.

      However, I'm currently sponsor of my new web site design, and
      we deliberately went the old MVC route. This allowed us to
      move really rapidly in building up functionality, not caring
      how the stuff showed up on the screen, but getting the behaviors
      and information the way we wanted.

      Finally we drafted and put on the presentation layer, and I'm
      working in the new models, still fixing some function questions.
      What I'm finding is that even I, though I khow they are drafts and
      subject to improvement, am constantly frustrated by absolutely
      tiny things in the presentation that I don't like, and I have to
      keep biting my fingernails not to send off bug reports on
      small visual errors. I /know/ we'll get around to changing them,
      but they drive me mad seeing them all the time.

      If I were to do it again, I'd delay the presentation layer even
      longer, until we got the functionality really working properly,
      and could put all our effort on getting the visuals nice. Then
      I'd be right in shipping off notices on things being n pixels off.

      Alistair
    • 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
      • 0 Attachment
        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
        accordingly?"

        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.