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

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

Expand Messages
  • 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 1 of 18 , Feb 18, 2005
      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.