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

[usage-centered] Re: Usage-centered vs. (formal)

Expand Messages
  • Nuno Nunes
    Hi there, I m in this list due to a tip from Dave Roberts. We co-organized the WISDOM 99 workshop at Interact 99 (http://math.uma.pt/wisdom99). ... The major
    Message 1 of 9 , Aug 4, 1998
    • 0 Attachment
      Hi there, I'm in this list due to a tip from Dave Roberts. We co-organized
      the WISDOM'99 workshop at Interact'99 (http://math.uma.pt/wisdom99).

      >> - What is the difference between a scenario and a use case diagram?
      The major point here is how do you detail the use cases and what goals do
      you try to meet in that process. In our approach (WISDOM method) we use
      activity diagrams to detail use cases. Activity diagrams are a very good
      tool to show task flows and create dependencies towards views in the
      interactive system. For more on our approach see the related paper in the
      WISDOM'99 site. There are also other approaches in the selected papers of
      our workshop. Check also another workshop at Interact'99 on Use cases and
      HCI.

      >> - How does UML help in user/usage centered design?
      >I don't think UML itself is the key. I think the team agreeing on a
      >common language is what matters. I have seen so many projects where
      >the different disciplines on a team did not communicate.


      I totally agree with Dave, UML is not the issue. I would add some other
      benefits of using UML. It's a standard, you have broad (although not that
      good) CASE tool support, it gathers a lot of very good ideas from 2nd
      generation A&D methods in the OO field and there is a lot of promissing work
      over UML.

      >> Another point is the issue of tools to support user centered design.
      >I have always been entirely pragmatic on this. I find a tool that does
      >most of what I need and adapt the method to fit within the tool. It
      >doesn't always give exactly what you want. However, as CASE tools are
      >very often tuned (at least partly) to team working and communication
      >then they form a good backbone.


      Again I totally agree with Dave. We can argue about proper tool support but
      we can't have it untill we try to tailor our methods and process to the
      existing tools and push vendor to improve. On this pragmatic approach see
      Shijian Lu's approach on a Rose extension that translates Diane+ to UML and
      vice versa. All of them are mentioned at the WISDOM'99 position papers.

      Nuno
    • Hallvard Trætteberg
      Hi all, I m a dr. student working on integrating user interface modeling with systems engineering. Currently I m looking at task modeling and user interface
      Message 2 of 9 , Jun 22, 1999
      • 0 Attachment
        Hi all,

        I'm a dr. student working on integrating user interface modeling with systems
        engineering. Currently I'm looking at task modeling and user interface design,
        and as a participant at the CHI'99 Workshop on tools for task based user
        interface
        modeling it was natural to join the usage-centered design session.

        I'm working within a tradition of (semi-)formal modeling of organisations
        and systems and
        have the same approach to user interface modeling and design. With this
        background
        I'm (naturally) sceptical to UML and its informal approach to modeling
        (languages),
        especially the Use Case sub-language. The usage-centered design session was
        disappointing for several reasons:
        - The presenter was far too dominating and "sales" oriented
        - He seemed to neglect a lot of work on user interface modeling
        (languages), both for
        specification (task analysis) and design (user interface construction).
        - I can accept pragmatic reasons for arguing for and using UML with industry,
        but someone presenting a method based on such a weak notation as special
        and wonderful,
        must have a very simplified view of user interface design (If this is all
        there is to it, it would
        have been discovered long time ago. Indeed, at the session there were
        references to old
        work along these lines, that the presenter didn't seem interested in).

        However, the idea of usage-centered design seems fruitful and I'm very
        interested
        in discussing this topic. E.g., what are the advantages and weaknesses of
        UML for
        user interface specification and design, and how should we address
        shortcomings.

        Hallvard

        Hallvard Trætteberg,
        Stipendiat ved Institutt for Datateknikk og Informasjonsvitenskap (IDI)
        Fakultet for Fysikk, Informatikk og Matematikk (FIM)
        Norges Teknisk-Naturvitenskapelige Universitet (NTNU)
        Kontor: F-262, Nye Elektro, Tlf: +47 7359 3443, Fax: +47 7359 4466

        ------------------------------------------------------------------------

        eGroups.com home: http://www.egroups.com/group/usage-centered
        http://www.egroups.com - Simplifying group communications
      • Larry Constantine
        Hallvard raises some interesting issues. One is the question of formal, rigorous modeling languages vs. informal, non-rigorous modeling schemes and
        Message 3 of 9 , Jun 23, 1999
        • 0 Attachment
          Hallvard raises some interesting issues. One is the question of formal,
          rigorous modeling languages vs. informal, non-rigorous modeling schemes and
          notations.The former may be of great importance to the advancement of
          academic research, but I confess to having only limited interest in highly
          formal methods and models myself because they are of little value to the
          everyday practitioner designing complex user interfaces in the real world
          under great time-pressure. We long ago learned that a certain amount of
          "studied sloppiness" is of great value in advancing quickly toward sound
          designs. Moreover, the vast majority of practicing designers, the people we
          work with and train in improved methods, are of a similar mind and are not
          in a position to make use of rigorous, formal, mathematically and
          linguistically pure modeling schemes. The core models of usage-centered
          design--user roles, essential use cases, and abstract prototypes--have been
          deliberately tuned over many, many applications to walk the fine line
          between systematic structure and flexible informality that best fits with
          doing real design. They are, in this sense, far more formal than scenario
          storyboards but far short of a rigorous GOMS-style hierarchical goal
          decomposition. We are interested in what works, in practice, and in
          elevating the level of practice of the vast majority of developers out
          there in need of better intellectual leverage in solving real problems.

          I would have hoped that the discussion made clear that our work is not
          based on such "a weak notation as UML," but rather thatwe see the
          possiblility of merging or connecting usage-centered design with UML,
          which, whatever its limitations and weaknesses, is a standard widely
          employed in software engineeering.

          As a moderator of this forum, I am going to say that personalized remarks
          that imply incompetence are inappropriate among professional colleagues. I
          refer specifically to the remark "someone presenting a method based on such
          a weak notation as special and wonderful, must have a very simplified view
          of user interface design (If this is all there is to it, it would have been
          discovered long time ago." The first part of this warrants no further
          comment. As to the latter, there are many simple ideas that, once
          "discovered" seem obvious.

          The charge of sloppy scholarship is, I feel, particularly unfair. One piece
          of early work was mentioned with which I was unfamiliar and which I
          immediately tracked down and read. It is relevant and connected to our
          work, but so are many things. In particular, it does not really anticipate
          the notion of "essential" intention-based, abstract narratives in use cases
          which is the core concept in usage-centered design. I am always eager to
          hear of other work that may be useful and relevant. I would, of course,
          like to be familiar with everything relevant to everything with which I am
          involved, but, with the vast literature in both software engineering and
          user interface design, that is a daunting task for a full-time academic and
          an impossible task one for someone like myself who designs real-world
          solutions for a living. (Nevertheless, one will find many hundreds of
          citations into the literature in both software engineering and CHI in our
          book, and rest assured, a future addtition will incorporate additional
          references.) (The other work mentioned was from last year's CHI
          proceedings, which, I am embarrassed to say, I had not yet read because of
          my heavy travel schedule. It was an exciting demonstration of an idea that
          I first proposed 10 years ago, so, needless to say, I was grateful to hear
          about it.)

          I do apologize if I seemed "sales oriented" in Pittsburgh. My enthusiasm
          does take over at times. We are excited about the results obtained by
          everyday industrial and business-oriented designers who have been applying
          usage-centered design over a wide range of problems at varying scales. This
          was our first oppoirtunity to share this topic with the CHI audience. We
          are also excited that our book is finally published after nearly 6 years in
          the making. SInce many people have been asking about it for a long time, I
          thought it only reasonable to let people know it was available.

          --Larry L. Constantine
          Director of Research & Development
          Constantine & Lockwood, Ltd.
          58 Kathleen Circle | Rowley, MA 01969 USA
          t: +1 978 948 5012; f: +1 978 948 5036 | http://www.foruse.com

          ------------------------------------------------------------------------

          eGroups.com home: http://www.egroups.com/group/usage-centered
          http://www.egroups.com - Simplifying group communications
        • Hallvard Trætteberg
          Larry, First I would like to apologize for my aggressive tone and personalized remark . As a veteran user interface designer and designer of methods, I m sure
          Message 4 of 9 , Jun 24, 1999
          • 0 Attachment
            Larry,

            First I would like to apologize for my aggressive tone and "personalized
            remark".
            As a veteran user interface designer and designer of methods, I'm sure you
            have taken qualified decisions with respect to formality, notation and
            found what
            you consider the "fine line between systematic structure and flexible
            informality".
            I'm sure I have a lot to learn from you, but that requires something
            different than
            what I got at CHI'99. To me that was evangelism, not an explanation or
            justification
            for how your method is better suited to industry than other, more formal
            methods.
            I we could discuss that in this forum, that would be very, very nice. I
            hope you will
            give me that chance, dispite my initial message.

            >[] the question of formal, rigorous modeling languages vs. informal,
            >non-rigorous modeling schemes and notations.The former [] are of
            >little value to the everyday practitioner designing complex user interfaces
            >in the real world under great time-pressure. We long ago learned that a
            certain
            >amount of "studied sloppiness" is of great value in advancing quickly
            toward sound
            >designs.

            Again, I'm sure you're right, but I also believe there are advantages to
            more formal
            modeling, that we should try to gain. Being informal and "sloppy" in early
            design
            does not mean you can't be formal later, if something can be gained. There are
            actually (at least) three dimensions to this, structure, formality and
            completeness.
            In the end, in the implementation you will have to be both formal and
            complete.
            I believe your method has structure and is perhaps more complete and formal
            than
            you present it as. I would not be too difficult to make a meta model of
            your notation and
            forms (cards?), However, it would be more difficult to make tools make
            constructive use
            of the notation, besides supporting editing. Correct me if I'm wrong.

            Personally, I've come to the conclusion that although formality may aid
            human-human
            communication, the potential is within developer-machine communication.
            Apart from
            code-generation from concrete or slightly abstract design models, I'm
            thinking of
            supporting the transition from tasks to dialog design, partly through
            formal reasoning, and
            partly through the use of design patterns.

            Suppose you express that taskA always is followed by taskB. Before this has
            been
            expressed explicitly, you for one thing can't question it! There may be
            reasons for
            the sequence, that are important to find, or it may be a habit that you can
            gain from
            getting rid of, given the right user interface. When designing the dialog
            for taskA and
            taskB, it does make sense for dialogA to trigger dialogB. Within a formal
            framework,
            a tool could at least prove the consistency between the dialog and tasks,
            i.e. that
            the dialog does support the tasks. However, there are limits to what can be
            proven and
            what is interesting to prove. An alternative is a design pattern based
            approach.

            Simply put, design patterns are a way of relating problem structure with
            design structures,
            which in our domain amounts to task model fragments and dialog design
            fragments.
            Design patterns do not require a mathematical basis, they only require a
            notation for
            the important structural properties of both specification and design (tasks
            and dialog).
            And if you want a computerized tool as an aid, the notation should be
            formal enough
            for matching of patterns.

            One of the important questions is: How can we design a notation that does not
            hinder creativeness and speed in development, but still let us express things
            that tools can use to support our design process.

            >The core models of usage-centered design--user roles, essential use cases,
            and
            >abstract prototypes--have been deliberately tuned over many, many
            applications
            >to walk the fine line between systematic structure and flexible
            informality that best fits
            >with doing real design.

            Could you perhaps say something about what kind of formal stuff you have
            discarded?

            >As to the latter, there are many simple ideas that, once "discovered" seem
            obvious.

            I still have problems understanding what is "discovered", but I guess I
            can't expect
            to find the one crucial element of a fine tuned method.

            >In particular, it does not really anticipate the notion of "essential"
            intention-based,
            >abstract narratives in use cases which is the core concept in
            usage-centered design.

            This part is interesting. At our workshop in tools for task based user
            interface design,
            we discussed a lot what should be in the task model and what was part of
            the dialog
            model. Your way of abstracting the use case, to get rid of premature design
            decisions,
            is similar to my personal views of how to find the border between task
            design and
            dialog design. Perhaps you could elaborate on that?

            >We are also excited that our book is finally published after nearly 6
            years in
            >the making. Since many people have been asking about it for a long time, I
            >thought it only reasonable to let people know it was available.

            I've just started pursuing my interest in user interface design patterns,
            and a book
            such as yours may be a good starting point, since at least some of us
            academics
            are concerned with industrial needs and not just mathematical purity :-)

            BTW, I have some of the material on model based user interface design
            available
            at http://www.idi.ntnu.no/~hal/ui-modeling/ as a four part pdf-document. I
            have
            presented the same material for two big consultancy firms and they do seem
            interested in a model based approach. Please have a look and give me your
            opinion!

            Hallvard

            Hallvard Trætteberg,
            Stipendiat ved Institutt for Datateknikk og Informasjonsvitenskap (IDI)
            Fakultet for Fysikk, Informatikk og Matematikk (FIM)
            Norges Teknisk-Naturvitenskapelige Universitet (NTNU)
            Kontor: F-262, Nye Elektro, Tlf: +47 7359 3443, Fax: +47 7359 4466

            ------------------------------------------------------------------------

            eGroups.com home: http://www.egroups.com/group/usage-centered
            http://www.egroups.com - Simplifying group communications
          • Larry Constantine
            I am glad to see the dialog continuing rather than grinding to a halt. Thanks for the open response. ... You are absolutely justified in your dissapointment,
            Message 5 of 9 , Jun 24, 1999
            • 0 Attachment
              I am glad to see the dialog continuing rather than grinding to a halt.
              Thanks for the open response.

              >that requires something
              >different than
              >what I got at CHI'99. To me that was evangelism, not an explanation or
              >justification
              >for how your method is better suited to industry than other, more formal
              >methods.

              You are absolutely justified in your dissapointment, because the CHI'99
              session was a Special Interest Group, a forum for sharing, not a formal
              presentation and certainly not a complete explanation or comparison. At the
              moment, I can only refer people who want to understand the complete
              approach to the book. No 90 minute forum could do justice to the whole.

              In our view, the need for precision, rigor, and formality increases as you
              approach implementation. The final form of the user interface design that
              becomes input to the programming process--what we refer to as the
              "implementation model"--must not only specifiy precisely what visual
              components need to be present in what layout, but also their exact
              behavior. For example, the time lag on automatic actions, such as cascading
              tool tips, must be just right or usability is impaired. We are in complete
              agreement that where the greatest formality and absolute completeness
              becomes most important is in the design and development of the supporting
              internal software architecture, which is why we have suggested that
              elaborated concrete use cases are the preferred input to internal software
              engineering. Usage-centered design was never intended to address all
              problems in software engineering and development; we were only interested
              in increasing the leverage for designing sound user interface architectures
              for enhanced usability. That is a big enough problem. Let the folks at
              Rational try to solve all problems for all people.

              As you might expect, I agree that a meta-model for the usage-centered
              design extensions would not be that difficult to devise, although there are
              some subtleties that require careful thinking. That effort is currently
              underway. Regarding tool support, there is a great deal that can be done
              that goes far beyond mere editing. I cannot go into details without
              compromising some proprietary efforts, but good CASE tool support for
              usage-centered design would interconnect all models so that the connections
              between particular use cases, the roles they support, and their realization
              in the abstract prototype and implementation model can be tracked and
              reviewed with single-click access. A good tool could include discretionary
              consistency checking on vocabulary, automatic generation of initial
              versions of some models (for example, a trial content model from each use
              case), etc.

              There are other aspects of the process as practiced that could be
              dramatically improved with CASE tool support. For example, currently,
              collaborative usability inspections are conducted as a discrete activity
              that must be manually related back to the work-in-progress. If the
              inspection recording and record were also part of the CASE tool, the
              connection with the visual elements and specific use cases would be
              maintained automatically, vastly simplifying both redesign and defect
              tracking. And the list goes on...

              >One of the important questions is: How can we design a notation that does
              not
              >hinder creativeness and speed in development, but still let us express
              things
              >that tools can use to support our design process.

              Of course, that is precisely what we have tried to do with the models of
              usage-centered design for the limited domain of visual and interaction
              design.

              As I have argued for more than a decade that, ultimately, the modeling
              tools must be fully integrated with the visual development environment so
              that code, implemented interface, and models are all merely synchronized
              alternative views into a project. The ability to move smoothly and
              instantly between modes of expression and views of the evolving design is
              the ideal support for rapid, creative, collaborative problem solving. The
              more precise models (state models, class hierarchies, etc.) needed to
              facilitate programming are linked directly to the more informal design
              models with which they are related as well as to documentation and help
              models.

              As to design patterns, these are an important and effective tool to help
              engineers in many areas. The efforts to devise useful design patterns for
              user interface design have not, thus far, produced results anywhere near as
              useful or as powerful as in object-oriented software engineering. Frankly,
              I think the problem is that we do not collectively have enough cumulative
              experience in structured, systematic user interface design as a basis for
              capturing accumulated wisdom in the form of patterns. Too much UI design
              has been art, magic, iterative hacking, or GOMS analysis. I would applaud
              efforts to compile a useful catalog of design patterns for usage-centered
              design, but I just haven't had the time to pursue it myself.

              --Larry Constantine

              ------------------------------------------------------------------------

              eGroups.com home: http://www.egroups.com/group/usage-centered
              http://www.egroups.com - Simplifying group communications
            • Hallvard Trætteberg
              ... cumulative ... However, many aspects of the resulting user interfaces are similar. For what reason: At a structural level, many domains are similar. E.g.
              Message 6 of 9 , Jun 25, 1999
              • 0 Attachment
                At 19:49 24.06.99 -0400, you wrote:
                >Frankly, I think the problem is that we do not collectively have enough
                cumulative
                >experience in structured, systematic user interface design as a basis for
                >capturing accumulated wisdom in the form of patterns. Too much UI design
                >has been art, magic, iterative hacking, or GOMS analysis.

                However, many aspects of the resulting user interfaces are similar. For
                what reason:
                At a structural level, many domains are similar. E.g. object hierarchies
                are common,
                and the interface solution, a twist-down tree, is also common. Similarly,
                many tasks
                are supported by the same mechanisms, menu commands of various kinds,
                drag-drop
                interaction etc, because many tasks are structurally similar.

                If you look at languages for modeling the static part of the domain, there
                is a stong
                consensus on the basic primitives: concept, attribute and relation
                (is-a, part-of, association). And consciously or unconsciously, structures
                of these
                primitives are mapped to the same small set of user interface structures.
                However,
                since there is less/no consensus on how to model the user interface, it is
                difficult to
                model these design patterns. Similarly, there is no agreed-upon task modelling
                language, hence the relation between tasks/task structures and interaction
                design
                is difficult to formulate. Until we have the needed languages for
                formulating design
                patterns, the knowledge will remain tacid. This is different from believing
                that the
                knowledge isn't there. If we can agree this is a language problem, it is
                easier to
                pursue.

                Comments?

                Hallvard

                Hallvard Trætteberg,
                Stipendiat ved Institutt for Datateknikk og Informasjonsvitenskap (IDI)
                Fakultet for Fysikk, Informatikk og Matematikk (FIM)
                Norges Teknisk-Naturvitenskapelige Universitet (NTNU)
                Kontor: F-262, Nye Elektro, Tlf: +47 7359 3443, Fax: +47 7359 4466

                ------------------------------------------------------------------------

                eGroups.com home: http://www.egroups.com/group/usage-centered
                http://www.egroups.com - Simplifying group communications
              • Martijn van Welie
                Hi, First of all let me introduce myself. My name is Martijn van Welie and I am a PhD student at the Vrije Universiteit of Amsterdam. My research is concerned
                Message 7 of 9 , Jun 25, 1999
                • 0 Attachment
                  Hi,

                  First of all let me introduce myself. My name is Martijn van Welie and I
                  am a PhD student at the Vrije Universiteit of Amsterdam.
                  My research is concerned with task based user interface design with a
                  focus on tools that support it. I have built a tool
                  called Euterpe that supports task analysis and we are looking at
                  extenstions for dialog modeling. I have no idea how I got
                  on this mailing list but it is getting interesting .... ( I probably
                  signed something and forgot all about it)

                  At CHI99 I also was at the workshop on Tools for Task Based Design and I
                  also attended Constantine's SIG.
                  I more or less share Hallvard's thoughts and we have already had some
                  discussion about it We discussed
                  the use of UML and how it would help user centred design. Two questions
                  still puzzle me;

                  - What is the difference between a scenario and a use case diagram?
                  I asked this question to several people but sofar there doesn't seem to
                  be a clear answer. When reading
                  the UML definition of a use case diagram, one could argue that a
                  scenario is the same thing BUT also
                  that it is something different. Personally I think it is basically the
                  same thing.

                  - How does UML help in user/usage centered design?
                  As far as I can see the only thing that is part of UML that has any
                  relationship with users, it is the use case diagram.
                  However, the use case diagram is a ratherly poorly defined. Larry
                  Constantine showed his improvements at the
                  SIG at CHI which illustrates my point. So where does task modeling, user
                  modeling, usage of guidelines and
                  design patterns come in (not to speak of usability evaluation, user
                  surveys etc) ?

                  Another point is the issue of tools to support user centered design.
                  Conceptually it is not that difficult to imagine
                  what kind of tools could be useful. Pragmatically it is more difficult.
                  Tools that support such as design process need
                  to be based on explicit models that have been semantically linked.
                  Otherwise you'll never get beyond a graphical
                  diagram editor. This means that as long as we cannot come up with the
                  right models that are semantically linked
                  (for instance using meta-models) tools are doomed to be unsuccesful
                  (apart from being just editors).
                  In my opinion we have not reached enough agreement on the models and
                  representations we need in order
                  to do this "integration". So this is the area where the "studied
                  sloppiness" needs to be formalized more.

                  Regards,

                  Martijn van Welie

                  ------------------------------------------------------------------------

                  eGroups.com home: http://www.egroups.com/group/usage-centered
                  http://www.egroups.com - Simplifying group communications
                • daveroberts@uk.ibm.com
                  ... and I ... That s how you got on the list. ... I store fragments of scenarios in use cases when I am collating the input for a design. I also tend to add a
                  Message 8 of 9 , Aug 3, 1999
                  • 0 Attachment
                    > At CHI99 I also was at the workshop on Tools for Task Based Design
                    and I
                    > also attended Constantine's SIG.
                    That's how you got on the list.

                    > - What is the difference between a scenario and a use case diagram?
                    I store fragments of scenarios in use cases when I am collating the
                    input for a design. I also tend to add a sequence diagram (which plays
                    the same role as Constantine's "essential use case".

                    > - How does UML help in user/usage centered design?
                    I don't think UML itself is the key. I think the team agreeing on a
                    common language is what matters. I have seen so many projects where
                    the different disciplines on a team did not communicate.

                    I use UML as that common language. Our work is reported on our web
                    site in the Design section of www.ibm.com/easy. We call our method
                    OVID.

                    You might also like to look at the WISDOM workshop at ECOOP99 which was
                    on this topic.

                    > Another point is the issue of tools to support user centered design.
                    I have always been entirely pragmatic on this. I find a tool that does
                    most of what I need and adapt the method to fit within the tool. It
                    doesn't always give exactly what you want. However, as CASE tools are
                    very often tuned (at least partly) to team working and communication
                    then they form a good backbone.

                    I am currently using Rational Rose to hold all our information but we
                    are investigating the new version of Visio. I am also searching for
                    tools to help more in the front end than the Use Case facilities in
                    Rose do.

                    Dave Roberts
                    Ease of Use
                    IBM
                  • Larry Constantine
                    ... We have been striving for a simple, consistent terminology that respects precedent and continuity with prevailing usage but clarifies important
                    Message 9 of 9 , Aug 3, 1999
                    • 0 Attachment
                      >> - What is the difference between a scenario and a use case diagram?

                      We have been striving for a simple, consistent terminology that respects
                      precedent and continuity with prevailing usage but clarifies important
                      distinctions. Particularly important from the standpoint of communication
                      is the distinction between scenarios and use cases. As most often used and
                      certainly as deducible from examples, a scenario typically comprises a
                      plausible combination of use cases in their enacted (concrete,
                      instantiated) form. Any use of the term scenario as an a substitute for use
                      case conflates two distinct constructs and is unnecessary obfuscation.
                      Similarly, we avoid using the term scenario to refer to the process ("flow
                      of events," narrative, or body) of a use case.

                      scenario: a plausible vignette or story line composed of the enacted or
                      instantiated form of one or more use cases and describing the interaction
                      between a user (in some one or more roles) and a system as a detailed
                      sequence of concrete events or processes; a scenario may be set within and
                      describe aspects of the environment or larger context within which the
                      interaction takes place, including the involvement of other actors and
                      systems.

                      The "use case diagram" in UML/UP models the relationships between use cases
                      and actors and among use cases. We refer to it as the "use case map," which
                      is more specific and informative.

                      >> - How does UML help in user/usage centered design?
                      >I don't think UML itself is the key. I think the team agreeing on a
                      >common language is what matters. I have seen so many projects where
                      >the different disciplines on a team did not communicate.

                      We (Lucy Lockwood and I) agree. The notation is less important than the
                      common agreement that facilitates communication. It might as well be UML
                      because it is standard (even if flawed from a human factors standpoint).
                      The extensions to UML to cover usage-centered design are currently being
                      refined.

                      >> Another point is the issue of tools to support user centered design.

                      Have hope, help is on the way. Moderator Jason Robbins has pledged to
                      extend ArgoUML to cover usage-centered design and other projects are under
                      way.
                    Your message has been successfully submitted and would be delivered to recipients shortly.