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

Re: [agile-usability] On the Communication between Planner, Designer, and Developer

Expand Messages
  • Adrian Howard
    On 8 May 2006, at 21:25, Ron Jeffries wrote: [snip] ... [snip] Seconded. Getting the UI abstractions into the code makes things much easier all round. As an
    Message 1 of 26 , May 10, 2006
    • 0 Attachment
      On 8 May 2006, at 21:25, Ron Jeffries wrote:
      [snip]
      > Who knows ... STANDARD_BUTTON_WIDTH, BIG_BUTTON_HEIGHT, ALERT_COLOR,
      > ... anything to abstract out the ideas that the designers are
      > developing, so that when they decide that pink letters on an orange
      > background aren't so good after all, we can just tweak a couple
      > values and rebuild.
      [snip]

      Seconded. Getting the UI abstractions into the code makes things much
      easier all round.

      As an aside this is one of the problems with people still working in
      a "throw the UI specs over the wall to the developer" mode. When
      developers are presented with a bunch of user journeys, wireframes,
      etc. without the UX person around to explain /why/ things have been
      done in such-and-such a way you don't notice the abstractions, so
      they don't make it into the code, so they get mucked about when the
      inevitable changes arrive....

      Cheers,

      Adrian
    • Jeff Patton
      June, Sorry I didn t get back to you right away. I m sure you understand how non-trivial the situation you describe is – and
      Message 2 of 26 , May 10, 2006
      • 0 Attachment
        <warning - long response>
        June,

        Sorry I didn't get back to you right away. I'm sure you understand
        how non-trivial the situation you describe is – and potentially how
        risky that makes giving advice. But, although I've hesitated, I won't
        let it stop me.

        The pain point or problem I hear you wanting to solve is the large
        amount of time planners spend crafting this communication artefact to
        designers and developers – so I'll talk about that first. Of course
        if you take a hard agile line with all this, you'd do everything you
        could to avoid the written communication. You do that by seating the
        teams close together, by encouraging them to talk over a whiteboard
        whenever possible.

        But, this doesn't solve everything.

        The planner seems to be performing the role of an interaction designer
        [they invent what needs to be built and document the user interaction
        and what I think is the visual design]. Concurrently they perform the
        role of project manager. Sounds tough. Sounds like a lot of
        responsibility for one person. In support of the interaction design
        work, they'll still need to work through somehow what the application
        should look and behave like. They'll need to model with cards, draw
        pictures on whiteboards, build and test paper prototypes. So, they
        still need to build something to contain all their own thoughts – even
        if it isn't powerpoint. That'll take time.

        And, if we encourage the planner to talk more over the whiteboard, and
        over their paper prototypes with the designers and developers, that's
        going to take lots of time.

        So, at the end of the day, we won't give the planners back any more
        time – they'll be spending as much or more, but we may reduce some
        significant risks of miscommunication caused by reliance on paper
        documents. In addition, I think people are ultimately happier when
        they can talk… but does this organization place value on "happy"? Do
        they perceive any pain caused by miscommunication?

        As far as a documentation mechanism goes, right now, I believe
        powerpoint works as well as anything. These days I spend more of my
        life than I want to admit building powerpoint storyboards. Part of
        the reason I prefer it over potentially other tools is that I can
        control the fidelity a little bit. By that I mean I can make very
        realistic UI when I think the situation demands it, or I can paste in
        and manipulate whiteboard photos when they're sufficient – and lots of
        points in between. The point is I control the fidelity. But, it
        doesn't seem like your planners are working with that "fidelity knob".
        Could they be? Would it save them time?

        What does come to mind is that the scale of the operation you describe
        indicates that building a healthy _community of interest_ is in order.
        By that I mean planners need to start regular collaboration with each
        other about how they do their job. They need to share techniques,
        document and share interaction patterns, basically have the
        opportunity to collaborate with each other about how to get better at
        what they do. Does this sort of opportunity for planner collaboration
        exist in the organization? If not, could it?

        Seems like planners could also work in small teams – dividing up work
        and building these prototypes faster. I've seen many organizations
        that have a design team that feeds and collaborates with development.
        Whether they believe they are or not, the BA teams we use at
        ThoughtWorks on projects function as a design team. They collaborate
        and take collective responsibility for the functionality of the
        software, the artefacts they hand to development, and the day to day
        communication with development. Could planners work in 2-3 person
        teams? Would that help them move faster?

        Now, the things that make me twitchy – problems I sense but problems
        you didn't express:

        How does the planner determine what was needed? How does he research
        and understand his users and their needs? How does he validate his
        solution is indeed a good one? Seems his life is so dominated by
        building powerpoints to keep the project running that he may have
        little time to determine if the resulting product is going to be a
        good one. That scares me. Issues there would manifest themselves as
        projects being completed on time, but end users and customers not
        liking what was built. Does that happen?

        I'm twitchy about how little the planners seem to collaborate with
        anyone on what they doe – end users, developers, each other. I'm
        always suspicious of solutions arrived at by individuals working in
        isolation with little context on which to solve their problems.

        What do you mean by designers? [or did you say and I missed it?]
        Are they designing the inside of the system – the architecture-y stuff
        – or the outside if the system – the visual and interaction design?
        My guess is the former – not the latter. If that's the case, based on
        what I'm hearing as constrained collaboration between them and
        developers, I suspect problems come out of that too.

        Finally, the last piece of advice I could give is think about how
        things would look if they were better. What would things look like if
        problems were solved? Then given that mental picture of the solution,
        what's the first tangible thing you can do/change you can make to move
        towards it?

        In the future do planners simply spend less time doing powerpoint work
        because they have a cool prototyping tool? This brings me back to one
        of the first things I asked – what really is the problem here? Is
        this really about saving the labour costs/time spent by the planners?
        No offence to the planners – but who cares? If you saved them 25% of
        their time, would that be significant to the company you work for?
        Might the company them be tempted to fire 25% of the planners? The
        net result being that their life really isn't any better. Look deeper
        to what the problem really is here. Does it take to long to build
        product? Is the product quality low? Is it too expense to build
        products vs. your competition – do you need to reduce costs overall?
        Where is the pain coming from?

        Hope that give you some more things to think about – and potentially
        some more questions to ask.

        Thanks for posting this here to make the discussion public.

        -Jeff

        --- In agile-usability@yahoogroups.com, "June Kim" <juneaftn@...> wrote:
        >
        > Following is email I sent to Jeff but I suppose it didn't make it to
        > him. I think it would be better to post it to a larger audience and
        > ask for help.
        >
        > ---------- Forwarded message ----------
        > From: June Kim
        > Date: Apr 19, 2006 5:08 PM
        > Subject: On the Communication between Planner, Designer, and Developer
        > [snip]
        >
        > BTW, I just want to ask some comments from you. I would greatly
        > appreciate your opinion or any reference you could afford me.
        >
        > As I told you I am coaching a few major web portal companies in Korea.
        > They have half a thousand developers and a few hundreds of designers
        > and planners. Oh, the job title, "planner". I think you are
        > unfamiliar with that job title. In Korea, we call those people who
        invent
        > and plan the web service(product manager?) as planners. They invent
        > the concepts and ideas and then draw storyboards and sometimes
        > organize the team and arrange the schedule, being the mediator between
        > designers and developers.
        ...
      • Jeff Patton
        ... Ditto! There s been lots of talk about how you can t refactor UI. By that developers mean that refactoring UI code is hard. Well I suppose it is - but
        Message 3 of 26 , May 10, 2006
        • 0 Attachment
          --- In agile-usability@yahoogroups.com, Adrian Howard <adrianh@...> wrote:
          >
          >
          > On 8 May 2006, at 21:25, Ron Jeffries wrote:
          > [snip]
          > > Who knows ... STANDARD_BUTTON_WIDTH, BIG_BUTTON_HEIGHT, ALERT_COLOR,
          > > ... anything to abstract out the ideas that the designers are
          > > developing, so that when they decide that pink letters on an orange
          > > background aren't so good after all, we can just tweak a couple
          > > values and rebuild.
          > [snip]
          >
          > Seconded. Getting the UI abstractions into the code makes things much
          > easier all round.

          Ditto!

          There's been lots of talk about how you can't refactor UI. By that
          developers mean that refactoring UI code is hard. Well I suppose it
          is - but it's extra hard to refactor code when the concepts in the UI
          aren't reflected in the code. I've found that when the UI concepts
          arrive in the code as first class objects, changing details about
          those concepts is easier. By that I mean changing/refactoring the UI.

          Throwing anything over a wall injects risk into a project. UI to
          developers is just another wall.

          [Live from London]
          -Jeff
        • Jared M. Spool
          ... Dare I make the Patterns war cry again? Jared Jared M. Spool, Founding Principal, User Interface Engineering 510 Turnpike Street, Suite 102, North
          Message 4 of 26 , May 10, 2006
          • 0 Attachment
            >On 8 May 2006, at 21:25, Ron Jeffries wrote:
            >[snip]
            > > Who knows ... STANDARD_BUTTON_WIDTH, BIG_BUTTON_HEIGHT, ALERT_COLOR,
            > > ... anything to abstract out the ideas that the designers are
            > > developing, so that when they decide that pink letters on an orange
            > > background aren't so good after all, we can just tweak a couple
            > > values and rebuild.
            >[snip]

            At 08:03 AM 5/10/2006, Adrian Howard wrote:

            >Seconded. Getting the UI abstractions into the code makes things much
            >easier all round.
            >
            >As an aside this is one of the problems with people still working in
            >a "throw the UI specs over the wall to the developer" mode. When
            >developers are presented with a bunch of user journeys, wireframes,
            >etc. without the UX person around to explain /why/ things have been
            >done in such-and-such a way you don't notice the abstractions, so
            >they don't make it into the code, so they get mucked about when the
            >inevitable changes arrive....

            Dare I make the "Patterns" war cry again?

            Jared


            Jared M. Spool, Founding Principal, User Interface Engineering
            510 Turnpike Street, Suite 102, North Andover, MA 01845
            978 327-5561 jspool@... http://www.uie.com
            Blog: http://www.uie.com/brainsparks
          • Adrian Howard
            On 10 May 2006, at 14:05, Jeff Patton wrote: [snip] ... [snip] I m pleasantly surprised how many XP coding practices fall nicely into place when you take the
            Message 5 of 26 , May 10, 2006
            • 0 Attachment
              On 10 May 2006, at 14:05, Jeff Patton wrote:
              [snip]
              > There's been lots of talk about how you can't refactor UI. By that
              > developers mean that refactoring UI code is hard. Well I suppose it
              > is - but it's extra hard to refactor code when the concepts in the UI
              > aren't reflected in the code. I've found that when the UI concepts
              > arrive in the code as first class objects, changing details about
              > those concepts is easier. By that I mean changing/refactoring the UI.
              [snip]

              I'm pleasantly surprised how many XP "coding" practices fall nicely
              into place when you take the UI into account. I rambled about this a
              little last year (http://groups.yahoo.com/group/agile-usability/
              message/1373).

              Adrian
            • Adrian Howard
              On 10 May 2006, at 14:35, Jared M. Spool wrote: [snip] ... [snip] ... I m thinking more of application-specific UI abstractions - and they don t seem to fit
              Message 6 of 26 , May 10, 2006
              • 0 Attachment
                On 10 May 2006, at 14:35, Jared M. Spool wrote:
                [snip]
                > At 08:03 AM 5/10/2006, Adrian Howard wrote:
                [snip]
                >> As an aside this is one of the problems with people still working in
                >> a "throw the UI specs over the wall to the developer" mode. When
                >> developers are presented with a bunch of user journeys, wireframes,
                >> etc. without the UX person around to explain /why/ things have been
                >> done in such-and-such a way you don't notice the abstractions, so
                >> they don't make it into the code, so they get mucked about when the
                >> inevitable changes arrive....
                >
                > Dare I make the "Patterns" war cry again?

                I'm thinking more of application-specific UI abstractions - and they
                don't seem to fit under the pattern banner to me.... am I wrong?

                Adrian
              • Jared M. Spool
                ... I think UI patterns could work in an application-specific manner. They take the abstractions you are talking about and add other descriptive components,
                Message 7 of 26 , May 10, 2006
                • 0 Attachment
                  At 09:59 AM 5/10/2006, Adrian Howard wrote:

                  > > At 08:03 AM 5/10/2006, Adrian Howard wrote:
                  >[snip]
                  > >> As an aside this is one of the problems with people still working in
                  > >> a "throw the UI specs over the wall to the developer" mode. When
                  > >> developers are presented with a bunch of user journeys, wireframes,
                  > >> etc. without the UX person around to explain /why/ things have been
                  > >> done in such-and-such a way you don't notice the abstractions, so
                  > >> they don't make it into the code, so they get mucked about when the
                  > >> inevitable changes arrive....
                  > >
                  >On 10 May 2006, at 14:35, Jared M. Spool wrote:
                  > > Dare I make the "Patterns" war cry again?
                  >
                  >I'm thinking more of application-specific UI abstractions - and they
                  >don't seem to fit under the pattern banner to me.... am I wrong?

                  I think UI patterns could work in an application-specific manner. They take
                  the abstractions you are talking about and add other descriptive
                  components, such as the context of use, history, and other required patterns.

                  I'm thinking by making your patterns align with the UI abstractions, you
                  get more mileage for not much more effort.

                  Jared


                  Jared M. Spool, Founding Principal, User Interface Engineering
                  510 Turnpike Street, Suite 102, North Andover, MA 01845
                  978 327-5561 jspool@... http://www.uie.com
                  Blog: http://www.uie.com/brainsparks
                • Adrian Howard
                  ... [snip] ... Oh yes, I quite agree. It s more a question of nomenclature. Once you add a bunch of application specific detail to them is it really right to
                  Message 8 of 26 , May 11, 2006
                  • 0 Attachment
                    On 10 May 2006, at 17:16, Jared M. Spool wrote:

                    > At 09:59 AM 5/10/2006, Adrian Howard wrote:
                    [snip]
                    >> I'm thinking more of application-specific UI abstractions - and they
                    >> don't seem to fit under the pattern banner to me.... am I wrong?
                    >
                    > I think UI patterns could work in an application-specific manner.
                    > They take
                    > the abstractions you are talking about and add other descriptive
                    > components, such as the context of use, history, and other required
                    > patterns.
                    >
                    > I'm thinking by making your patterns align with the UI
                    > abstractions, you
                    > get more mileage for not much more effort.

                    Oh yes, I quite agree. It's more a question of nomenclature. Once you
                    add a bunch of application specific detail to them is it really right
                    to carry on calling them patterns? Haven't they then lost the generic
                    nature that the name implies?

                    Adrian
                  • June Kim
                    ... That s OK. I really appreciate your long and detailed response. ... They initially devise and propose the core idea of the service. They do strategic
                    Message 9 of 26 , May 11, 2006
                    • 0 Attachment
                      2006/5/10, Jeff Patton <jpatton@...>:
                      > <warning - long response>
                      > June,
                      >
                      > Sorry I didn't get back to you right away. I'm sure you understand

                      That's OK. I really appreciate your long and detailed response.

                      > how non-trivial the situation you describe is – and potentially how
                      > risky that makes giving advice. But, although I've hesitated, I won't
                      > let it stop me.
                      >
                      > The pain point or problem I hear you wanting to solve is the large
                      > amount of time planners spend crafting this communication artefact to
                      > designers and developers – so I'll talk about that first. Of course
                      > if you take a hard agile line with all this, you'd do everything you
                      > could to avoid the written communication. You do that by seating the
                      > teams close together, by encouraging them to talk over a whiteboard
                      > whenever possible.
                      >
                      > But, this doesn't solve everything.
                      >
                      > The planner seems to be performing the role of an interaction designer
                      > [they invent what needs to be built and document the user interaction
                      > and what I think is the visual design]. Concurrently they perform the
                      > role of project manager. Sounds tough. Sounds like a lot of

                      They initially devise and propose the core idea of the service. They
                      do strategic planning for the web service also; thinking about the
                      positions of the web service in the company's whole web services
                      portfolio, SWOT analysis, benchmarking other rival services, sometimes
                      coming up with marketing plan and etc. And usually there is a process
                      that the planner should do the presentation in front of executives to
                      persuade them into allowing the service.

                      > responsibility for one person. In support of the interaction design
                      > work, they'll still need to work through somehow what the application
                      > should look and behave like. They'll need to model with cards, draw
                      > pictures on whiteboards, build and test paper prototypes. So, they
                      > still need to build something to contain all their own thoughts – even
                      > if it isn't powerpoint. That'll take time.
                      >
                      > And, if we encourage the planner to talk more over the whiteboard, and
                      > over their paper prototypes with the designers and developers, that's
                      > going to take lots of time.
                      >
                      > So, at the end of the day, we won't give the planners back any more
                      > time – they'll be spending as much or more, but we may reduce some
                      > significant risks of miscommunication caused by reliance on paper
                      > documents. In addition, I think people are ultimately happier when
                      > they can talk… but does this organization place value on "happy"? Do
                      > they perceive any pain caused by miscommunication?
                      >
                      > As far as a documentation mechanism goes, right now, I believe
                      > powerpoint works as well as anything. These days I spend more of my
                      > life than I want to admit building powerpoint storyboards. Part of
                      > the reason I prefer it over potentially other tools is that I can
                      > control the fidelity a little bit. By that I mean I can make very
                      > realistic UI when I think the situation demands it, or I can paste in
                      > and manipulate whiteboard photos when they're sufficient – and lots of
                      > points in between. The point is I control the fidelity. But, it
                      > doesn't seem like your planners are working with that "fidelity knob".
                      > Could they be? Would it save them time?

                      Enlightening! I never thought I could lower the fidelity in the
                      power-point. Of course, we could even use varying levels of fidelity
                      in a same power-point file, depending on the significance and needs.

                      I did some instruction on paper prototyping to a few teams(developer
                      teams and planner teams), and they were very interested in the
                      technique and Guindon's idea of opportunistic design(top-down and
                      bottom-up).

                      I totally agree that fidelity knob is very important. Thanks for
                      pointing this out.

                      >
                      > What does come to mind is that the scale of the operation you describe
                      > indicates that building a healthy _community of interest_ is in order.
                      > By that I mean planners need to start regular collaboration with each
                      > other about how they do their job. They need to share techniques,
                      > document and share interaction patterns, basically have the
                      > opportunity to collaborate with each other about how to get better at
                      > what they do. Does this sort of opportunity for planner collaboration
                      > exist in the organization? If not, could it?

                      I am trying to nudge in. With a few teams, I came to the point where
                      the planner team and developer team became willing to collaborate
                      (like agile planning) but still the designer dept is the problem.
                      There is a political issue, and a mentality issue.


                      >
                      > Seems like planners could also work in small teams – dividing up work
                      > and building these prototypes faster. I've seen many organizations
                      > that have a design team that feeds and collaborates with development.
                      > Whether they believe they are or not, the BA teams we use at

                      What are the BA teams?

                      > ThoughtWorks on projects function as a design team. They collaborate
                      > and take collective responsibility for the functionality of the
                      > software, the artefacts they hand to development, and the day to day
                      > communication with development. Could planners work in 2-3 person
                      > teams? Would that help them move faster?

                      They could in some fortunate teams, and it would make them move
                      faster. But there are planner teams that take responsibility for
                      almost 100 services(24 x 7) with 10 people, each one serving 10
                      services. They make a new event for their services, plan renewal ,
                      resolve customer dissatisfaction and etc. For such a team, that kind
                      of move might not be feasible, well, in the shorter term

                      >
                      > Now, the things that make me twitchy – problems I sense but problems
                      > you didn't express:
                      >
                      > How does the planner determine what was needed? How does he research
                      > and understand his users and their needs? How does he validate his
                      > solution is indeed a good one? Seems his life is so dominated by
                      > building powerpoints to keep the project running that he may have
                      > little time to determine if the resulting product is going to be a
                      > good one. That scares me. Issues there would manifest themselves as
                      > projects being completed on time, but end users and customers not
                      > liking what was built. Does that happen?
                      >

                      I would say yes. I think they do mostly speculative researches.
                      Conceptual design?

                      > I'm twitchy about how little the planners seem to collaborate with
                      > anyone on what they doe – end users, developers, each other. I'm
                      > always suspicious of solutions arrived at by individuals working in
                      > isolation with little context on which to solve their problems.
                      >
                      > What do you mean by designers? [or did you say and I missed it?]

                      They are graphic designers. Planners plan the service, developers
                      implement the "blue-print" and designers do all the artistic parts,
                      like drawing jpg images, choosing specific colors for buttons, and
                      even coding html. They have not much room to consider usability,
                      information architecture, and all the luxury, but they are always
                      concerned about aesthetics, I guess.

                      Oh, the mentality problem I mentioned above, is that they are worried
                      if their desiging skill would lag or even deteriorate when they join
                      to become a whole team with developers and planners. They are some
                      designers who belong to a task force (with developers and planners in
                      the same room) but their pride is very low and they consider they are
                      there because their design skill is not professional enough. They want
                      to be with their kinds. They want to form a professional group.

                      > Are they designing the inside of the system – the architecture-y stuff
                      > – or the outside if the system – the visual and interaction design?

                      Outside.

                      > My guess is the former – not the latter. If that's the case, based on
                      > what I'm hearing as constrained collaboration between them and
                      > developers, I suspect problems come out of that too.
                      >
                      > Finally, the last piece of advice I could give is think about how
                      > things would look if they were better. What would things look like if
                      > problems were solved? Then given that mental picture of the solution,
                      > what's the first tangible thing you can do/change you can make to move
                      > towards it?
                      >
                      > In the future do planners simply spend less time doing powerpoint work
                      > because they have a cool prototyping tool? This brings me back to one
                      > of the first things I asked – what really is the problem here? Is
                      > this really about saving the labour costs/time spent by the planners?
                      > No offence to the planners – but who cares? If you saved them 25% of
                      > their time, would that be significant to the company you work for?
                      > Might the company them be tempted to fire 25% of the planners? The
                      > net result being that their life really isn't any better. Look deeper
                      > to what the problem really is here. Does it take to long to build
                      > product? Is the product quality low? Is it too expense to build
                      > products vs. your competition – do you need to reduce costs overall?
                      > Where is the pain coming from?
                      >


                      These are good questions.

                      I started coaching a new team with developers and planners (haven't
                      yet figured out to have the designer participate, and they are
                      thinking about working without a designer as far as they can get --
                      they think the political problem is too difficult to solve) and their
                      morale is very high. The team is working very agile using agile
                      usability techniques.

                      The problem is other teams.

                      > Hope that give you some more things to think about – and potentially
                      > some more questions to ask.

                      Thank you. I will keep in my mind those questions and report the result later.

                      >
                      > Thanks for posting this here to make the discussion public.
                      >

                      Your welcome. Thank you again for your response.

                      June

                      > -Jeff
                      >
                      > --- In agile-usability@yahoogroups.com, "June Kim" <juneaftn@...> wrote:
                      > >
                      > > Following is email I sent to Jeff but I suppose it didn't make it to
                      > > him. I think it would be better to post it to a larger audience and
                      > > ask for help.
                      > >
                      > > ---------- Forwarded message ----------
                      > > From: June Kim
                      > > Date: Apr 19, 2006 5:08 PM
                      > > Subject: On the Communication between Planner, Designer, and Developer
                      > > [snip]
                      > >
                      > > BTW, I just want to ask some comments from you. I would greatly
                      > > appreciate your opinion or any reference you could afford me.
                      > >
                      > > As I told you I am coaching a few major web portal companies in Korea.
                      > > They have half a thousand developers and a few hundreds of designers
                      > > and planners. Oh, the job title, "planner". I think you are
                      > > unfamiliar with that job title. In Korea, we call those people who
                      > invent
                      > > and plan the web service(product manager?) as planners. They invent
                      > > the concepts and ideas and then draw storyboards and sometimes
                      > > organize the team and arrange the schedule, being the mediator between
                      > > designers and developers.
                      > ...
                      >
                      >
                      >
                      >
                      >
                      >
                      >
                      >
                      > Yahoo! Groups Links
                      >
                      >
                      >
                      >
                      >
                      >
                      >
                      >
                    • Jared M. Spool
                      ... I guess I was thinking about large applications, where design elements (such as date input or user login) may repeat themselves multiple times in a variety
                      Message 10 of 26 , May 11, 2006
                      • 0 Attachment
                        At 06:41 AM 5/11/2006, Adrian Howard wrote:
                        >Oh yes, I quite agree. It's more a question of nomenclature. Once you
                        >add a bunch of application specific detail to them is it really right
                        >to carry on calling them patterns? Haven't they then lost the generic
                        >nature that the name implies?

                        I guess I was thinking about large applications, where design elements
                        (such as date input or user login) may repeat themselves multiple times in
                        a variety of contexts. I would think patterns would be ideal in this scenario.

                        I agree that for small applications, it's probably overkill. But for a
                        suite of small applications, it could be useful.

                        Jared


                        Jared M. Spool, Founding Principal, User Interface Engineering
                        510 Turnpike Street, Suite 102, North Andover, MA 01845
                        978 327-5561 jspool@... http://www.uie.com
                        Blog: http://www.uie.com/brainsparks
                      Your message has been successfully submitted and would be delivered to recipients shortly.