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

GUI component magnets

Expand Messages
  • Rob Keefer
    I recently saw an article or advertisement for a package of GUI components that are magnetic. It was really cool because you could work through GUI flow on a
    Message 1 of 18 , Feb 16, 2005
    • 0 Attachment
      I recently saw an article or advertisement for a package of GUI components that are magnetic. It was really cool because you could work through GUI flow on a whiteboard with the little components - move things around and such. I can't find the reference though.
       
      Does anyone know where I can find something like this?
       
      Thanks.
       
      - Rob
       
    • Dane R. Falkner
      One product I know of is from 6PM. The creator, Ivan Bartolo, is a friend of mine and lives on the Island of Malta. Here is a link:
      Message 2 of 18 , Feb 16, 2005
      • 0 Attachment
        One product I know of is from 6PM. The creator, Ivan Bartolo, is a friend of mine and lives on the Island of Malta. Here is a link: http://www.6pmodel.com/6PMSite/DesktopDefault.aspx?tabid=24. You can probably talk him into a discount. It might even help if you say that I (Dane Falkner) sent you to him.


        ________________________________

        From: Rob Keefer [mailto:rbkeefer@...]
        Sent: Wed 2/16/2005 9:14 AM
        To: agile-usability@yahoogroups.com
        Subject: [agile-usability] GUI component magnets


        I recently saw an article or advertisement for a package of GUI components that are magnetic. It was really cool because you could work through GUI flow on a whiteboard with the little components - move things around and such. I can't find the reference though.

        Does anyone know where I can find something like this?

        Thanks.

        - Rob


        Yahoo! Groups Sponsor
        ADVERTISEMENT

        <http://us.ard.yahoo.com/SIG=1292qlfrf/M=298184.6018725.7038619.3001176/D=groups/S=1705007709:HM/EXP=1108656903/A=2532114/R=2/SIG=12k07h2am/*http://clk.atdmt.com/NFX/go/yhxxxnfx0020000014nfx/direct/01/&time=1108570503359838>


        ________________________________

        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/> .
      • hj
        ... Sounds an interesting product ... but the powerpoint presentation really put me off. I looked at a few slides then switched it off. Random slide
        Message 3 of 18 , Feb 17, 2005
        • 0 Attachment
          > One product I know of is from 6PM.

          Sounds an interesting product ... but the powerpoint presentation really put
          me off. I looked at a few slides then switched it off.

          Random slide transitions slowing down the show and just getting in the
          way.... titles crawling in from all angles...the images in which I am
          interested, painfully slowly unfolding in slices, boxes, diamonds and
          chequerboards or again crawling in from any odd angle, and then being sucked
          into a black hole in the middle of the screen or scrolled off the screen at
          various angles...! Argh!

          Why do people insist on putting random - or any slide transition effects in
          presentations which do not add any value to the slideshow .. and in fact
          usually get in the way of the message that the presentation is trying to
          make. Or is it just me that finds them most irritating? I can see an
          occasional use for slide transition effects, but not used gratuitously.

          I'll get off my soapbox now.....

          - h
        • Jamie Nettles
          I suspect this PowerPoint madness is an introvert versus extrovert thing. One theory of introversion/extroversion says that we seek homeostasis in the level
          Message 4 of 18 , Feb 17, 2005
          • 0 Attachment
            I suspect this PowerPoint madness is an introvert versus extrovert
            thing. One theory of introversion/extroversion says that we seek
            homeostasis in the level of stimulation we receive. Introverts have
            lower comfort levels for stimulation, extroverts require more
            stimulation to feel comfortable. When an introvert (such as myself)
            sees a busy PowerPoint presentation (or web site or office environment)
            they feel overstimulated and seek to reduce the level of stimulation
            (I'll try to scroll web pages with animations or else hit the back
            button). Extroverts tend to be bored by simple, clean presentations.

            > -----Original Message-----
            > From: hj [mailto:hjohnstone@...]
            > Sent: Thursday, February 17, 2005 3:11 AM
            > To: agile-usability@yahoogroups.com
            > Subject: RE: [agile-usability] GUI component magnets
            >
            >
            >
            > > One product I know of is from 6PM.
            >
            > Sounds an interesting product ... but the powerpoint
            > presentation really put me off. I looked at a few slides then
            > switched it off.
            >
            > Random slide transitions slowing down the show and just
            > getting in the way.... titles crawling in from all
            > angles...the images in which I am interested, painfully
            > slowly unfolding in slices, boxes, diamonds and chequerboards
            > or again crawling in from any odd angle, and then being
            > sucked into a black hole in the middle of the screen or
            > scrolled off the screen at various angles...! Argh!
            >
            > Why do people insist on putting random - or any slide
            > transition effects in presentations which do not add any
            > value to the slideshow .. and in fact usually get in the way
            > of the message that the presentation is trying to make. Or is
            > it just me that finds them most irritating? I can see an
            > occasional use for slide transition effects, but not used
            > gratuitously.
            >
            > I'll get off my soapbox now.....
            >
            > - h
            >
            >
            >
            >
            > Yahoo! Groups Links
            >
            >
            >
            >
            >
            >
            >
            >
          • Petteri Hiisilä
            There are two classes of people in the world: those who divide the people of the world into two classes, and those who do not. (Robert Benchley) Sorry, I
            Message 5 of 18 , Feb 17, 2005
            • 0 Attachment
              "There are two classes of people in the world: those who divide the
              people of the world into two classes, and those who do not."

              (Robert Benchley)

              Sorry, I could't resist :)

              Best,
              Petteri

              Jamie Nettles wrote:
              > I suspect this PowerPoint madness is an introvert versus extrovert
              > thing. One theory of introversion/extroversion says that we seek
              > homeostasis in the level of stimulation we receive. Introverts have
              > lower comfort levels for stimulation, extroverts require more
              > stimulation to feel comfortable. When an introvert (such as myself)
              > sees a busy PowerPoint presentation (or web site or office environment)
              > they feel overstimulated and seek to reduce the level of stimulation
              > (I'll try to scroll web pages with animations or else hit the back
              > button). Extroverts tend to be bored by simple, clean presentations.
              >
              > > -----Original Message-----
              > > From: hj [mailto:hjohnstone@...]
              > > Sent: Thursday, February 17, 2005 3:11 AM
              > > To: agile-usability@yahoogroups.com
              > > Subject: RE: [agile-usability] GUI component magnets
              > >
              > >
              > >
              > > > One product I know of is from 6PM.
              > >
              > > Sounds an interesting product ... but the powerpoint
              > > presentation really put me off. I looked at a few slides then
              > > switched it off.
              > >
              > > Random slide transitions slowing down the show and just
              > > getting in the way.... titles crawling in from all
              > > angles...the images in which I am interested, painfully
              > > slowly unfolding in slices, boxes, diamonds and chequerboards
              > > or again crawling in from any odd angle, and then being
              > > sucked into a black hole in the middle of the screen or
              > > scrolled off the screen at various angles...! Argh!
              > >
              > > Why do people insist on putting random - or any slide
              > > transition effects in presentations which do not add any
              > > value to the slideshow .. and in fact usually get in the way
              > > of the message that the presentation is trying to make. Or is
              > > it just me that finds them most irritating? I can see an
              > > occasional use for slide transition effects, but not used
              > > gratuitously.
              > >
              > > I'll get off my soapbox now.....
              > >
              > > - h
              > >
              > >
              > >
              > >
              > > Yahoo! Groups Links
              > >
              > >
              > >
              > >
              > >
              > >
              > >
              > >
              >
              > *Yahoo! Groups Sponsor*
              > ADVERTISEMENT
              >
              >
              > ------------------------------------------------------------------------
              > *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/>.
              >
              >




              --
              Petteri Hiisilä
              Palveluarkkitehti / Interaction Designer /
              Alma Media Interactive Oy / NWS /
              +358505050123 / petteri.hiisila@...

              "I was told there's a miracle for each day that I try"
              - John Petrucci
            • Jade Ohlhauser
              In my opinion there are 10, those who understand binary and those who don t (I too apologize, maybe I can salvage this if I get serious...) Slide transitions,
              Message 6 of 18 , Feb 17, 2005
              • 0 Attachment
                In my opinion there are 10, those who understand binary and those who don't
                 
                (I too apologize, maybe I can salvage this if I get serious...)
                 
                Slide transitions, word transitions, and, even worse, letter transitions are a big pet peeve of mine. Have you ever had to sit though a slide where every letter "shoots" in accompanied with a sound effect. It sort of reminds me of the problem introduced with easy to use video editing. All of a sudden every transition is a "star wipe" (Home Simpson: "Why eat hamburger when you can have steak?"). This is all part of a larger issue, one that I consider personally very important: It's all about the content. Or, as Cooper puts it, "No matter how cool your interface is, less of it would be better."
                 
                I'm not sure if agile interface design can help this situation, but I do know here I try to encourage everyone to "challenge the design". Since the interface is finished along with everything else instead of being applied after, maybe that makes it harder to slip in whiz bang type stuff. If an effect is useless, chances are a developer will make that fact quite vocal after they've had to sit through it for the 10th time to get at some functionality.
                 
                Jade Ohlhauser
                Product Manager
                RPM Software                          
                www.rpmsoftware.com 403-265-6727
                 


                From: Petteri Hiisilä [mailto:petteri.hiisila@...]
                Sent: Thursday, February 17, 2005 10:11 AM
                To: agile-usability@yahoogroups.com
                Subject: Re: [agile-usability] GUI component magnets


                "There are two classes of people in the world: those who divide the
                people of the world into two classes, and those who do not."

                (Robert Benchley)

                Sorry, I could't resist :)

                Best,
                Petteri

                Jamie Nettles wrote:
                > I suspect this
                PowerPoint madness is an introvert versus extrovert
                > thing.  One
                theory of introversion/extroversion says that we seek
                > homeostasis in the
                level of stimulation we receive.  Introverts have
                > lower comfort
                levels for stimulation, extroverts require more
                > stimulation to feel
                comfortable.  When an introvert (such as myself)
                > sees a busy
                PowerPoint presentation (or web site or office environment)
                > they feel
                overstimulated and seek to reduce the level of stimulation
                > (I'll try to
                scroll web pages with animations or else hit the back
                > button). 
                Extroverts tend to be bored by simple, clean presentations.
                >
                >  > -----Original Message-----
                >  > From: hj
                [mailto:hjohnstone@...]
                >  > Sent: Thursday, February
                17, 2005 3:11 AM
                >  > To:
                agile-usability@yahoogroups.com
                >  > Subject: RE:
                [agile-usability] GUI component magnets
                >  >
                >  >
                >  >
                >  > > One product I know of is from
                6PM.
                >  >
                >  > Sounds an interesting product ...
                but the powerpoint
                >  > presentation really put me off. I looked
                at a few slides then
                >  > switched it off.
                >  >
                >  > Random slide transitions slowing down the show and
                just
                >  > getting in the way.... titles crawling in from
                all
                >  > angles...the images in which I am interested,
                painfully
                >  > slowly unfolding in slices, boxes, diamonds and
                chequerboards
                >  > or again crawling in from any odd angle, and
                then being
                >  > sucked into a black hole in the middle of the
                screen or
                >  > scrolled off the screen at various angles...!
                Argh!
                >  >
                >  > Why do people insist on putting
                random - or any slide
                >  > transition effects in presentations
                which do not add any
                >  > value to the slideshow .. and in fact
                usually get in the way
                >  > of the message that the presentation
                is trying to make. Or is
                >  > it just me that finds them most
                irritating? I can see an
                >  > occasional use for slide transition
                effects, but not used
                >  > gratuitously.
                >  >
                >  > I'll get off my soapbox now.....
                >  >
                >  > - h
                >  >
                >  >
                >  >
                >  >
                >  > Yahoo! Groups Links
                >  >
                >  >
                >  >
                >  >
                >  >
                >  >
                >  >
                >  >
                >
                >
                *Yahoo! Groups Sponsor*
                > ADVERTISEMENT
                >
                >
                >
                ------------------------------------------------------------------------
                >
                *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/>.
                >
                >




                --
                Petteri Hiisilä
                Palveluarkkitehti / Interaction Designer /
                Alma Media Interactive Oy / NWS /
                +358505050123 / petteri.hiisila@...

                "I was told there's a miracle for each day that I try"
                  - John Petrucci


              • Jamie Nettles
                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
                Message 7 of 18 , Feb 17, 2005
                • 0 Attachment
                  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?


                  From: Jade Ohlhauser [mailto:jade@...]
                  Sent: Thursday, February 17, 2005 10:36 AM
                  To: agile-usability@yahoogroups.com
                  Subject: RE: [agile-usability] GUI component magnets

                  In my opinion there are 10, those who understand binary and those who don't
                   
                  (I too apologize, maybe I can salvage this if I get serious...)
                   
                  Slide transitions, word transitions, and, even worse, letter transitions are a big pet peeve of mine. Have you ever had to sit though a slide where every letter "shoots" in accompanied with a sound effect. It sort of reminds me of the problem introduced with easy to use video editing. All of a sudden every transition is a "star wipe" (Home Simpson: "Why eat hamburger when you can have steak?"). This is all part of a larger issue, one that I consider personally very important: It's all about the content. Or, as Cooper puts it, "No matter how cool your interface is, less of it would be better."
                   
                  I'm not sure if agile interface design can help this situation, but I do know here I try to encourage everyone to "challenge the design". Since the interface is finished along with everything else instead of being applied after, maybe that makes it harder to slip in whiz bang type stuff. If an effect is useless, chances are a developer will make that fact quite vocal after they've had to sit through it for the 10th time to get at some functionality.
                   
                  Jade Ohlhauser
                  Product Manager
                  RPM Software                          
                  www.rpmsoftware.com 403-265-6727
                   


                  From: Petteri Hiisilä [mailto:petteri.hiisila@...]
                  Sent: Thursday, February 17, 2005 10:11 AM
                  To: agile-usability@yahoogroups.com
                  Subject: Re: [agile-usability] GUI component magnets


                  "There are two classes of people in the world: those who divide the
                  people of the world into two classes, and those who do not."

                  (Robert Benchley)

                  Sorry, I could't resist :)

                  Best,
                  Petteri

                  Jamie Nettles wrote:
                  > I suspect this PowerPoint madness is an introvert versus extrovert
                  > thing.  One theory of introversion/extroversion says that we seek
                  > homeostasis in the level of stimulation we receive.  Introverts have
                  > lower comfort levels for stimulation, extroverts require more
                  > stimulation to feel comfortable.  When an introvert (such as myself)
                  > sees a busy PowerPoint presentation (or web site or office environment)
                  > they feel overstimulated and seek to reduce the level of stimulation
                  > (I'll try to scroll web pages with animations or else hit the back
                  > button).  Extroverts tend to be bored by simple, clean presentations.
                  >
                  >  > -----Original Message-----
                  >  > From: hj [mailto:hjohnstone@...]
                  >  > Sent: Thursday, February 17, 2005 3:11 AM
                  >  > To: agile-usability@yahoogroups.com
                  >  > Subject: RE: [agile-usability] GUI component magnets
                  >  >
                  >  >
                  >  >
                  >  > > One product I know of is from 6PM.
                  >  >
                  >  > Sounds an interesting product ... but the powerpoint
                  >  > presentation really put me off. I looked at a few slides then
                  >  > switched it off.
                  >  >
                  >  > Random slide transitions slowing down the show and just
                  >  > getting in the way.... titles crawling in from all
                  >  > angles...the images in which I am interested, painfully
                  >  > slowly unfolding in slices, boxes, diamonds and chequerboards
                  >  > or again crawling in from any odd angle, and then being
                  >  > sucked into a black hole in the middle of the screen or
                  >  > scrolled off the screen at various angles...! Argh!
                  >  >
                  >  > Why do people insist on putting random - or any slide
                  >  > transition effects in presentations which do not add any
                  >  > value to the slideshow .. and in fact usually get in the way
                  >  > of the message that the presentation is trying to make. Or is
                  >  > it just me that finds them most irritating? I can see an
                  >  > occasional use for slide transition effects, but not used
                  >  > gratuitously.
                  >  >
                  >  > I'll get off my soapbox now.....
                  >  >
                  >  > - h
                  >  >
                  >  >
                  >  >
                  >  >
                  >  > Yahoo! Groups Links
                  >  >
                  >  >
                  >  >
                  >  >
                  >  >
                  >  >
                  >  >
                  >  >
                  >
                  > *Yahoo! Groups Sponsor*
                  > ADVERTISEMENT
                  >
                  >
                  > ------------------------------------------------------------------------
                  > *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/>.
                  >
                  >




                  --
                  Petteri Hiisilä
                  Palveluarkkitehti / Interaction Designer /
                  Alma Media Interactive Oy / NWS /
                  +358505050123 / petteri.hiisila@...

                  "I was told there's a miracle for each day that I try"
                    - John Petrucci



                • Ron Vutpakdi
                  ... components that are magnetic. It was really cool because you could work through GUI flow on a whiteboard with the little components - move things around
                  Message 8 of 18 , Feb 17, 2005
                  • 0 Attachment
                    --- In agile-usability@yahoogroups.com, Rob Keefer <rbkeefer@y...> wrote:
                    > I recently saw an article or advertisement for a package of GUI
                    components that are magnetic. It was really cool because you could
                    work through GUI flow on a whiteboard with the little components -
                    move things around and such. I can't find the reference though.
                    >
                    > Does anyone know where I can find something like this?

                    A couple of years ago, I purchased a set of thin magnets with website
                    components on them intended to be used on a whiteboard (or the
                    supplied thin whiteboard like sheet). The set was called "Magnetic
                    Elements."

                    It doesn't look like the company (or, really, the person selling these
                    things) is in business anymore since the listed website has nothing to
                    do with magnetic elements.

                    If someone else has something similar, I'd possibly be interested in
                    them as well if the components are for desktop apps.

                    Ron
                  • Cummins, Darin
                    This is a great idea. I think I ll try it. You can purchase thin, flexible magnets (the kind for sticking business cards to) at Office Max, etc. I have
                    Message 9 of 18 , Feb 17, 2005
                    • 0 Attachment

                      This is a great idea.  I think I’ll try it.

                       

                      You can purchase thin, flexible magnets (the kind for sticking business cards to) at Office Max, etc.  I have purchased 8.5X11 sheets of them for making magnetic signs.  They have a white front that can be written on with marker.  They are easy to cut with scissors, too.  I’m betting that you could create a usable set of components fairly easily, and still have some blanks to create missing components on the fly.

                       

                      --Darin

                       

                       


                      From: Ron Vutpakdi [mailto:vutpakdi@...]
                      Sent: Thursday, February 17, 2005 1:35 PM
                      To: agile-usability@yahoogroups.com
                      Subject: [agile-usability] Re: GUI component magnets

                       


                      --- In agile-usability@yahoogroups.com, Rob Keefer <rbkeefer@y...> wrote:
                      > I recently saw an article or advertisement for a package of GUI
                      components that are magnetic. It was really cool because you could
                      work through GUI flow on a whiteboard with the little components -
                      move things around and such. I can't find the reference though.

                      > Does anyone know where I can find something like this?

                      A couple of years ago, I purchased a set of thin magnets with website
                      components on them intended to be used on a whiteboard (or the
                      supplied thin whiteboard like sheet).  The set was called "Magnetic
                      Elements." 

                      It doesn't look like the company (or, really, the person selling these
                      things) is in business anymore since the listed website has nothing to
                      do with magnetic elements.

                      If someone else has something similar, I'd possibly be interested in
                      them as well if the components are for desktop apps.

                      Ron





                    • Jade Ohlhauser
                      There is a presentation on this: http://www.bentley.edu/events/agingbydesign2004/presentations/tedesco_ch adwickdias_tullis_fido.pdf These guys printed out
                      Message 10 of 18 , Feb 17, 2005
                      • 0 Attachment
                         
                        These guys printed out portions of their website on magnetic inkjet paper (!) so test subjects could re-arrange the site they way they would prefer to use it. Magnetic inkjet paper? OK - this I have to try. I'll reply to the group once I've tested it out.
                         
                        Jade Ohlhauser
                        Product Manager
                        RPM Software                          
                        www.rpmsoftware.com 403-265-6727
                         


                        From: Cummins, Darin [mailto:Darin_Cummins@...]
                        Sent: Thursday, February 17, 2005 1:46 PM
                        To: agile-usability@yahoogroups.com
                        Subject: RE: [agile-usability] Re: GUI component magnets

                        This is a great idea.  I think I’ll try it.

                         

                        You can purchase thin, flexible magnets (the kind for sticking business cards to) at Office Max, etc.  I have purchased 8.5X11 sheets of them for making magnetic signs.  They have a white front that can be written on with marker.  They are easy to cut with scissors, too.  I’m betting that you could create a usable set of components fairly easily, and still have some blanks to create missing components on the fly.

                         

                        --Darin

                         

                         


                        From: Ron Vutpakdi [mailto:vutpakdi@...]
                        Sent: Thursday, February 17, 2005 1:35 PM
                        To: agile-usability@yahoogroups.com
                        Subject: [agile-usability] Re: GUI component magnets

                         


                        --- In agile-usability@yahoogroups.com, Rob Keefer <rbkeefer@y...> wrote:
                        > I recently saw an article or advertisement for a package of GUI
                        components that are magnetic. It was really cool because you could
                        work through GUI flow on a whiteboard with the little components -
                        move things around and such. I can't find the reference though.

                        > Does anyone know where I can find something like this?

                        A couple of years ago, I purchased a set of thin magnets with website
                        components on them intended to be used on a whiteboard (or the
                        supplied thin whiteboard like sheet).  The set was called "Magnetic
                        Elements." 

                        It doesn't look like the company (or, really, the person selling these
                        things) is in business anymore since the listed website has nothing to
                        do with magnetic elements.

                        If someone else has something similar, I'd possibly be interested in
                        them as well if the components are for desktop apps.

                        Ron






                      • Phlip
                        ... A headline from last week s www.onion.com: Project Manager Leaves Suicide PowerPoint Presentation PORTLAND, OR—Project manager Ron Butler left behind a
                        Message 11 of 18 , Feb 17, 2005
                        • 0 Attachment
                          Jamie Nettles wrote:

                          > I suspect this PowerPoint madness is an introvert versus extrovert
                          > thing. One theory of introversion/extroversion says that we seek
                          > homeostasis in the level of stimulation we receive. Introverts have
                          > lower comfort levels for stimulation, extroverts require more
                          > stimulation to feel comfortable. When an introvert (such as myself)
                          > sees a busy PowerPoint presentation (or web site or office environment)
                          > they feel overstimulated and seek to reduce the level of stimulation
                          > (I'll try to scroll web pages with animations or else hit the back
                          > button). Extroverts tend to be bored by simple, clean presentations.

                          A headline from last week's www.onion.com:

                          Project Manager Leaves Suicide PowerPoint Presentation\

                          PORTLAND, OR—Project manager Ron Butler left behind a 48-slide
                          PowerPoint presentation explaining his tragic decision to commit
                          suicide, coworkers reported Tuesday.

                          "When I first heard that Ron had swallowed an entire bottle of
                          sleeping pills, I was shocked," said Hector Benitez, Butler's friend
                          and coworker at Williams+Kennedy Marketing Consultants. "But after the
                          team went through Ron's final PowerPoint presentation, I had a solid
                          working knowledge of the pain he was feeling, his attempts to cope,
                          and the reasons for his ultimate decision."

                          "I just wish he would've shot me an e-mail asking for help," Benitez added.

                          Butler broke his presentation into four categories: Assessment Of
                          Current Situation, Apologies & Farewells, Will & Funeral Arrangements,
                          and Final Thoughts.

                          According to Williams+Kennedy president Bradford Williams,
                          finalgoodbye.ppt was "clear, concise, and persuasive."

                          --
                          Phlip
                        • Jeff Patton
                          ... 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
                          Message 12 of 18 , Feb 17, 2005
                          • 0 Attachment
                            --- 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
                          • Rob Keefer
                            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
                            Message 13 of 18 , Feb 18, 2005
                            • 0 Attachment
                              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
                              >
                              >
                              >
                              >
                              >
                            • Desilets, Alain
                              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. 4. The UI layer should be
                              Message 14 of 18 , Feb 18, 2005
                              • 0 Attachment
                                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.

                                <SNIP>

                                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.

                                -- Alain:
                                I agree with both these statements. The main reason developpers get angry
                                when they need to change code that "already works" is that they are afraid
                                of breaking it. This usually happens when the code in question is not
                                properly regression tested. In such situation, the natural reaction is to
                                question the value-added of the change compared to the risk of breaking
                                something (does the user REALLY need this to be a picklist instead of a list
                                of checkboxes?).

                                The secret of regression testing GUIs is, as Rob points out, to make the
                                graphical layer be very thin and to mostly test the model layer. There is a
                                very interesting small paper called "The Humble Dialog Box" that describes
                                how to do this (just google that phrase to find it). This is a simple
                                Model-View (no Controller) approach where the View is really dumb and does
                                nothing more than display data, catch user events and dispatch them to the
                                model, and answer questions from the model about what it is currently
                                displaying. The model contains all the business and interaction logic. You
                                can then do most of your testing on the model.

                                Note that the Humble Dialog Box approach suggests that you use a MockView
                                class instead of an actual graphical view when regression testing.
                                Personally, I have found that it is just as easy to use an actual graphical
                                view even when testing. You just have to implement methods in the graphical
                                View that return the values displayed in particular fields, and that can
                                programmatically fire events like clicking on a particular button. This has
                                the added advantage that you can test the model by exercising it through the
                                actual graphical view that will be connected to it when the system is
                                operational.
                                ----
                              • Chris Pehura
                                I don t have those inner conflicts any more. Mine were between my inner marketer, architect and programmer. Now they only show up when I do the role specific
                                Message 15 of 18 , Feb 18, 2005
                                • 0 Attachment
                                  I don't have those inner conflicts any more. Mine were between my inner marketer, architect and programmer. Now they only show up when I do the role specific tasks. I have to cue them in meetings.
                                  -----Original Message-----
                                  From: Rob Keefer <rbkeefer@...>
                                  Date: Fri, 18 Feb 2005 05:35:09
                                  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









                                  Chris Pehura

                                  (630) 696-8101
                                  chris@...
                                • Jade Ohlhauser
                                  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
                                  Message 16 of 18 , Feb 18, 2005
                                  • 0 Attachment
                                    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 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
                                    >
                                    >
                                    >
                                    >
                                    >

                                  • 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 17 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 18 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.