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

RE: [agile-usability] Re: GUI component magnets

Expand Messages
  • Rob Keefer
    Jade, Your question is great, and as I said I m still learning, so my experience may or may not be helpful. When I say custom control I m using it in the
    Message 1 of 18 , Feb 18, 2005
    • 0 Attachment
      Jade,

      Your question is great, and as I said I'm still
      learning, so my experience may or may not be helpful.

      When I say "custom control" I'm using it in the most
      generic of terms. If I have a series of text boxes on
      a page that all gather information for the same type
      of data I may derive a couple of controls from
      Textbox.

      For example, if I have a page with two columns of text
      boxes - on the left is player name and on the right is
      the number of points that player scored in a football
      game.

      In C# I may do something like this:
      public class PlayerInput :
      System.Windows.Forms.TextBox
      {
      }

      public class ScoreInput : System.Windows.Forms.TextBox
      {
      }

      Then when the UI requirement for player entry changes
      to be a ComboBox, all I have to do is change the base
      class:
      public class PlayerInput :
      System.Windows.Forms.ComboBox
      {
      }

      One change in one place instead of a bunch on a form.
      Same idea again when a "valid score range" requirement
      is placed on the ScoreInput, I can now add:

      public class ScoreInput : System.Windows.Forms.TextBox
      {
      private int getMaxScore(){}
      private int getMinScore(){}
      }

      All the ScoreInput fields are now a little smarter.

      These are kinda lame examples, but I hope you get the
      idea. For places where I only have one input field
      categorization I may go ahead and use the standard
      control, but for groups of input fields where changing
      one thing would affect a bunch of controls I try to
      wrap them up.

      I may use a class hiearchy too, where I have a
      TextBoxBase class that simply derives from TextBox,
      and all of my TextBoxes are instantiations of some
      form of TextBoxBase. Then when a requirement comes in
      saying, "No field in the system will be longer than
      256 characters", I can go to that base class, add the
      appropriate parms, and go on. The reason the developer
      in me is frustrated by requirements changing like this
      is not because it is difficult, but because the way it
      is often implemented causes busy work.

      This is a long answer, does it answer your question?

      - Rob




      --- Jade Ohlhauser <jade@...> wrote:

      > Hi Rob. Why do you feel custom controls are "much
      > easier" to refactor?
      > When I think of custom controls I think of something
      > built with a
      > specific purpose, less generic (and usually less
      > documented) than
      > included functionality.
      >
      > I'm not disagreeing, I'm just curious. This is a
      > complex subject where
      > semantics and perspective leave a lot of room for
      > different methods :)
      >
      > Jade Ohlhauser
      > Product Manager
      > RPM Software
      > www.rpmsoftware.com <http://www.rpmsoftware.com/>
      > 403-265-6727
      >
      >
      > ________________________________
      >
      > From: Rob Keefer [mailto:rbkeefer@...]
      > Sent: Friday, February 18, 2005 6:35 AM
      > To: agile-usability@yahoogroups.com
      > Subject: Re: [agile-usability] Re: GUI component
      > magnets
      >
      >
      > I too end up wearing both hats, and am headed toward
      > schizophrenia. My developer persona often gets very
      > upset with my designer persona. This happens when a
      > change in the UI shows glaring holes in my system's
      > architecture. So really the developer in me should
      > be
      > mad at the developer, but the anger gets directed at
      > the designer.
      >
      > Some lessons I am learning through this are:
      > 1. A changing UI should flow right into the
      > iterations
      > with the rest of the system.
      > 2. The reason developers get upset when the UI
      > changes
      > may be because the UI is too tightly coupled to the
      > rest of the system.
      > 3. In desktop applications, I try to use custom
      > controls most of the time. They may be a simple
      > wrapper around the standard control, but when it
      > comes
      > time to refactor it is much easier with custom
      > controls.
      > 4. The UI layer should be as thin as possible. Most
      > events should delegate to a layer lower in the
      > architecture. This helps in a number of ways, most
      > importantly Unit Tests. I can write (J/N)Unit tests
      > for non-UI code, and these tests tend to be easier
      > to
      > write than HTMLUnit tests or running through scripts
      > by hand.
      >
      > I am still learning, but I think when someone really
      > figures out how agility and usability play together
      > well, the architecture of the system will play a
      > part
      > in the solution.
      >
      > - Rob
      >
      >
      >
      > --- Jeff Patton <jpatton@...> wrote:
      >
      > >
      > > --- In agile-usability@yahoogroups.com, "Jamie
      > > Nettles" <jamien@i...>
      > > wrote:
      > > > I am just now finishing up Alan Cooper's "The
      > > Inmates Are Running
      > > the Asylum" and while I have immense respect for
      > his
      > > opinions I am
      > > having trouble reconciling his approach with
      > > agility. Cooper
      > > recommends working out the interface ahead of time
      > > before coding
      > > starts. Agility suggests we design as we code.
      > In
      > > addition, Cooper
      > > sees a clear distinction between designers and
      > > programmers. Agility
      > > tends to disfavor rigid roles. Can anyone help me
      > > reconcile these
      > > apparently conflicting approaches?
      > > >
      > >
      > > Alan's just wrong. ;-)
      > >
      > > Actually it's not that simple. He's sorta right
      > > too. I think it's
      > > in Fowler's Refactoring that he describes
      > > programmers wearing
      > > different hats: a programming hat and a
      > refactoring
      > > hat. You switch
      > > hats frequently while programming - you just need
      > to
      > > be clear which
      > > hat you're wearing.
      > >
      > > I'm a programmer. I'm a designer. And, by the
      > way,
      > > Alan is a
      > > programmer - and a designer. The world has quite
      > a
      > > bit of software
      > > to thank Alan for before he gained his reputation
      > as
      > > a designer.
      > >
      > > A couple day's ago I was leading a facilitated
      > > design meeting. I
      > > like these meeting to be multi-disciplinary -
      > which
      > > means I like
      > > programmers, designers, testers, users - lots of
      > > people present.
      > > There weren't any programmers present on that day,
      > > then one of my
      > > stakeholders said "you're a programmer." Oh yeah,
      > I
      > > thought to
      > > myself. But after a midday break I was thinking
      > to
      > > myself of a good
      > > bit of insight we'd have gotten in an earlier
      > > discussion if we'd had
      > > a programmer in the room. I got the insight at
      > the
      > > break when I put
      > > my programmer hat back on. While being a
      > designer,
      > > my programmer
      > > eyes and ears were shut down - or at least
      > muffled.
      > > From here on in
      > > I'll insist on having programmers present during
      > > collaborative design
      > > sessions - because I'm not one when I'm a
      > designer.
      > >
      > > So, Alan is right. Programmers can't be
      > designers.
      > > But, they can
      > > change hats back and forth pretty quickly.
      > >
      > > And, on the do it all up front thing: it's simply
      > > not necessary any
      > > more. However, before getting to far in it is
      > > beneficial to get a
      > > clear vision of your project goals, the users the
      > > software will
      > > serve, their goals and context of use. The things
      > > they do to reach
      > > those goals [user tasks] start to be your first
      > user
      > > stories.
      > > Affinity diagrams of those user tasks give you a
      > > good idea of how
      > > they should hang together in the user interface...
      > > the structure of
      > > your application. Thinking about all that stuff
      > to
      > > start with helps
      > > the first bit of code you right be in the right
      > > direction. It's
      > > not /all/ the design up front - just enough to
      > > validate the detail
      > > design you do as you iteratively design and
      > develop.
      > >
      > > Big bang design and delivery is also financially
      > > risky. If you
      > > really must design it /all/ up front, tell your
      > > design team instead
      > > of 1 product deliverable in a year, you'd like
      > them
      > > to design 2
      > > products, one the upgraded version of the first,
      > > each deliverable in
      > > 6 months. Fully design the first then start
      > > building it. While
      > > building the first, start your design team
      > building
      > > the second.
      > > Rinse and repeat... you get the idea.
      > >
      > > Thanks for your post. I love the opportunity to
      > > remind everyone that
      > > Alan Cooper is actually a programmer... ;-)
      > >
      > > -Jeff
      > >
      > >
      > >
      > >
      > >
      >
      >
      >
      > ________________________________
      >
      > Yahoo! Groups Links
      >
      >
      > * To visit your group on the web, go to:
      > http://groups.yahoo.com/group/agile-usability/
      >
      > * To unsubscribe from this group, send an email to:
      > agile-usability-unsubscribe@yahoogroups.com
      >
      <mailto:agile-usability-unsubscribe@yahoogroups.com?subject=Unsubscribe>
      >
      >
      > * Your use of Yahoo! Groups is subject to the Yahoo!
      > Terms of
      > Service <http://docs.yahoo.com/info/terms/> .
      >
      >
      >
    • Jade Ohlhauser
      I see what you meant. We do the same thing here, like having pages inherit our BasePage class instead of System.Web.UI.Page. Sure BasePage is really just
      Message 2 of 18 , Feb 18, 2005
      • 0 Attachment
        I see what you meant. We do the same thing here, like having pages inherit our BasePage class instead of System.Web.UI.Page. Sure BasePage is really just System.Web.UI.Page, but we can add functionality to BasePage to add functionality (or replace Microsoft's built-in functionality) for all the pages. We also use this for all our interface styling, using CSS classes instead of directly applying formatting to an element.
         
        Jade Ohlhauser
        Product Manager
        RPM Software                          
        www.rpmsoftware.com 403-265-6727
         


        From: Rob Keefer [mailto:rbkeefer@...]
        Sent: Friday, February 18, 2005 10:45 AM
        To: agile-usability@yahoogroups.com
        Subject: RE: [agile-usability] Re: GUI component magnets

        Jade,

        Your question is great, and as I said I'm still
        learning, so my experience may or may not be helpful.

        When I say "custom control" I'm using it in the most
        generic of terms. If I have a series of text boxes on
        a page that all gather information for the same type
        of data I may derive a couple of controls from
        Textbox.

        For example, if I have a page with two columns of text
        boxes - on the left is player name and on the right is
        the number of points that player scored in a football
        game.

        In C# I may do something like this:
        public class PlayerInput :
        System.Windows.Forms.TextBox
        {
        }

        public class ScoreInput : System.Windows.Forms.TextBox
        {
        }

        Then when the UI requirement for player entry changes
        to be a ComboBox, all I have to do is change the base
        class:
        public class PlayerInput :
        System.Windows.Forms.ComboBox
        {
        }

        One change in one place instead of a bunch on a form.
        Same idea again when a "valid score range" requirement
        is placed on the ScoreInput, I can now add:

        public class ScoreInput : System.Windows.Forms.TextBox
        {
          private int getMaxScore(){}
          private int getMinScore(){}
        }

        All the ScoreInput fields are now a little smarter.

        These are kinda lame examples, but I hope you get the
        idea. For places where I only have one input field
        categorization I may go ahead and use the standard
        control, but for groups of input fields where changing
        one thing would affect a bunch of controls I try to
        wrap them up.

        I may use a class hiearchy too, where I have a
        TextBoxBase class that simply derives from TextBox,
        and all of my TextBoxes are instantiations of some
        form of TextBoxBase. Then when a requirement comes in
        saying, "No field in the system will be longer than
        256 characters", I can go to that base class, add the
        appropriate parms, and go on. The reason the developer
        in me is frustrated by requirements changing like this
        is not because it is difficult, but because the way it
        is often implemented causes busy work.

        This is a long answer, does it answer your question?

        - Rob




        --- Jade Ohlhauser <jade@...> wrote:

        > Hi Rob. Why do you
        feel custom controls are "much
        > easier" to refactor?
        > When I think
        of custom controls I think of something
        > built with a
        > specific
        purpose, less generic (and usually less
        > documented) than
        >
        included functionality.

        > I'm not disagreeing, I'm just
        curious. This is a
        > complex subject where
        > semantics and
        perspective leave a lot of room for
        > different methods :)

        > Jade Ohlhauser
        > Product Manager
        > RPM
        Software                         
        > www.rpmsoftware.com <
        href="http://www.rpmsoftware.com/">http://www.rpmsoftware.com/>
        >
        403-265-6727

        >
        >
        ________________________________
        >
        > From: Rob Keefer
        [mailto:rbkeefer@...]
        > Sent: Friday, February 18, 2005 6:35
        AM
        > To: agile-usability@yahoogroups.com
        > Subject: Re:
        [agile-usability] Re: GUI component
        > magnets
        >
        >
        > I
        too end up wearing both hats, and am headed toward
        > schizophrenia. My
        developer persona often gets very
        > upset with my designer persona. This
        happens when a
        > change in the UI shows glaring holes in my
        system's
        > architecture. So really the developer in me should
        >
        be
        > mad at the developer, but the anger gets directed at
        > the
        designer.
        >
        > Some lessons I am learning through this are:
        >
        1. A changing UI should flow right into the
        > iterations
        > with the
        rest of the system.
        > 2. The reason developers get upset when the
        UI
        > changes
        > may be because the UI is too tightly coupled to
        the
        > rest of the system.
        > 3. In desktop applications, I try to use
        custom
        > controls most of the time. They may be a simple
        > wrapper
        around the standard control, but when it
        > comes
        > time to refactor
        it is much easier with custom
        > controls.
        > 4. The UI layer should
        be as thin as possible. Most
        > events should delegate to a layer lower in
        the
        > architecture. This helps in a number of ways, most
        >
        importantly Unit Tests. I can write (J/N)Unit tests
        > for non-UI code, and
        these tests tend to be easier
        > to
        > write than HTMLUnit tests or
        running through scripts
        > by hand.
        >
        > I am still learning,
        but I think when someone really
        > figures out how agility and usability
        play together
        > well, the architecture of the system will play a
        >
        part
        > in the solution.
        >
        > - Rob
        >
        >
        >
        > --- Jeff Patton <jpatton@...> wrote:
        >
        > >
        > > --- In agile-usability@yahoogroups.com, "Jamie
        > >
        Nettles" <jamien@i...>
        > > wrote:
        > > > I am just
        now finishing up Alan Cooper's "The
        > > Inmates Are Running
        > > the Asylum" and while I have immense respect for
        > his
        > >
        opinions I am
        > > having trouble reconciling his approach with
        > > agility.  Cooper
        > > recommends working out the interface
        ahead of time
        > > before coding
        > > starts.  Agility
        suggests we design as we code.
        > In
        > > addition, Cooper
        > > sees a clear distinction between designers and
        > >
        programmers.  Agility
        > > tends to disfavor rigid roles. 
        Can anyone help me
        > > reconcile these
        > > apparently
        conflicting approaches?
        > > >
        > >
        > > Alan's
        just wrong.  ;-)
        > >
        > > Actually it's not that
        simple.  He's sorta right
        > > too.  I think it's
        > > in Fowler's Refactoring that he describes
        > > programmers wearing
        > > different hats: a  programming hat and a
        >
        refactoring
        > > hat.  You switch
        > > hats frequently
        while programming - you just need
        > to
        > > be clear which
        > > hat you're wearing.
        > >
        > > I'm a
        programmer.  I'm a designer.  And, by the
        > way,
        > >
        Alan is a
        > > programmer - and a designer.  The world has
        quite
        > a
        > > bit of software
        > > to thank Alan for
        before he gained his reputation
        > as
        > > a designer.
        > >
        > > A couple day's ago I was leading a facilitated
        > > design
        meeting.  I
        > > like these meeting to be multi-disciplinary
        -
        > which
        > > means I like
        > > programmers, designers,
        testers, users - lots of
        > > people present. 
        > > There
        weren't any programmers present on that day,
        > > then one of my
        > > stakeholders said "you're a programmer."  Oh yeah,
        >
        I
        > > thought to
        > > myself.  But after a midday break I
        was thinking
        > to
        > > myself of a good
        > > bit of
        insight we'd have gotten in an earlier
        > > discussion if we'd had
        > > a programmer in the room.  I got the insight at
        >
        the
        > > break when I put
        > > my programmer hat back on. 
        While being a
        > designer,
        > > my programmer
        > > eyes
        and ears were shut down - or at least
        > muffled.
        > > From here
        on in
        > > I'll insist on having programmers present during
        > > collaborative design
        > > sessions - because I'm not one when I'm
        a
        > designer.
        > >
        > > So, Alan is right. 
        Programmers can't be
        > designers.
        > > But, they can
        > > change hats back and forth pretty quickly.
        > >
        > > And,
        on the do it all up front thing: it's simply
        > > not necessary any
        > > more.  However, before getting to far in it is
        > >
        beneficial to get a
        > > clear vision of your project goals, the users
        the
        > > software will
        > > serve, their goals and context of
        use.  The things
        > > they do to reach
        > > those goals
        [user tasks] start to be your first
        > user
        > > stories. 
        > > Affinity diagrams of those user tasks give you a
        > > good
        idea of how
        > > they should hang together in the user
        interface...
        > > the structure of
        > > your application. 
        Thinking about all that stuff
        > to
        > > start with helps
        > > the first bit of code you right be in the right
        > >
        direction.  It's
        > > not /all/ the design up front - just enough
        to
        > > validate the detail
        > > design you do as you
        iteratively design and
        > develop.
        > >
        > > Big bang
        design and delivery is also financially
        > > risky.  If you
        > > really must design it /all/ up front, tell your
        > >
        design team instead
        > > of 1 product deliverable in a year, you'd
        like
        > them
        > > to design 2
        > > products, one the
        upgraded version of the first,
        > > each deliverable in
        > > 6
        months.   Fully design the first then start
        > > building
        it.  While
        > > building the first, start your design team
        >
        building
        > > the second. 
        > > Rinse and repeat... you
        get the idea.
        > >
        > > Thanks for your post.  I love the
        opportunity to
        > > remind everyone that
        > > Alan Cooper is
        actually a programmer... ;-)
        > >
        > > -Jeff
        > >
        > >
        > >
        > >
        > >
        >
        >
        >
        > ________________________________
        >
        > Yahoo!
        Groups Links
        >
        >
        > *      To visit
        your group on the web, go to:
        >      
        href="http://groups.yahoo.com/group/agile-usability/">http://groups.yahoo.com/group/agile-usability/
        >
               
        > *     
        To unsubscribe from this group, send an email to:
        >
              agile-usability-unsubscribe@yahoogroups.com
        >
        <mailto:agile-usability-unsubscribe@yahoogroups.com?subject=Unsubscribe>
        >
        >        
        >
        *      Your use of Yahoo! Groups is subject to the Yahoo!
        > Terms of
        > Service <
        href="http://docs.yahoo.com/info/terms/">http://docs.yahoo.com/info/terms/> .
        >
        >
        >

      Your message has been successfully submitted and would be delivered to recipients shortly.