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

1159Re: [agile-usability] zooming, porpoising, and goal level

Expand Messages
  • Kay Burnett
    May 3 7:32 AM
    • 0 Attachment
      Hi--
      your title line caught my eye as I try desperately to cope with weeks of unread messages.
       
      I know the phenomena of which you speak -- I call it deconstructing & reconstructing -- and its like breathing -- once you've done one you follow it with the other, and so on, and so on...until you have something you like.
       
      I'm vasillating on whether it is a method or just a way of practicing a method of analysis and synthesis. Basically, in analysis you break things down into their granular parts and look at the parts and in synthesis you build things back adding, tweaking, removing parts and assessing the thing being built.
       
      I hear the germs of this kind of behavior in porpoising and zooming...
       
      Kay Burnett
      Information Architect

      Jeff Patton <jpatton@...> wrote:
      So, I'd wondered in an earlier thread if designers mostly work top down or
      bottom up, and I think my answer was "yes."  That is to say, both are
      important, but at different times for different reasons. 

      This idea of goal level, or abstraction level, and the comparison of goals
      at a high level to the smaller goals at another level seems pretty critical
      to what we're doing.  The idea that upper level goals are validated against
      real world observation of the activities people are doing and the context
      they do them also seems critical. 

      Anita used the term zooming.  I grabbed at the term porpoising - sorta to
      suggest that that like a porpoise, I spend more time below the surface, but
      keep jumping up to look around, but always land back in the water.  Given
      that looking up and down across goal/abstraction level is so important, I'm
      curious if anyone knows if an author has called attention to, and named this
      activity?  Or, is this all pretty obvious, and terms like zooming are good
      enough to explain to others what we're doing?

      Going back full circle, I thought I had detected that written down
      methodologies /do/ favor one method of thinking over another... but I'm
      hearing from practitioners otherwise.  I'm not very well read, but in the
      few books I have read, and the few people I have worked with, I don't recall
      anyone drawing attention to this concept as critical.  Is it too obvious, or
      did I overlook the message when I heard it?

      I'd love to hear feedback and comments on this.

      Thanks,

      -Jeff 

      -----------
      Jeff Patton
      ThoughtWorks
      www.abstractics.com/papers
      Agile usability discussion group:
      http://groups.yahoo.com/group/agile-usability/

      XP 2005 (Sheffield, UK) Agile User Experience Tutorial:
      http://www.xp2005.org

      UPA (Montreal, Quebec) Agile-UCD Tutorial:
      http://www.upassoc.org/conferences_and_events/upa_conference/2005/program/ac
      tivity.php?id=179
      Agile-Usability Workshop:
      http://www.upassoc.org/conferences_and_events/upa_conference/2005/program/ac
      tivity.php?id=156

      Agile 2005 (Denver, CO) Agile User Experience Tutorial, Agile Code Metrics
      Tutorial: http://www.agile2005.org/

      "There is nothing that saps one's confidence as the knowing how to do a
      thing."
      --Mark Twain





      Yahoo! Groups Links

      __________________________________________________
      Do You Yahoo!?
      Tired of spam? Yahoo! Mail has the best spam protection around
      http://mail.yahoo.com

    • Show all 23 messages in this topic