The list has been quiet for awhile, so here is a discussion topic to,
hopefully, stir up the pot.

I have been working on a large project to replace a number of disparate
systems supporting a financial services business with an off-the-shelf
product, which will act as a system of record, a batch processor and a call
center UI.
Our first step was to discover and document "the world" as it is today,
since there was no coherent business domain documentation.  We accomplished
it by creating a business use case model to describe existing business
processes.  (We're using Rational Rose for modeling activities.)
After that we went through the business model and identify required
actor-system interactions and created system use cases.
The next task to elaborate system use cases, and here're the questions.

1.  It seems that all essential use case examples that I've seen describe
the main path of interaction, leaving out alternative and exception paths.
I'm reluctant to use extension use cases to capture other paths for the fear
of making the model unreadable.  Is there a better way?

2.  As we're elaborating use cases with our users, much of business logic,
procedural and legal constraints will come out.  They must be captured.  In
the past I used activity diagrams to map out logic behind system
responsibilities.  Is anybody doing something different?

3.  Recently I have re-read the book that started it all "Usage Centered
Design..." and it made me wonder if I overloaded the essential use case
narrative with my modified template (attached) too much.  The information
that I added is useful, but it does make each use case a bit heavier.  Any
suggestions?

I hope these questions are relevant to all and will spur good discussion.

Best,

Kiril Okun
CapitalOne - CRS
208-472-6323
kiril.okun@...








**************************************************************************
The information transmitted herewith is sensitive information intended only
for use by the individual or entity to which it is addressed. If the reader
of this message is not the intended recipient, you are hereby notified that
any review, retransmission, dissemination, distribution, copying or other
use of, or taking of any action in reliance upon this information is
strictly prohibited. If you have received this communication in error,
please contact the sender and delete the material from your computer.

Kiril,

Thanks for opening up some important issues with your questions.

> I have been working on a large project to replace a number of disparate
> systems supporting a financial services business with an off-the-shelf
> product, which will act as a system of record, a batch processor
> and a call
> center UI.
> Our first step was to discover and document "the world" as it is today,
> since there was no coherent business domain documentation.  We
> accomplished
> it by creating a business use case model to describe existing business
> processes.  (We're using Rational Rose for modeling activities.)
> After that we went through the business model and identify required
> actor-system interactions and created system use cases.
> The next task to elaborate system use cases, and here're the questions.
>
> 1.  It seems that all essential use case examples that I've seen describe
> the main path of interaction, leaving out alternative and exception paths.
> I'm reluctant to use extension use cases to capture other paths
> for the fear
> of making the model unreadable.  Is there a better way?

Keeping the essential narrative to the main flow or "success case" is so
widely practiced because that's what usually works best for so many
purposes, but especially for guiding interaction design and user interface
design. This practice keeps the design focused on essentials and leads to
cleaner interactions. However, the alternatives and exceptions ultimately
need to be modeled and handled somewhere. We expand these as extension use
cases whenever the extension cases make sense in and of themselves and are
of use (or potential use) elsewhere, that is in other use cases. If not, we
follow Alistair Cockburn's suggestion, and describe them as internal
extensions or "footnotes" within the base use case.

The real point is embodied in Constantine's Third Law: "Complexity, though
easily created, cannot be eliminated but can only be hidden or moved from
one place to another." Putting exceptions in separate use cases does not
make the model any more complex or unreadable, it just moves the complexity
from one place to another. Either you have fewer but messier use cases or
you have more but cleaner ones. Experienced modelers try to strike a
balance, such as that suggested by the best practices just described.

Ideally, we would like to see the software tools recognize this problem and
incorporate structured use cases so that, at a click of a button or link,
one could trace all the external extensions, see them on one page as if they
were internal, or extract internal extensions into external extension cases.
We keep trying to get the tool vendors to listen.

> 2.  As we're elaborating use cases with our users, much of business logic,
> procedural and legal constraints will come out.  They must be
> captured.  In
> the past I used activity diagrams to map out logic behind system
> responsibilities.  Is anybody doing something different?

Following Ellen Gottesdiener's recommendations, we capture and retain
business rules in a separate model that is cross-linked to the essential use
cases. The use cases contain references to applicable business rules, and
each rule refers to the use cases affected. Putting them inside use cases is
an invitation to mistakes and maintenance headaches.

> 3.  Recently I have re-read the book that started it all "Usage Centered
> Design..." and it made me wonder if I overloaded the essential use case
> narrative with my modified template (attached) too much.  The information
> that I added is useful, but it does make each use case a bit heavier.  Any
> suggestions?

The template looks very thorough and well thought out, but, as you say, it
has been weighted down some. We have always been hesitant to try and put too
much into any one model. Independent but cross-linked models are generally
better. One consequence of cramming so much into the use case narrative is a
great deal of redundancy and wordiness. We would address stakeholder issues
at the system/context level, but rarely if ever at the use case level, as
any significant impact on the task model is typically carried through by way
of the role/actor model. I would also have reservations about some sections.
For example, inclusion of "triggers" and "implementation notes" violates
essential modeling.

One danger of such heavily loaded models is that they promote a kind of
obsessive-compulsive approach to box-filling. The modeling drags out into an
exercise in tedium within which an appreciation for the forest gets lost in
the recording of every leaf on every tree. This becomes a variant disease of
the old analysis paralysis.

The Extreme Programmers have an expression, YAGNI ("You ain't going to need
it.") that applies. In our experience, much of the time all the stuff that
gets stuffed into bloated use cases never gets read or used in any any
meaningful way. We strongly favor the cleanest, simplest use case model that
supports good visual and interaction design, with elaboration only later and
as necessary. In the YAGNI spirit, for example, most of the "future
improvements" and "implementation notes" that one could write when doing the
task modeling will most likely prove to be wrong headed or outright wrong
once the system is being built or actually being used.

Another danger is that modelers get so worn down by the implicit
requirements of documenting so much, that they start just ignoring or
skipping over all the extra stuff, which can lead to a false sense of
security about what is or is not in the model. If it takes a lot to write
such stuff, it also takes a lot to understand it. In addition, all that
information has to be maintained, which it will almost certainly not be.
Often, where highly elaborate use cases have been developed initially, very
quickly much of the contents becomes obsolete or even wrong, so they are, in
effect, discarded after one use. Much more streamlined use cases are more
apt to remain valid or to be maintained as the project continues and the
application evolves.

That said, the direction your template takes might be justified in some very
large projects with many participants and an external or business need (or
mandate) for highly structured, systematic process. In that context, I could
myself argue in favor of almost everything you have added, and even add a
few more things myself. However, in many cases, YAGNI rules. For my part, I
would still do most or all of my initial modeling on index cards and leave
the box-filling to someone with the stomach and talent for it.

I hope to see you at forUSE 2002 in August (www.forUSE.com/2002/).

BTW, would you have any objection to our posting your comprehensive use case
template on our Web site? Others in similar circumstances might find it
useful.

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

I've been programming for a living for around 26 years now.  I learned to
program 38 years ago in abstract machine language ( no computer to run it on). 
Most recently (last 10 years or so), I've been doing object oriented programming
in C++.  The majority of what I've been doing has only had error messages for a
user interface, with a few exceptions.  What little GUI work I've done has been
with Borland, MS VC++, and MS VB.  It has all been by following the examples of
what I've seen, and hasn't been desingned at all.

Since I value design very highly in building classes in C++, I was very glad to
run across _Software_for_Use_ by Constantine & Lockwood (refered from the Bruce
Eckel's site, by the way).  Since I have some of Constantine's structured
programming books in my library, I ordered it without looking, feeling confident
it would be a good reference book, at the very least.

I'm currently up to chapter 10, and spending as much time reading as I can.  I
hope there are a few people still reading/using this group, as I believe I'll
have a fair number of questions.

We're here, just kinda quiet recently.
For some of us, it's been crunch time; others just quietly working.
I think of this list as I do my longtime friends; sometimes you go
for a while without seeing each other or talking much, but they're
always there when you have a cool idea or a project to share, need
someone to talk to about usage-center design, or need help or have a
question, etc.

Personally, I think you won't find a more insightful group of
professionals or a better interaction design method than Usage-
Centered Design, and we'd enjoy hearing from you.
In addition to Larry and Lucy's book, I'd encourage you to go to
their website at www.ForUse.com. They've got a lot of additional
resources, like case studies, downloadable templates, and even
contributions from the U-CD community, just to name a few.
While you're there, check out the training opportunities and the
upcoming conference schedule. Even though I was an accomplished
Interaction Designer (professionally recognized and with over 17
years of successful industrial development experience) I took the 5-
day U-CD training course and came away with so much more! Beyond the
materials and training, I felt Larry and Lucy took the time to get to
know the attendees so that they could push and stretch us in the
areas we needed it most. I'd really recommend it.

Finally, I'm curious... you said that "the majority of what I've been
doing has only had error messages for a user interface". What type of
systems were these? (I've spent a fair amount of time working with
embedded systems, and sometimes the situation was similar to what you
describe.)

Best Regards,
David W. Schofield
dschofield at DesignedForUse dot com
www.DesignedForUse.com

> but I have no idea of how to design user interfaces.
> Or even what makes a good interface vs. a bad one.

At least you are aware of this! So many user interfaces
are designed by folks who have no clue about what makes
a good UI, resulting in mountains of almost unusable
programs. As Socrates said, understanding the level
of your ignorance is the best kind of knowledge.

One of the core tenets of UsageCD is teaching good
engineers to be good UI designers, allowing them to
use the logical, stepwise thinking process that
they use to design great code to also design great
UIs. So the book, this group, and the web site should
prove to be a fantastic resource for you.

..tony..

Larry,
thank you for your thoughtful reply.  I will bring up these points with my
compatriots.
Please, feel free to post this template.  It was mostly based on your
original template with additions from Cockburn's book and our specific
project requirements.

The conference looks very interesting, and I will do my best to make it.

Truly yours,

Kiril Okun
Capital One - CRS
208-472-6323

-----Original Message-----
From: Larry Constantine [mailto:lConstantine@...]
Sent: Thursday, April 18, 2002 1:27 PM
To: usage-centered@yahoogroups.com
Cc: Okun, Kiril
Subject: RE: [usage-centered] Capturing alternative paths, exceptions
and business logic.


Kiril,

Thanks for opening up some important issues with your questions.

> I have been working on a large project to replace a number of disparate
> systems supporting a financial services business with an off-the-shelf
> product, which will act as a system of record, a batch processor
> and a call
> center UI.
> Our first step was to discover and document "the world" as it is today,
> since there was no coherent business domain documentation.  We
> accomplished
> it by creating a business use case model to describe existing business
> processes.  (We're using Rational Rose for modeling activities.)
> After that we went through the business model and identify required
> actor-system interactions and created system use cases.
> The next task to elaborate system use cases, and here're the questions.
>
> 1.  It seems that all essential use case examples that I've seen describe
> the main path of interaction, leaving out alternative and exception paths.
> I'm reluctant to use extension use cases to capture other paths
> for the fear
> of making the model unreadable.  Is there a better way?

Keeping the essential narrative to the main flow or "success case" is so
widely practiced because that's what usually works best for so many
purposes, but especially for guiding interaction design and user interface
design. This practice keeps the design focused on essentials and leads to
cleaner interactions. However, the alternatives and exceptions ultimately
need to be modeled and handled somewhere. We expand these as extension use
cases whenever the extension cases make sense in and of themselves and are
of use (or potential use) elsewhere, that is in other use cases. If not, we
follow Alistair Cockburn's suggestion, and describe them as internal
extensions or "footnotes" within the base use case.

The real point is embodied in Constantine's Third Law: "Complexity, though
easily created, cannot be eliminated but can only be hidden or moved from
one place to another." Putting exceptions in separate use cases does not
make the model any more complex or unreadable, it just moves the complexity
from one place to another. Either you have fewer but messier use cases or
you have more but cleaner ones. Experienced modelers try to strike a
balance, such as that suggested by the best practices just described.

Ideally, we would like to see the software tools recognize this problem and
incorporate structured use cases so that, at a click of a button or link,
one could trace all the external extensions, see them on one page as if they
were internal, or extract internal extensions into external extension cases.
We keep trying to get the tool vendors to listen.

> 2.  As we're elaborating use cases with our users, much of business logic,
> procedural and legal constraints will come out.  They must be
> captured.  In
> the past I used activity diagrams to map out logic behind system
> responsibilities.  Is anybody doing something different?

Following Ellen Gottesdiener's recommendations, we capture and retain
business rules in a separate model that is cross-linked to the essential use
cases. The use cases contain references to applicable business rules, and
each rule refers to the use cases affected. Putting them inside use cases is
an invitation to mistakes and maintenance headaches.

> 3.  Recently I have re-read the book that started it all "Usage Centered
> Design..." and it made me wonder if I overloaded the essential use case
> narrative with my modified template (attached) too much.  The information
> that I added is useful, but it does make each use case a bit heavier.  Any
> suggestions?

The template looks very thorough and well thought out, but, as you say, it
has been weighted down some. We have always been hesitant to try and put too
much into any one model. Independent but cross-linked models are generally
better. One consequence of cramming so much into the use case narrative is a
great deal of redundancy and wordiness. We would address stakeholder issues
at the system/context level, but rarely if ever at the use case level, as
any significant impact on the task model is typically carried through by way
of the role/actor model. I would also have reservations about some sections.
For example, inclusion of "triggers" and "implementation notes" violates
essential modeling.

One danger of such heavily loaded models is that they promote a kind of
obsessive-compulsive approach to box-filling. The modeling drags out into an
exercise in tedium within which an appreciation for the forest gets lost in
the recording of every leaf on every tree. This becomes a variant disease of
the old analysis paralysis.

The Extreme Programmers have an expression, YAGNI ("You ain't going to need
it.") that applies. In our experience, much of the time all the stuff that
gets stuffed into bloated use cases never gets read or used in any any
meaningful way. We strongly favor the cleanest, simplest use case model that
supports good visual and interaction design, with elaboration only later and
as necessary. In the YAGNI spirit, for example, most of the "future
improvements" and "implementation notes" that one could write when doing the
task modeling will most likely prove to be wrong headed or outright wrong
once the system is being built or actually being used.

Another danger is that modelers get so worn down by the implicit
requirements of documenting so much, that they start just ignoring or
skipping over all the extra stuff, which can lead to a false sense of
security about what is or is not in the model. If it takes a lot to write
such stuff, it also takes a lot to understand it. In addition, all that
information has to be maintained, which it will almost certainly not be.
Often, where highly elaborate use cases have been developed initially, very
quickly much of the contents becomes obsolete or even wrong, so they are, in
effect, discarded after one use. Much more streamlined use cases are more
apt to remain valid or to be maintained as the project continues and the
application evolves.

That said, the direction your template takes might be justified in some very
large projects with many participants and an external or business need (or
mandate) for highly structured, systematic process. In that context, I could
myself argue in favor of almost everything you have added, and even add a
few more things myself. However, in many cases, YAGNI rules. For my part, I
would still do most or all of my initial modeling on index cards and leave
the box-filling to someone with the stomach and talent for it.

I hope to see you at forUSE 2002 in August (www.forUSE.com/2002/).

BTW, would you have any objection to our posting your comprehensive use case
template on our Web site? Others in similar circumstances might find it
useful.

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







Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/


**************************************************************************
The information transmitted herewith is sensitive information intended only
for use by the individual or entity to which it is addressed. If the reader
of this message is not the intended recipient, you are hereby notified that
any review, retransmission, dissemination, distribution, copying or other
use of, or taking of any action in reliance upon this information is
strictly prohibited. If you have received this communication in error,
please contact the sender and delete the material from your computer.

I've just finished my initial reading of _Software_for_Use_, and I have a question about usage centered design and batch processes.  By batch processes, I mean a process which is intended to run with minimal human interaction.  For example, in an airline revenue accounting system I worked on, there were a great number of file feeds, which needed to be moved into the relational database on a regular basis, but we wanted it to be as automated as possible.

A typical example was getting fare information.  About once a day, a scheduling system started a shell script which would FTP a file from a fare clearing house.  It would validate the files received (by checksum), and enter  the file name into a database table for processing.  Later on in the evening, a progrom would be started that would check the database table for unprocessed entries.  The file would then be processed moving the flat file into a set of fare tables.

The primary human interaction was with the operators, who would receive detailed error messages if the process failed at any point.  Some where fairly simple, on the order of "Connection to remote site could not be established, please check network connectivity by ..."; some printed out several pages of detailed analysis of possible problems in order of probable causes.  Most of those messages were stored in the database, and regular reviews modified them to keep them current, with feedback from the operators on useful they were on resolving problems, or how easy they were to understand.

Finally, each fare was subject to validation.  Each transcaction was validated.  Any that failed validation had entries created into an error work queue.  The work queues were processed by a seperate process, which was interactive, but all the batch job did was add entries to work queue.

The only real role I can see is the operator, and, under most conditions, there were no interactions with the operator.  I can remember at least one period where the fare loading process ran for 4 months without operator intervention, which was our main goal for this process.

So how do you tackle this sort of process from a usage centered design process?

Stanley,

Yes, this is a bit of a slow response, but between the relaunch of
forUse.com (http://foruse.com/) and putting together the program for the
upcoming forUSE 2002 conference (http://foruse.com/2002/), things have been
crazy.

I once had a guy come up to me after one of my classes in usage-centered
design for embedded systems applications. He asked how the techniques
applied to the world of UPS design in which he worked. I asked him about the
UI of his last project and he said, "Well, there was a power switch an LED,
and an audio alarm. The truth is, some applications--such as your batch
processes--have inherently minimal user interfaces. For these,
usage-centered design itself won't buy you much. That is not to say that
usability issues shouldn't be considered in the design of log-on procedures
or error messages, but the ROI of doing a full-blown user role and task
modeling is likely to be limited.

However, there are those who are convinced that abstract (essential) use
cases are still valuable for driving the object design process. See the
Noble et al. paper on this
(http://foruse.com/articles/euc-responsibility.htm).

Regards,

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

-----Original Message-----
From:
sentto-1175705-106-1019926079-lConstantine=compuserve.com@...
oo.com
[mailto:sentto-1175705-106-1019926079-lConstantine=compuserve.com@...
oups.yahoo.com]On Behalf Of Stanley Sutton
Sent: 27 April 2002 12:49 PM
To: usage-centered@yahoogroups.com
Subject: [usage-centered] usage-centered design of batch processes?


I've just finished my initial reading of _Software_for_Use_, and I have a
question about usage centered design and batch processes.  By batch
processes, I mean a process which is intended to run with minimal human
interaction.  For example, in an airline revenue accounting system I worked
on, there were a great number of file feeds, which needed to be moved into
the relational database on a regular basis, but we wanted it to be as
automated as possible.

A typical example was getting fare information.  About once a day, a
scheduling system started a shell script which would FTP a file from a fare
clearing house.  It would validate the files received (by checksum), and
enter  the file name into a database table for processing.  Later on in the
evening, a progrom would be started that would check the database table for
unprocessed entries.  The file would then be processed moving the flat file
into a set of fare tables.

The primary human interaction was with the operators, who would receive
detailed error messages if the process failed at any point.  Some where
fairly simple, on the order of "Connection to remote site could not be
established, please check network connectivity by ..."; some printed out
several pages of detailed analysis of possible problems in order of probable
causes.  Most of those messages were stored in the database, and regular
reviews modified them to keep them current, with feedback from the operators
on useful they were on resolving problems, or how easy they were to
understand.

Finally, each fare was subject to validation.  Each transcaction was
validated.  Any that failed validation had entries created into an error
work queue.  The work queues were processed by a seperate process, which was
interactive, but all the batch job did was add entries to work queue.

The only real role I can see is the operator, and, under most conditions,
there were no interactions with the operator.  I can remember at least one
period where the fare loading process ran for 4 months without operator
intervention, which was our main goal for this process.

So how do you tackle this sort of process from a usage centered design
process?



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

I'd like to get this group's opinion on an assertion I've made:

In a couple papers I've submitted recently I've made the assertion
that Interaction Design represents a class of activity that can be
effectively added into agile development methodologies such as XP or
Scrum.  I'm asserting Usage-Centered Design, in the agile form that
Larry and Lucy teach it, represents an ideal method for implementing
Interaction Design in practice.

So, is that statement garbage?

I've been asked for more references on Interaction Design as a
discipline.  And, unfortunately I'm coming up short.  It turns out I
may have my own working definition of the term - and it may not match
with other's.  How would _you_ define "Interaction Design"?  Does
Usage-Centered Design qualify as form of Interactions Design?  If
not, is there a generic term for what Usage-Centered Design is - a
Superclass so to speak?  Are there books, or articles you could
recommend that might discuss Interaction Design as a discipline?

Thanks for any opinions you can offer.

-Jeff

Jeff,

Thanks for raising another good question.

Interaction design, like information architecture, is a neologism that many
are claiming is an advance over or better than or newer than user interface
design. Like much other current terminology, it has almost as many meanings
as it has users.

In the broad sense, interaction design means design of the interaction--the
process of exchange or intercommunication--between users and a system. Some
claimants to the title of interaction designer say they do not do user
interface design--that's old stuff and the easy part. Most seem to see
interaction design as embracing aspects of the design problem not covered by
user interface design as many have come to regard it, which became stuck at
the level of widget choice and layout.

In the narrow sense in which we often use the term interaction design, it is
just one part of user interface design, that is, design of the interface
between the system and the user. Interaction design concerns dynamics and
behavior; it's complement is visual design, which concerns layout and
appearance. Obviously this shows a GUI bias. If you have a voice interface,
the split is less clear, but there are structural aspects--how the options
and responses are organized into menus, submenus, packets--and the dynamic
aspects involving sequence, interruptability, etc.

David Anderson at uidesign.net is one of the strong proponents of
interaction design as distinct from (rather than a part of) user interface
design.

There is also a political issue, which is that interaction design is more
trendy than UI design.

As to usage-centered design, we would describe it as a refinement of
improvement upon user-centered design. It is one method for approaching
interaction design, user interface design, visual interface design...

That's how I'd call it. Any other comments out there?

--Larry Constantine
   forUSE 2002 | 25-28 August 2002
   Sponsored by Constantine & Lockwood, Ltd.
   www.foruse.com/2002/


> -----Original Message-----
> From:
> sentto-1175705-108-1021059889-lConstantine=compuserve.com@...
> .yahoo.com
> [mailto:sentto-1175705-108-1021059889-lConstantine=compuserve.com@return
> s.groups.yahoo.com]On Behalf Of jeff621
> Sent: 10 May 2002 3:45 PM
> To: usage-centered@yahoogroups.com
> Subject: [usage-centered] What's Interaction Design?
>
>
>
> I'd like to get this group's opinion on an assertion I've made:
>
> In a couple papers I've submitted recently I've made the assertion
> that Interaction Design represents a class of activity that can be
> effectively added into agile development methodologies such as XP or
> Scrum.  I'm asserting Usage-Centered Design, in the agile form that
> Larry and Lucy teach it, represents an ideal method for implementing
> Interaction Design in practice.
>
> So, is that statement garbage?
>
> I've been asked for more references on Interaction Design as a
> discipline.  And, unfortunately I'm coming up short.  It turns out I
> may have my own working definition of the term - and it may not match
> with other's.  How would _you_ define "Interaction Design"?  Does
> Usage-Centered Design qualify as form of Interactions Design?  If
> not, is there a generic term for what Usage-Centered Design is - a
> Superclass so to speak?  Are there books, or articles you could
> recommend that might discuss Interaction Design as a discipline?
>
> Thanks for any opinions you can offer.
>
> -Jeff
>
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>

on 12/05/02 01:14, Larry Constantine at lConstantine@... wrote:

I agree that interaction design is far more a political issue rather than an
interesting scientific or technical breakthrough, whether in user-interface
design or user-centered development. The issue is quite similar to the
"agile development" movement... Suddenly every method out there is "agile"
or "extreme", it doesn't matter if many of the proponents don't have a clue
about the development context (software engineering in the small) that
jumpstarted lightweight methods - I prefer to use the older terms since I
don't see any fundamental different between them!

I agree with Larry in the broad definition of interaction design as "design
of the interaction between users and a system". However, I disagree with the
narrow definition...

> In the narrow sense in which we often use the term interaction design, it is
> just one part of user interface design, that is, design of the interface
> between the system and the user. Interaction design concerns dynamics and
> behavior; it's complement is visual design, which concerns layout and
> appearance. Obviously this shows a GUI bias. If you have a voice interface,
> the split is less clear, but there are structural aspects--how the options
> and responses are organized into menus, submenus, packets--and the dynamic
> aspects involving sequence, interruptability, etc.

Assuming the broad definition, it seams obvious that interaction design
starts at early project inception when task cases (or task flows) are
identified and the structure of use is captured and worked. This is
specially true when work or process re-engineering are a concern (and they
should always be in my opinion). The key issue here is that, assuming
interaction design starts early in the project lifecycle, then it highly
influences the system architecture... And perhaps that is the major
breakthrough in the last couple of years (together with what is known as
OOUID). Unfortunately it seams that those important aspects are not
interesting in a world of x-something or agile-something!!!

That brings us to Jeff's assertion...

>> In a couple papers I've submitted recently I've made the assertion
>> that Interaction Design represents a class of activity that can be
>> effectively added into agile development methodologies such as XP or
>> Scrum.  I'm asserting Usage-Centered Design, in the agile form that
>> Larry and Lucy teach it, represents an ideal method for implementing
>> Interaction Design in practice.

I'm sorry but I can't figure out how you can practice interaction design as
an activity in XP without creating something which is not XP at all... On
the other hand I can't see how UsageCD can be classified as an agile-method
when Larry and Lucy are strong proponents of upfront-modeling and claim that
agile development can cope with upfront specification of dozens of task
cases without iterative or evolutionary development!!! I hope that somebody
doesn't think about using the excellent modeling techniques of UsageCD,
while doing XP, and them call it X-UsageCD...

Please don't misinterpret me. I'm a strong proponent of some of the
techniques in UsageCD (and XP). I believe that they can be combined in a
different process setup to create agile-methods. I'm also a strong proponent
of engineering practices such as the ones proposed by Larry and others...
Surely nobody would want to cross a bridge or fly an airplane that was build
over a set of "religious" principles...

This is perhaps a useless discussion, at least until we can settle over
definitions of some simples things like technique, method, process...

I would highly recommend reading an interview with Jeff Raskin about
Cooper's book that coined (at least to my knowledge) the term interaction
design (http://www.uidesign.net/2000/letters/raskinoncooper.html)...

Please carry on...
     Nuno

--
Nuno Jardim Nunes
URL: http://www.math.uma.pt/njn/

In scanning through some recent usage-centered mailings (yeah,
I'm running a bit behind ;-), I found:


jeff621 wrote:

  > I'd like to get this group's opinion on an assertion I've made:
  >
  > In a couple papers I've submitted recently I've made the assertion
  > that Interaction Design represents a class of activity that can be
  > effectively added into agile development methodologies such as XP or
  > Scrum.  I'm asserting Usage-Centered Design, in the agile form that
  > Larry and Lucy teach it, represents an ideal method for implementing
  > Interaction Design in practice.

Are these papers available somewhere?  I'd like to take a look
if I could.

  > So, is that statement garbage?

I don't think so.  I've spent a lot of time on my last client's
project working with the IA/UI Designer to weave his activities
into the overall agile process (mostly based on XP).  He uses a
process very much like UCD, which I also advocate.

The main issue we encountered is that some of the IA activities
seem to best occur upstream from the development activities.
For example, the layout of the use cases into an overall task
map, with a map of the pages, seems to fit better when run close
to the story writing activities, since these help the Customer
define and scope the story.  The developers really can't start
writing the guts of the pages unless they know what pages exist
and know what widgets need to be on the pages.  Adding the page
refinements, like graphics and fonts and widget locations can be
done concurrently with the development.

Just as an added thought, one key reason we can't do all of this
in parallel is that the skill sets for IA/UI (especially graphic
design) is really different from the skill set for programming
the business logic with Java.  The only overlap is in the areas
of HTML and Javascript.  So, we can't treat the IA/UI design as
just another task for the task pool, and pairing has limited
returns when the skill sets are so different.

We focused a lot on determining what the minimal investment
that needed to be made in the IA/UI design before we could
feed it to the developers.  This investment was made when the
Customer was reasonable certain the story would show up in the
next iteration, so the IA/UI Designer was essentially working
one iteration ahead of the Java developers.  The IA/UI design
products are incrementally refined as needed through the two
iterations, with good source control used to make sure the
UI designers and developers aren't trashing each other's work.
This "pipeline" is decidedly /not/ agile, but it's the best we
came up with and it worked well in practice.


Also, while we're on this thread, Nuno J. Nunes wrote:

  > Suddenly every method out there is "agile" or "extreme", it
  > doesn't matter if many of the proponents don't have a clue
  > about the development context (software engineering in the
  > small) that jumpstarted lightweight methods

I agree about the misuse of the term "agile," however the main
context that spurred the development of agile methods like XP
wasn't programming in the small, it was development in an
environment where requirements were changing and rapid
development was needed.  Agile methods are mostly oriented
towards moving fast and adapting to change.  Simplicity,
providing feedback, close collaboration, avoiding debt, etc.
are strategies used to manifest rapid, adaptable development.

I also agree with Nuno that adding UCD into XP seems to result
in something that is no longer XP due to the pipeline effect
I mentioned above that prevents a single iteration from being
a discrete unit of development.  I belive we can apply agile
principles and strategies to UCD (Larry's got some stuff on
this as well), and our experience is that the result is agile
enough for the projects where we've tried it.  YMMV.

Regards,
Paul
-----
Paul Hodgetts -- Principal Consultant
Agile Logic -- www.agilelogic.com
Training, Mentoring, Development -- Agile Processes, XP, Java, J2EE, C++

On 15/05/02 02:20, "Paul Hodgetts" <phodgetts@...> wrote:


> I don't think so.  I've spent a lot of time on my last client's
> project working with the IA/UI Designer to weave his activities
> into the overall agile process (mostly based on XP).  He uses a
> process very much like UCD, which I also advocate.

That's fine, but what people are doing is combining different techniques to
create a customised method.

The key issues here are, for instance, what process framework emerges from
combining XP and UsageCD? Iterative? Evolutionary? Spiral?
Are task cases the stories used in XP? If not, what is used? What are
stories in XP? How do you convey stories in XP?
How much effort is put into UsageCD up-front design? What about up-front
design and XP principles? Does that design only impact the UI or also the
internal functionality?
How do you convey architectural spikes in UsageCD+XP? What is the impact of
UI elements in the architectural spike? What is an architectural spike in
XP? What is an architectural model in UsageCD?

> I agree about the misuse of the term "agile," however the main
> context that spurred the development of agile methods like XP
> wasn't programming in the small, it was development in an
> environment where requirements were changing and rapid
> development was needed.  Agile methods are mostly oriented
> towards moving fast and adapting to change.  Simplicity,
> providing feedback, close collaboration, avoiding debt, etc.
> are strategies used to manifest rapid, adaptable development.

I meant software engineering in the small and not programming in the
small... There's a huge difference... Of course I agree that changing
requirements are the key issue spurring agile development... The problem is
that changing requirements happen in both small and large-scale SE!

Interesting discussion...
     Nuno
--
Nuno Jardim Nunes
Assistant Professor
University of Madeira
Mathematics Dep. - Computer Science Unit
URL: http://math.uma.pt/njn/

Thanks all for the comments back.

Nuno, thanks for the reference to UIDesign.net.  I'd read the Cooper
interview, but not the Raskin comments afterwards.  Basically if
these well-respected people don't have a common definition of
Interaction Design, I don't expect I'll find one.

The stuff I'm trying to label are the decisions made before we know
what might be on the user interface - or if there should be a user-
interface at all.  I'm seeing Interaction Design addressing questions
like: "Who are the users?",  "What do they want?", "How should they
interact with some system to get it?",  "Who else cares and what do
they want?".  Once we've decided what the users should do with the
system, and basically what interaction contexts might contain, we can
go about designing user interface and measuring its effectiveness.
But no amount of good user-interface will compensate for
misunderstanding the goal of a user - or leaving an important user
out completely.

Paul Hodgets wrote:
>Are these papers available somewhere? I'd like to take a look
if I could.<

They're simple experience reports and still a work in progress.
XP/Agile Universe and OOPSLA have accepted drafts.  They'll be
presented at each of those conferences.  It's feedback from those
groups that prompted my post.  I'd asserted that some form of
Interaction Design should be used - but then only gave information
about U-CD.  Which prompted the fair question "What is interaction
design exactly?  And, what other forms are there?"  - Which maybe
should have been my real posted question to this group.

Nuno Nunez wrote:
>Assuming the broad definition, it seams obvious that interaction
design
starts at early project inception when task cases (or task flows) are
identified and the structure of use is captured and worked. This is
especially true when work or process re-engineering are a concern
(and they
should always be in my opinion). The key issue here is that, assuming
interaction design starts early in the project lifecycle, then it
highly
influences the system architecture... And perhaps that is the major
breakthrough in the last couple of years (together with what is known
as
OOUID). Unfortunately it seams that those important aspects are not
interesting in a world of x-something or agile-something!!!<

Good comments.  I'll focus on the comment on interaction design
influencing system architecture.  We've had good luck bringing
developers, business people, end-users and UI people together in
collaborative U-CD sessions.  We find that developers and UI people
come away with a better understanding of why things are the way they
are.  And, business people and end-users understand how doing things
a little differently can be more cost effective and faster.  U-CD
gives us a framework to make sure we ask and answer all those right
questions.  We end up calling this agile because it's highly
collaborative, we throw around lots of 3x5 cards, we churn out lots
of poster-sized post-its then roll them up and call them design
documents.  We may be guilty of calling it agile because it doesn't
look like anything we used to do.

Nuno Nunez also wrote:
>I'm sorry but I can't figure out how you can practice interaction
design as
an activity in XP without creating something which is not XP at
all... On
the other hand I can't see how UsageCD can be classified as an agile-
method
when Larry and Lucy are strong proponents of upfront-modeling and
claim that
agile development can cope with upfront specification of dozens of
task
cases without iterative or evolutionary development!!! I hope that
somebody
doesn't think about using the excellent modeling techniques of
UsageCD,
while doing XP, and them call it X-UsageCD...<

This is a fun one to respond to.  I've never seen an XP project that
could be called XP – including the one I spent a year on that was set
up by Kent Beck himself.  We're definitely not doing pure XP.  We do
XP style planning, regular iterations, unit-testing, refactoring,
pair programming.. yada yada yada.  But, we front-end this entire
process with a collaborative U-CD session.  We "re-brand" our
resulting task-cases as user-stories then use them to plan releases
and iterations.  Things get "agile" when we realize we made a mistake
and need to change our minds about what to develop.  We go back to
the user roles and task cases and make our decisions with what we
hope are interaction designer's sensibilities.

On iterative development and upfront specification of lots of task
cases, I find that when XP people bristle at big upfront design,
they're generally talking about the architecture & objects under the
interactions.  In practice we don't decide any of that stuff up
front.  We still have lots of room to make mistakes and change that
design without affecting the interactions we agreed on together.
There's still plenty of room to really evolve the architecture over
the course of many iterations.  We may let interaction requirements
push some major architectural issues – like "the performance of
interactions required for this user may be better served by a Java
Swing UI rather than an HTML/Servlet based approach."

I hope we don't see an X-UsageCD either.  I'll make it a career goal
right now to never invent a software development methodology.  I
couldn't take the resulting abuse… ;-)  - Makes me think of the joke
you've likely all heard:  "What's the difference between a
methodologist and a terrorist? – You can negotiate with a terrorist."

Larry Constantine wrote:
>There is also a political issue, which is that interaction design is
more trendy than UI design.<

I'm adopting the more trendy interaction design label.  The political
issue I keep fighting in the XP/Agile community is: "UI designers are
the people you bring in to make things pretty just before you ship."
The emphasis in XP and agile processes to involve the "customer" or
user in the process is a good one.  Now if we can just get someone in
there to ask the customer the right questions, we may just get
somewhere.  So, coming full circle, that skill of knowing what
questions to ask and how to respond to that with an appropriate piece
of software - can I get away with calling that "Interaction Design?"

Someone also forwarded me this link:
http://www.chesco.com/~cmarion/PCD/WhatIsInteractionDesign.html -
thanks Peter.  I haven't digested this article yet, but it may have
some useful ideas as well.

Thanks again for everyone's comments.  Lots of good information and
lots of good ideas to consider.

Jeff Patton
Development Team Lead
Tomax Technologies
(801) 924 - 6924

"We can't solve problems by using the same kind of thinking we used
when we created them."
Albert Einstein

Don't Miss This Exciting Opportunity!

Superb Computer Based Training OFFER

Please click on link below:
http://web.iwebcenters.com/globalcbt/newrequirements.ivnu?afl=jays



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

CollegeClub.com is sizzlin' this summer!
Win cash, play games and get hooked up.
http://navisite.collegeclub.com/summer2002/

Hi,

I only recently discovered this group on the Yahoo! list. Is it still
alive? Did it die for a reason? Is anyone interested in resurrecting it?

I'd like to ask if anyone on the list has given any thought to the
best way to be an agile software developer is not to build stuff the
user doesn't need? To me, it's the notion that usage-centered design
can be applied early to help product managers focus their marketing
requirements.

I'm considering studying this area in greater depth and would like to
know if there is anyone out there who has looked at this issue already
and any work which I should go read before I start.

Best regards,

David
--
David J. Anderson
http://www.uidesign.net/
The Webzine for Interaction Designers

PS The thread on Interaction Design from a year or two back made me smile.

Agile Manifesto Principle #10 reads

"Simplicity--the art of maximizing the amount
of work not done--is essential."

To me this means that it is important to know what is
appropriate and will be valued by the user - producing
a minimal design for it and insuring that maximum
value is delivered for the programming buck. That is
right in the agile space but it needs UCD to achieve
it.

I believe that this principle can be delivered through
correct persona definition, and thorough task analysis
leading to the right set of task cases.

Hence, I believe that Usage-Centered Design is a key
element to delivering a truly agile software
development organization. Agility is just about
programmers hugging each other while they write unit
tests.

David
--
David J. Anderson
http://www.uidesign.net/
The Webzine for Interaction Designers



--- David Anderson <netherby_uk@...> wrote:

---------------------------------
Hi,

I only recently discovered this group on the Yahoo!
list. Is it still
alive? Did it die for a reason? Is anyone interested
in resurrecting it?

I'd like to ask if anyone on the list has given any
thought to the
best way to be an agile software developer is not to
build stuff the
user doesn't need? To me, it's the notion that
usage-centered design
can be applied early to help product managers focus
their marketing
requirements.

I'm considering studying this area in greater depth
and would like to
know if there is anyone out there who has looked at
this issue already
and any work which I should go read before I start.

Best regards,

David
--
David J. Anderson
http://www.uidesign.net/
The Webzine for Interaction Designers

PS The thread on Interaction Design from a year or two
back made me smile.


Yahoo! Groups Sponsor  ADVERTISEMENT

Your use of Yahoo! Groups is subject to the Yahoo!
Terms of Service.


__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
http://webhosting.yahoo.com

The group may be a little stagnant, but the concepts aren't.

I've been doing exactly what you describe.  U-CD, as Larry and Lucy
teach it is very agile.  I use a collaborative U-CD session involving
development and customers to establish the initial scope.  During
this quick collaborative session (1-2 days depending on the size of
the problem) we create a role model, task model and interaction
contexts.  From this we can extract features, stories or whatever
your agile methodology wants to call them.  Since developers are in
the room we can roughly and quickly estimate development time.  We
write up the result of this meeting in a scope document that the
customers and developers walk away with.  During development, at the
head of each iteration we flesh out tasks and create wireframe UI -
just-in-time.  The role and task models live as posters on the wall
in the development room to contuously help us be aware of the users
and tasks, their relationships and priorities.

The whole thing works very well.

I haven't written too much, but you'll find an experience report
here: http://oopsla.acm.org/fp/files/pra_extra.html  If I get my act
together, I'll be giving a presentation and/or tutorial on exactly
this stuff at ForUse 2003.

cheers,

-Jeff

--- In usage-centered@yahoogroups.com, "David Anderson"
<netherby_uk@y...> wrote:
> Hi,
>
> I only recently discovered this group on the Yahoo! list. Is it
still
> alive? Did it die for a reason? Is anyone interested in
resurrecting it?
>
> I'd like to ask if anyone on the list has given any thought to the
> best way to be an agile software developer is not to build stuff the
> user doesn't need? To me, it's the notion that usage-centered design
> can be applied early to help product managers focus their marketing
> requirements.
>
> I'm considering studying this area in greater depth and would like
to
> know if there is anyone out there who has looked at this issue
already
> and any work which I should go read before I start.
>
> Best regards,
>
> David
> --
> David J. Anderson
> http://www.uidesign.net/
> The Webzine for Interaction Designers
>
> PS The thread on Interaction Design from a year or two back made me
smile.

Interesting! I look forward to seeing you at forUse
2003. Glad to see at least one more person sees the
agile advantage from UI design effort up-front.

Have you seen the paper I wrote in 1999 on
collaborative UI design sessions?
http://www.uidesign.net/1999/papers/UI_Modelling1.html

This was the process used on the original FDD project
in Singapore. This stuff was never documented as part
of the official book on FDD as the UI processes were
not considered sufficiently mature at the time. Since
then I've significantly improved them. I must get
around to writing it all down sometime.

David
--
David J. Anderson
http://www.uidesign.net/
The Webzine for Interaction Designers

--- Jeff Patton <jeff621@...> wrote:

---------------------------------
The group may be a little stagnant, but the concepts
aren't.

I've been doing exactly what you describe.  U-CD, as
Larry and Lucy
teach it is very agile.  I use a collaborative U-CD
session involving
development and customers to establish the initial
scope.  During
this quick collaborative session (1-2 days depending
on the size of
the problem) we create a role model, task model and
interaction
contexts.  From this we can extract features, stories
or whatever
your agile methodology wants to call them.  Since
developers are in
the room we can roughly and quickly estimate
development time.  We
write up the result of this meeting in a scope
document that the
customers and developers walk away with.  During
development, at the
head of each iteration we flesh out tasks and create
wireframe UI -
just-in-time.  The role and task models live as
posters on the wall
in the development room to contuously help us be aware
of the users
and tasks, their relationships and priorities.

The whole thing works very well.

I haven't written too much, but you'll find an
experience report
here: http://oopsla.acm.org/fp/files/pra_extra.html
If I get my act
together, I'll be giving a presentation and/or
tutorial on exactly
this stuff at ForUse 2003.

cheers,

-Jeff

--- In usage-centered@yahoogroups.com, "David
Anderson"
<netherby_uk@y...> wrote:
> Hi,
>
> I only recently discovered this group on the Yahoo!
list. Is it
still
> alive? Did it die for a reason? Is anyone interested
in
resurrecting it?
>
> I'd like to ask if anyone on the list has given any
thought to the
> best way to be an agile software developer is not to
build stuff the
> user doesn't need? To me, it's the notion that
usage-centered design
> can be applied early to help product managers focus
their marketing
> requirements.
>
> I'm considering studying this area in greater depth
and would like
to
> know if there is anyone out there who has looked at
this issue
already
> and any work which I should go read before I start.
>
> Best regards,
>
> David
> --
> David J. Anderson
> http://www.uidesign.net/
> The Webzine for Interaction Designers
>
> PS The thread on Interaction Design from a year or
two back made me
smile.


Yahoo! Groups Sponsor  ADVERTISEMENT

Your use of Yahoo! Groups is subject to the Yahoo!
Terms of Service.


__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
http://webhosting.yahoo.com

--Larry Constantine [mailto:lconstantine@...]
   Director of Research and Development
   Constantine & Lockwood, Ltd.
   58 Kathleen Circle | Rowley, MA 01969
   tel: +1 978 948 5012 | fax: +1 978 948 5036 | www.foruse.com
> I only recently discovered this group on the Yahoo! list. Is it still
> alive? Did it die for a reason? Is anyone interested in resurrecting it?

It's a matter of numbers and the fact that the forUSE newsletter has evolved
into the primary forum.

> I'd like to ask if anyone on the list has given any thought to the
> best way to be an agile software developer is not to build stuff the
> user doesn't need? To me, it's the notion that usage-centered design
> can be applied early to help product managers focus their marketing
> requirements.

Jeff Patton (who has already chimed in) has done good work in this area.

> I'm considering studying this area in greater depth and would like to
> know if there is anyone out there who has looked at this issue already
> and any work which I should go read before I start.

Bravo! Keep us all informed.

--Larry Constantine

Hi there,

This issue was already discussed previously here, by that time my only
concern was how can you combine an upfront design method like UsageCD
with the principles of XP... One year latter this kind of combination
(at the methodological level) still beats me...

I don't want to be academic here, but there is an important difference
between a method (like UsageCD - sorry but I don't consider XP a
method) and a set of techniques: card games, participatory design,
prototyping, etc.

XP, and the Agile manifesto for that matter, are mainly a set of
philosophical principles that promote rapid development, refactoring,
pair-programming, etc. - which are techniques (most of them quite old)
that can be used successfully with any other method. What XP doesn't
describe are specific steps for systematic development... what are XP
stories? how can you describe them? are they scenarios? are they
(essential) use-cases? how are users modeled? with abstractions like
actors? user profiles? or the "fascinating" personas (how on earth can
you do UCD with stuff like personas!!!). What is an architectural
spike? Is this a conceptual or physical model of the software
architecture? But then it can be a model... modeling has nothing to do
with XP...

These are some answers I'm trying to find since I bumped into XP some
years ago... before lightweight methods (or should I say any method)
became the politically correct agile.

Sorry for being the only guy on earth not excited with XP and the Agile
Manifesto...

Nuno

PS: There are many important things about development agility and UCD
or UID. For instance the importance of the structure of use of a
software system to the underlying architecture... and the impact of UCD
in the overall system size and complexity...

On Quarta, Mar 12, 2003, at 19:52 Europe/Lisbon, Tom Poppendieck wrote:

> David –
>
>  
>
> I am advocating the thesis that usage centered design is in fact the
> foundation of a set of agile customer-side practices similar to the
> developer-side practices that are the core of XP and the Project
> Management Practices that are at the core of Scrum and the XP Joint
> practices.  The fundamental issue is that while TDD permits
> refactoring to let the architecture of code emerge, there is no
> similar opportunity to refactor the users once they commit usage
> patterns to muscle memory.
>
>  
>
> I am taking a stab at articulating this at SDWest 2003 in a tutorial. 
> Larry Constantine is offering some sessions on Card Based design that
> I expect will follow a similar direction.
>
>  
>
>  
>
> - Tom Poppendieck
>
>  
>
> -----Original Message-----
> From: David J. Anderson [mailto:netherby_uk@...]
> Sent: Wednesday, March 12, 2003 10:25 AM
> To: usage-centered@yahoogroups.com
> Subject: Re: [usage-centered] Product Management, Agile and UCD
>
>  
>
> <Snip>
> Hence, I believe that Usage-Centered Design is a key
> element to delivering a truly agile software
> development organization. Agility is just about
> programmers hugging each other while they write unit
> tests.
>
> David
> --
> David J. Anderson
> http://www.uidesign.net/
> The Webzine for Interaction Designers
>
>
>
> .
>
>
<image.tiff>
>
>
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

Nuno -
Those same philosophical principles, under the banner of lean
thinking have revolutionized manufacturing, logistics, and even
government by eliminating waste and enabling people to do the
best work they are capable of.  The resistance to lean practices
in manufacturing took a decade to go away.  Today, those
organizations that did not adopt lean approaches are out of
business. Information about how lean thinking applies to software
development is available at www.leanprogramming.com.
If you are still interested in learning about agile methods.
answers to your questions are available at
http://www.agilealliance.com/articles/index and many other
places.  A discussion group such as this is a poor medium to
address such questions.
- Tom Poppendieck
Nuno wrote:
<SNIP>
XP, and the Agile manifesto for that matter, are mainly a set of
philosophical principles that promote rapid development,
refactoring, pair-programming, etc. - which are techniques (most
of them quite old) that can be used successfully with any other
method. What XP doesn't describe are specific steps for
systematic development... what are XP stories? how can you
describe them? are they scenarios? are they (essential)
use-cases? how are users modeled? with abstractions like actors?
user profiles? or the "fascinating" personas (how on earth can
you do UCD with stuff like personas!!!). What is an architectural
spike? Is this a conceptual or physical model of the software
architecture? But then it can be a model... modeling has nothing
to do with XP...
These are some answers I'm trying to find since I bumped into XP
some years ago... before lightweight methods (or should I say any
method) became the politically correct agile.
Sorry for being the only guy on earth not excited with XP and the
Agile Manifesto...
Nuno

PS: There are many important things about development agility and
UCD or UID. For instance the importance of the structure of use
of a software system to the underlying architecture... and the
impact of UCD in the overall system size and complexity...

I didn't say that those principles are not useful... They were before
XP existed and they are now.

My point is that all the excitement with X-this and agile-that is
leading to methodological misconceptions that ultimately lead
practitioners to unfunded and misleading assumptions about the role of
development principles, design techniques, process models and specific
methods...

For instance, some of the principles behind XP are not consistent with
up-front modeling (or any kind of modeling). I'm not saying that you
can't combine some XP principles and techniques with some UsageCD
principles and techniques, just that the combination is not XP or
UsageCD - it's something completely different that requires specific
methodological concerns. The lack of such methodological concerns leads
to chaotic styles of development (chaotic doesn't mean that they don't
work on real projects, it just means that they are not consistently
repeatable across projects and teams)... This is something I've been
researching for a while... and I've seen people with rigid
waterfall-like lifecycle models practicing pair-programming, or using
iterative and incremental development with rigid up-front modeling
approaches (meaning devoting literally months to analysis)...

Nuno

On Quinta, Mar 13, 2003, at 02:39 Europe/Lisbon, Tom Poppendieck wrote:

> Nuno -
> Those same philosophical principles, under the banner of lean
> thinking have revolutionized manufacturing, logistics, and even
> government by eliminating waste and enabling people to do the
> best work they are capable of.  The resistance to lean practices
> in manufacturing took a decade to go away.  Today, those
> organizations that did not adopt lean approaches are out of
> business. Information about how lean thinking applies to software
> development is available at www.leanprogramming.com.
> If you are still interested in learning about agile methods.
> answers to your questions are available at
> http://www.agilealliance.com/articles/index and many other
> places.  A discussion group such as this is a poor medium to
> address such questions.
> - Tom Poppendieck
> Nuno wrote:
> <SNIP>
> XP, and the Agile manifesto for that matter, are mainly a set of
> philosophical principles that promote rapid development,
> refactoring, pair-programming, etc. - which are techniques (most
> of them quite old) that can be used successfully with any other
> method. What XP doesn't describe are specific steps for
> systematic development... what are XP stories? how can you
> describe them? are they scenarios? are they (essential)
> use-cases? how are users modeled? with abstractions like actors?
> user profiles? or the "fascinating" personas (how on earth can
> you do UCD with stuff like personas!!!). What is an architectural
> spike? Is this a conceptual or physical model of the software
> architecture? But then it can be a model... modeling has nothing
> to do with XP...
> These are some answers I'm trying to find since I bumped into XP
> some years ago... before lightweight methods (or should I say any
> method) became the politically correct agile.
> Sorry for being the only guy on earth not excited with XP and the
> Agile Manifesto...
> Nuno
>
> PS: There are many important things about development agility and
> UCD or UID. For instance the importance of the structure of use
> of a software system to the underlying architecture... and the
> impact of UCD in the overall system size and complexity...
>
>
>
>
> ------------------------ Yahoo! Groups Sponsor
> ---------------------~-->
> Get 128 Bit SSL Encryption!
> http://us.click.yahoo.com/xaxhjB/hdqFAA/xGHJAA/NhFolB/TM
> ---------------------------------------------------------------------
> ~->
>
>
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>
>
--
Nuno Jardim Nunes
Assistant Professor, Universidade da Madeira
http://math.uma.pt/njn

Nuno and Tom,

I think this is the right place to discuss and explore such issues--as they
relate to presentation and interaction design broadly and usage-centered
specifically.

As to the issue of rigor in practice, XP, for all it's informality in
terminology and style, is far more an orthodoxy than usage-centered design,
even with its quasi-formal models and logical process. In our view, you can
do usage-centered design in pieces and mixed with almost any methodology
within almost any life-cycle model. It can still be usage-centered. On the
other hand, to claim to be doing XP, you have to buy a package and be
following a whole series of practices.

True, "agile" and "extreme" and "lightweight" are often mere jingoisms of
the market-oriented zeitgeist, but that is just life. It was and is and
always will be the name of the game. Once it was structured this and
structured that, then object this and object that, then unified this and
unified that. All these will pass and the agile agenda, too, someday. The
good ideas from all will survive long after the brand names wither. Nobody
does structured design anymore, but coupling and cohesion are alive and well
as metrics and explanatory factors and the subject of continuing research.

I do not worry either that many--even perhaps most--development groups
misapply or mis-mix methods. It's Sturgeon's Law. The fact is that a group
shoehorning pair programming into an otherwise baroque process may still be
better off than if they didn't do it, and a team that builds a task case
model and sketches a UI design along with orthodox XP will probably crank
out better software than if they just went from stories to code.

Tom may be right that fully lean approaches are absolutely superior, and
Kent may be right that true XP is the true path, and Lucy and I may be right
that model-driven usage-centered design based on a comprehensive task case
model is the best way to go, and Nuno may have valid concerns about
methodological muddling, but the fact is that the vast majority of
developers will muddle and mix and practice only partially controlled chaos
anyway.

--Larry Constantine [mailto:lconstantine@...]
   Director of Research and Development
   Constantine & Lockwood, Ltd.
   58 Kathleen Circle | Rowley, MA 01969
   tel: +1 978 948 5012 | fax: +1 978 948 5036 | www.foruse.com

Jeff,

I read your material. Thanks for the pointer. What a
pity, we didn't get a chance to meet at OOPSLA - I am
based in Seattle and attended the conference for a
single day.

Anyway, I felt I needed to give you some feedback
regarding FDD. You need to be careful when relating
Task Cases to FDD. FDD Features are not tasks. They
are not procedures but functions.

FDD uses architectural partitioning. There are four
types of Features in FDD: PD (problem domain or
business logic); UI (user interface); DM (data
management or persistence); SI (systems interface).

Most of the writing on FDD only talks about PD so
those less familiar with it can be forgiven for
mistakes in interpretation.

The Feature partitioning existed right from the start
in FDD. Of the regular contributors at
http://www.featuredrivendevelopment.com/ Steve Palmer,
Pauyl Szego and Jeff De Luca matured the PD Feature
methods. As these were most mature when the book "Java
Modeling in Color with UML" was written, these were
the things which were written down. Philip Bradley was
repsonsible for the SI and DM side of FDD and I was
repsonsible for the UI.

On the original project the UI was split into two
levels which were known as HLD and LLD (High level and
Low level design - respectively). The HLD tracked my
own work as the designer. The LLD tracked the
developers work programming the UI.

Later I wrote a paper "Extending FDD for UI" which
updated the LLD process using Ian Horrock's work of
Statechart Modeling for UI based on David Harel's
original Statechart notation.

Today, UI Features are grouped in Sets based on the
Container in the UI design. There are Features for
each View and Features for each event controller (or
action).

FDD Features are much more like object-oriented
Function Points than tasks or use cases. This is a
significant distinction from other methods.

Hence, Task Cases need to be elaborated into a Content
Model and Interaction Model before Features can be
defined.

Best Regards,

David
--
David J. Anderson
http://www.uidesign.net/
The Webzine for Interaction Designers


--- Jeff Patton <jeff621@...> wrote:


I haven't written too much, but you'll find an
experience report
here: http://oopsla.acm.org/fp/files/pra_extra.html
If I get my act
together, I'll be giving a presentation and/or
tutorial on exactly
this stuff at ForUse 2003.

cheers,

-Jeff



__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
http://webhosting.yahoo.com

Thanks David for the feedback.  I'm sure it's obvious that my knowledge of FDD is a little sketchy.  Based on the little reading I'd done, I'd very roughly equated FDD features to XP stories - and from what I'm hearing, if you look at them sideways, FDD PD type features could be mistaken for stories.  I'll dig in over the next little while and read more about FDD so I can understand it better.  But, I have to admit that the little bit of reading I've done has left me confused.  I had actually found your site and read your article there months ago.

>Hence, Task Cases need to be elaborated into a Content
Model and Interaction Model before Features can be
defined.<

In practice, these days, I've found this to be true also.  I am finding that I can't simply recast task cases into things to develop. 

My methods these days are more about establishing a language that works between development, customers and management.  I don't like the XP term "story" - since folks with millions of dollars to spend don't feel good about characterizing their needs as a "pack of stories."  I have been using the term "feature."  And by that I mean something that is understandable by customer and management, decomposable and buildable by development, testable by QA and easily demonstrable at acceptance time.  For those features I look for traceability back through the U-CD task and role models.  I need to know who uses the feature, in support of what goal, and as part of what task.

Looking at what I understand so far about FDD, the granularity of feature types might fail some of my tests for a valid feature - such as "understandable by customer and management."  Today, every once in a while, I let features slip into scope documents that fail my tests above.  After 30 minutes on a conference call explaining to a group of customers what I mean by BusinessObject, object-relational mapping and persistence, I've sworn to plan, manage and commicate about projects in terminology that works for most people involved.  Internally we'll break my course-grain features out into development tasks that might closely match up to FDD features types - but for us that sort of exercise is part of our teams implementation - not our public interface - if that makes sense.    

This very course-grain feature probably really is an XP story.  That's what I'm finding U-CD very effective at generating quickly and collaboratively. 

But, back to the original point of your message - I'd better get up to speed on FDD so I'm not mis-using its terminology.  And, more importantly, so I can make use of the work you and others have done.

BTW: I'd found and rooted around in your site sometime last year, but at that time it looked like you'd discontinued posting new content.  Looking at it now I see lots of new stuff to read.  I'll look forward to digging through it.

Thanks again for the feedback.  I look forward to meeting you sometime soon.  I'm sure we'll stumble across each other at one of these conferences.

If you're ever in or near my neck of the wood, Salt Lake City, please look me up. 

cheers,

-Jeff

 "David J. Anderson" <netherby_uk@...> wrote:

Jeff,

I read your material. Thanks for the pointer. What a
pity, we didn't get a chance to meet at OOPSLA - I am
based in Seattle and attended the conference for a
single day.

Anyway, I felt I needed to give you some feedback
regarding FDD. You need to be careful when relating
Task Cases to FDD. FDD Features are not tasks. They
are not procedures but functions.

FDD uses architectural partitioning. There are four
types of Features in FDD: PD (problem domain or
business logic); UI (user interface); DM (data
management or persistence); SI (systems interface).

Most of the writing on FDD only talks about PD so
those less familiar with it can be forgiven for
mistakes in interpretation.

The Feature partitioning existed right from the start
in FDD. Of the regular contributors at
http://www.featuredrivendevelopment.com/ Steve Palmer,
Pauyl Szego and Jeff De Luca matured the PD Feature
methods. As these were most mature when the book "Java
Modeling in Color with UML" was written, these were
the things which were written down. Philip Bradley was
repsonsible for the SI and DM side of FDD and I was
repsonsible for the UI.

On the original project the UI was split into two
levels which were known as HLD and LLD (High level and
Low level design - respectively). The HLD tracked my
own work as the designer. The LLD tracked the
developers work programming the UI.

Later I wrote a paper "Extending FDD for UI" which
updated the LLD process using Ian Horrock's work of
Statechart Modeling for UI based on David Harel's
original Statechart notation.

Today, UI Features are grouped in Sets based on the
Container in the UI design. There are Features for
each View and Features for each event controller (or
action).

FDD Features are much more like object-oriented
Function Points than tasks or use cases. This is a
significant distinction from other methods.

Hence, Task Cases need to be elaborated into a Content
Model and Interaction Model before Features can be
defined.

Best Regards,

David
--
David J. Anderson
http://www.uidesign.net/
The Webzine for Interaction Designers


--- Jeff Patton <jeff621@...> wrote:


I haven't written too much, but you'll find an
experience report
here: http://oopsla.acm.org/fp/files/pra_extra.html
If I get my act
together, I'll be giving a presentation and/or
tutorial on exactly
this stuff at ForUse 2003.

cheers,

-Jeff



__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
http://webhosting.yahoo.com


Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

Yes, the term Feature was never completed
satisfactory.

Se my post at the FDD community site on "A Feature by
any other name".

Features in FDD come after initial analysis. The PD
Features are definitely understandable by the
customer. The UI Features are too. Customers
comprehend a single View object and they understand
the notion that code must be written to process button
presses and their like. SI and DM are not understood
by the customer.

Hence, I tend to work with Marketing Features - which
would be your coarse-grained features - and either FDD
or Coad Features which are the Features as defined in
FDD for UI, PD, DM and SI.

The Feature template for PD and the architectural
partitioning are Peter Coad's contributions to FDD.

Sadly, there still isn't enough written down about FDD
in the other layers outside of PD.

I intend to re-launch uidesign.net in April with
irregular content. The recent material there will be
moving to my other site agilemanagement.net.

David

--- Jeff Patton <jeff621@...> wrote:
>
>
> BTW: I'd found and rooted around in your site
> sometime last year, but at that time it looked like
> you'd discontinued posting new content.  Looking at
> it now I see lots of new stuff to read.  I'll look
> forward to digging through it.
>


__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
http://webhosting.yahoo.com