At 07:48 PM 9/3/2006, Jason Yip wrote:
>I've been reading Steve Krug's Don't Make Me Think and he references a
>1995 paper on browser behaviour that indicates 40.6% of browser
>actions are the Back button.
>
>The paper seems a bit old though (browser was X/Mosaic) and I'm
>wondering if anyone knows of more current data confirming this result?

Statistics like this are meaningless without context. It's like saying 99%
of all clicks are with the left button, so why do we have a right mouse button?

With regards to the back button, you have to split things up:

First, are you talking about a transactional flow or searching for
information. The two have distinctly different patterns. For the former,
back button usage traditionally implies lack of a clear "undo" function
(and may result in some sort of error state for either the client browser
or the server).

For information searching, there are some sites where users use the back
button far more than others. Interestingly, in our studies, the sites where
users use the back button less have substantially higher task success rates.

I don't have my hands on the paper you're referring to, but if I remember
the study, it was just a complete log of all browser actions, independent
of what the user was trying to accomplish. I haven't found much use for
statistics like that. They don't really tell us what to do differently.

Jared

Jared M. Spool, Founding Principal, User Interface Engineering
510 Turnpike Street, Suite 102, North Andover, MA 01845
978 327-5561   jspool@...  http://www.uie.com
Blog: http://www.uie.com/brainsparks

Hi, Adrian. Fantastic post! I'm definitely going to look at applying the
constrained state transition network you mention for page mapping. One
minor, minor comment:

Adrian Howard wrote:
>> But I /can/ write automated tests that check
>> * all pages pass the WAI WCAG validation suite without fatal errors
>> * all images have ALT attributes
>> * all ALT attributes come from the url/image/alt-text mapping
>> dictionary that I've checked
>> * link text comes from the url/url mapping table that I previously
>> checked
>> * that the MD5 hash of every page has an entry in the "a human
>> reviewed this" table
>> * etc.
>>


Regarding the MD5 hash, I really like to save the whole page after human
review. It means extra storage, but allows for diffing, so that changes
can be pinpointed during subsequent review.

William

Jason Yip wrote:
> I've been reading Steve Krug's Don't Make Me Think and he references a
> 1995 paper on browser behaviour that indicates 40.6% of browser
> actions are the Back button.

I have to agree with Ron that the most common action I do is a
middle-click to open the link in a new tab. The handy thing is that it
doesn't leave the current page, so I can open up several links and then
look at them when I'm done.

In fact, I rarely use the back button because of that, and get very
annoyed when I can't middle-click a link (for example, javascript
navigation links).

--
Cory Foy
http://www.cornetdesign.com

At 01:28 PM 9/4/2006, Cory Foy wrote:
>I have to agree with Ron that the most common action I do is a
>middle-click to open the link in a new tab. The handy thing is that it
>doesn't leave the current page, so I can open up several links and then
>look at them when I'm done.

Historically, self reported behavioral data, such as this, is exceptionally
unreliable. I'm willing to bet, if we were to actually log your browser
actions, we'd find this statement to be false. Just a hunch. What one
perceives they do and what they actually do are often two very different
things.

>In fact, I rarely use the back button because of that, and get very
>annoyed when I can't middle-click a link (for example, javascript
>navigation links).

With all due respect, I'm thinking you're at least two standard deviations
off the mean. ;-)

Jared


Jared M. Spool, Founding Principal, User Interface Engineering
510 Turnpike Street, Suite 102, North Andover, MA 01845
978 327-5561   jspool@...  http://www.uie.com
Blog: http://www.uie.com/brainsparks

Jared M. Spool wrote:
> Historically, self reported behavioral data, such as this, is exceptionally
> unreliable. I'm willing to bet, if we were to actually log your browser
> actions, we'd find this statement to be false. Just a hunch. What one
> perceives they do and what they actually do are often two very different
> things.

Yes. In fact, I'd be open to such a logging thing. I wonder how
difficult it would be.

I do know that I often close windows many times more than I go back, for
the simple reason that if there is any indication that I'd want to go
back to where I was, I open it in a new tab.

> With all due respect, I'm thinking you're at least two standard deviations
> off the mean. ;-)

This is something else I think we both agree on. I offered the example
because, while it is important to consider the back button (especially
in today's AJAXified world of web apps), don't forget those of us who
want to not have to use the back button at all.

--
Cory Foy
http://www.cornetdesign.com

On 4 Sep 2006, at 17:04, William Pietri wrote:

> Regarding the MD5 hash, I really like to save the whole page after
> human
> review. It means extra storage, but allows for diffing, so that
> changes
> can be pinpointed during subsequent review.

You mean your pages aren't in source control?

:)

Adrian

It's one of the ones I often recommend to and people seem to manage
to separate the message from the rhetoric pretty well.

Sure there's a lot in the anti-developer message that get from the
book I disagree with - but there's also a heck of a lot of useful
stuff in there too.

-- Alain:
I agree that there is a lot of useful stuff in there. The problem is, as
you point out,  that there is also much anti-programmer rhetoric in
there, and that makes it hard to focus on the useful stuff if you are a
programmer. I'm a pretty open-minded kind of guy, and am very
sympathetic to the usability-matters message. Yet, I had trouble
focusing on the content. I suspect developers who are not so sensitive
to usability will simply discard the message altogether.

But maybe you have a different experience. When you say that you often
recommend this to people, does that include programmers who not already
pre-conditioned to the message of the book?
----

Also - shaking people up a bit can sometimes be useful :)

-- Alain:
I agree. But you have to shake them in the right way.

For example, putting developers behind a 1-way mirror, to witness
otherwise intelligent users struggle with the software is a good way of
shaking them up.

Telling them that they are a bunch of immature geeks turned prima-donna
is NOT the right way to shake them up.
----

Adrian Howard wrote:
> On 4 Sep 2006, at 17:04, William Pietri wrote:
>
>
>> Regarding the MD5 hash, I really like to save the whole page after
>> human
>> review. It means extra storage, but allows for diffing, so that
>> changes
>> can be pinpointed during subsequent review.
>>
>
> You mean your pages aren't in source control? :)
>

For rendered pages, no. With one UI reviewer, it wasn't necessary. But
that's absolutely the way to do it for multiple users.

William

1) Use heuristics

-- Alain:
Heuristics as in "heuristic usability assessement"? If so, I'm confused,
because those heuristics can only be applied by humans AFAIK.

If on the other hand you mean some heuristics that can coded so that a
machine can apply them, can you provide some examples?
----

2) Split the usability requirements up into things you can test and
things you cannot

-- Alain:
Presumably you mean "things you can test *automatically* and things you
can only test *manually*", right? ----

3) Automate the detection of changes that need a human review.

-- Alain:
Can you give me a concrete example of such a change and how a machine
would be able to identify it automatically?
----

4) Make sure that you're UI concepts are embedded in the code - then
you're normal automated tests should catch them

-- Alain:
In my experience, the normal automated tests can test that something is
*possible*, but they can't test that something is *easy to do*. For
example, the automated tests can verify that it's possible to write a
new email message by clicking on the "new" button, but it can't test
whether the label "new" conveys the message to the user that this is the
button to click to write a new message.
----

One example of 1--3 snipped from something I wrote here ages ago
about accessibility:



> I'm often involved with testing web sites for accessibility. Now
> producing an accessible site involves human judgement. There is no
> automated way to say whether a particular piece of alternative text
> "makes sense", or that a piece of prose on a link title gives
> enough information to the user in a particular context.
>
> But I /can/ write automated tests that check
> * all pages pass the WAI WCAG validation suite without fatal errors
> * all images have ALT attributes
> * all ALT attributes come from the url/image/alt-text mapping
> dictionary that I've checked
> * link text comes from the url/url mapping table that I previously
> checked
> * that the MD5 hash of every page has an entry in the "a human
> reviewed this" table
> * etc.
>
> The automated tests that build up over time catch the majority of
> accessibility issues, which allow me to give much more focussed
> attention to the bits that do require a vague approximation of
> actual intelligence.

-- Alain:
Right. Accessibility is a special kind of usability issue that can be
described mostly in the form of machine verfifiable guidelines.
----

An example of (4) would be a workflow I designed that always had one
"happy path" from each stage - the route that most users would follow.

This was highlighted in the visual appearance of each page of the
workflow. The "happy path" button was a different colour and size,
and always appeared before any buttons on the page on the right hand
side.

Now - we already had a system for implementing basic HTML workflows
(a little state transition network glued to some basic templating).
The developers could have just implemented workflows with a "happy
path" using this, styling the default-route buttons appropriately.

The problem with doing this is that none of the design concepts of
the "happy path" route end up in the code. Later on somebody could
implement pages with multiple "happy path" buttons, or ones that are
in the wrong position, or pages with no default route.

So instead we subclass the state transition code and add the
HappyPath concept. We make sure that it's impossible to instantiate
an instance of a workflow that has pages with multiple happy paths,
or no happy path at all.

We subclass the template code so that happy path buttons are
automatically styled appropriately and are only permitted in certain
areas of the page layout. We even make the CSS for the "happy path"
button linked to an id rather than a class so it's impossible to have
more than one on a page.

And of course, since we developed using TDD, we have automated tests
that will break if somebody comes along later and tries to change the
code to break those design decisions.

This is why it's so vital to help the development team understand the
underlying decisions behind the design of the user experience. If the
developers don't see or understand them then they never get embedded
in the code. If they don't get embedded in the code they won't get
automated tests. If they don't get automated tests they'll get broken
later in the project.

Make vague sense?

-- Alain:
Definitely. Basically, both the accessibility example and this workflow
example use strong stylistic guideline as a means to improve usability.
I think that's a great improvement over having to do everything
manually.

But I have a feeling that this kind of technique only touches the
surface level usability issues, and I suspect those are not necessarily
the more important ones.

Here's an example of something I did that caused an unintentional
decrease in usability, which I don't think could be spotted
automatically.

I do a lot of work on wikis, and have developed a wiki clone called
LizzyWiki. In the early wikis, the way to create a link to another page,
was simply to type the page name LikeThis (i.e. like a class name). This
was fairly intuitive to most users, but it meant that users did not have
control over the capitalisation of the words in the link. So I modified
LizzyWiki so that users could create a page using any capitalisation
they wanted like: SomePage, somePage, some_page, SOME_PAGE, etc...

Users were happy about this and started using it almost immediately. But
down the line, we ran into a problem where people couldn't remember what
capitalisation convention they had used to create a page. They knew the
page was called "some page", but they didn't know if it was written
SomePage, some_page, etc... By giving users a way to control
capitalisation of page names, I had suddenly made a focal task (pointing
to an existing page) much harder. It took me a couple of weeks before
realising that this had happened. The unit tests for link creation of
course did not spot that, because they were written in such a way that
they always used to correct capitalisation. Once I realised the problem,
it was easy to fix (I just made link matching case insensitive), but it
made me uneasy about improving usability for one task, and not knowing
if that decreases usability in other tasks.
----







----

Does anybody else have more examples - alternate techniques?

Cheers,

Adrian




Yahoo! Groups Links

---

From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of Frank Maurer
Sent: Tuesday, September 05, 2006 10:41 AM
To: agile-usability@yahoogroups.com
Subject: RE: [agile-usability] What is the the One UX book to read?

The inmates book certainly is a nice read but it heavily steps on the toes of developers. Then there is the 

message that users do not know what they need but need the help of interaction designers/usability specialists to

tell them that. I'm always surprised how a community that is so much focused on people interactions

can so strongly stump on the feet of the two key stakeholder groups of the software development process ;-)

Maybe that is the reason why usability approaches take so long to be adopted in industry while agile methods

seem to be very quick to cross the chasm.

 

Frank

Sure there's a lot in the anti-developer message that get from the
book I disagree with - but there's also a heck of a lot of useful
stuff in there too.

-- Alain:
Actually, even if you are able to make abstraction of the anti-developer
rethoric, the actual message is also very irritating to developers,
especially agile ones.

For example, Cooper is very clear that:

- Developers should take NO part in designing the interaction or
gathering requirements. They should not even be present in the room when
U* people do their stuff with clients.

- Once U* people have designed the interaction structure of the system,
developers should implement it EXACTLY AS IS.

That's about as anti-agile as you can get. Not surprisingly, Cooper
complains bitterly in the introduction to his book that most of his
team's beautiful designs never get implemented. That tends to happen
when you design things without consulting thowe who will eventually have
to build it.

Alain
----

I do think that any developer will be a  better developer with at least some U* knowledge. We can’t be experts in everything, but knowing a little bit of everything (generalists) makes you appreciate the value of having the expert around. I don’t think developers currently have enough U* knowledge to be able to gage the value of U* people.  

In an agile team where U* people are fully integrated, the U* design would come from the whole team like everything else, with most likely greater input from the U* people. Of course, for that to work, the team has to be aware and r e  spect what the U* people bring to the equation. Otherwise, it will likely not even let the U* people contribute.  

-- Alain:

Pascal,

I agree 100% with everything you say above. But that's not what Cooper is trying to encourage with his book. He makes it quite clear that he doesn't  believe that developers CAN acquire U* knowlege or start thinking about the real needs of the end-user. He also makes it quite clear that he doesn't want developers to "interfere" in any way with the U* design process.

Hence, I think that this disqualifies his book as a good U* introduction for agile developers. If you can afford to, just wait for Jeff's book instead ;-).

----

Hi Alain,

On 5 Sep 2006, at 16:36, Desilets, Alain wrote:

> 1) Use heuristics
>
> -- Alain:
> Heuristics as in "heuristic usability assessement"? If so, I'm
> confused,
> because those heuristics can only be applied by humans AFAIK.

Heuristic in the <http://en.wikipedia.org/wiki/
Heuristic#Computer_science> sense.

> If on the other hand you mean some heuristics that can coded so that a
> machine can apply them, can you provide some examples?

Some examples:
* Clean XHTML/CSS validation as a sign that the app will present well
on all browsers
* Using the presence of ALT tags as a sign of accessibility.
* Using a computed "colour contrast" value as a sign of legibility
* Using the Kincaid formula or similar as a sign of readability

None of these things guarantee accessibility or legibility or
readability - but they can help cut out a lot of bad cases early.

> 2) Split the usability requirements up into things you can test and
> things you cannot
>
> -- Alain:
> Presumably you mean "things you can test *automatically* and things
> you
> can only test *manually*", right? ----

Yes.

> 3) Automate the detection of changes that need a human review.
>
> -- Alain:
> Can you give me a concrete example of such a change and how a machine
> would be able to identify it automatically?

1) The system take a snapshot of the HTML/CSS of each page in a web
app whenever somebody commits a change
2) Have a flag you can set on each page once you have reviewed them
4) Automatically notify you when a reviewed page changes, and have a
failing test until you mark it as reviewed again

> 4) Make sure that you're UI concepts are embedded in the code - then
> you're normal automated tests should catch them
>
> -- Alain:
> In my experience, the normal automated tests can test that
> something is
> *possible*, but they can't test that something is *easy to do*. For
> example, the automated tests can verify that it's possible to write a
> new email message by clicking on the "new" button, but it can't test
> whether the label "new" conveys the message to the user that this
> is the
> button to click to write a new message.

No we cannot make a computer say whether an arbitrary thing is
usable. However we can make a computer  spot many of the instances
where a usability design decision that we have made is actually being
implemented correctly.

Getting the computer to do this means we have more time available for
the things that the computer cannot do.

[snip]
>> I'm often involved with testing web sites for accessibility. Now
>> producing an accessible site involves human judgement. There is no
>> automated way to say whether a particular piece of alternative text
>> "makes sense", or that a piece of prose on a link title gives
>> enough information to the user in a particular context.
>>
>> But I /can/ write automated tests that check
>> * all pages pass the WAI WCAG validation suite without fatal errors
>> * all images have ALT attributes
>> * all ALT attributes come from the url/image/alt-text mapping
>> dictionary that I've checked
>> * link text comes from the url/url mapping table that I previously
>> checked
>> * that the MD5 hash of every page has an entry in the "a human
>> reviewed this" table
>> * etc.
>>
>> The automated tests that build up over time catch the majority of
>> accessibility issues, which allow me to give much more focussed
>> attention to the bits that do require a vague approximation of
>> actual intelligence.
>
> -- Alain:
> Right. Accessibility is a special kind of usability issue that can be
> described mostly in the form of machine verfifiable guidelines.

I'd disagree with the "mostly". Lots accessibility issues cannot be
captured by automated tests. However automating all that we can
automate means we have more time to spend on the harder issues.

[workflow example snipped]
> Definitely. Basically, both the accessibility example and this
> workflow
> example use strong stylistic guideline as a means to improve
> usability.
> I think that's a great improvement over having to do everything
> manually.
>
> But I have a feeling that this kind of technique only touches the
> surface level usability issues, and I suspect those are not
> necessarily
> the more important ones.
>
> Here's an example of something I did that caused an unintentional
> decrease in usability, which I don't think could be spotted
> automatically.
[nice example snipped]

Yup. I'm really not trying to say that all usability issues can be
captured by automated tests. They can't (well - not until we get that
whole Strong AI thang off the ground :-)

My point is that there are a bunch of kinds of automation that can
save us time, and that it's really important to make sure that the
usability related design decisions are made as explicit as possible
in the code to prevent later regressions.

Cheers,

Adrian

(As an aside - I find you're way of quoting messages /really/ hard to
read since there are few visual cues on what is quoted text and what
is your comment, and since you don't include the author of the text
you're commenting on. I sheepishly admit that I sometimes skip over
your messages because of this :-)

> > 3) Automate the detection of changes that need a human review.
> >
> > -- Alain:
> > Can you give me a concrete example of such a change and how
> a machine
> > would be able to identify it automatically?
>
> 1) The system take a snapshot of the HTML/CSS of each page in a web
> app whenever somebody commits a change
> 2) Have a flag you can set on each page once you have reviewed them
> 4) Automatically notify you when a reviewed page changes, and have a
> failing test until you mark it as reviewed again

I like that.

Basically, the tool automatically identifies when it looks like some
kind of UI design decision has been made (either intentionally or
unintentionally) and flags it for review.

If I wanted to do this for say, an Eclipse development environment, are
there components I could use to easily implement it?


> (As an aside - I find you're way of quoting messages /really/
> hard to
> read since there are few visual cues on what is quoted text and what
> is your comment, and since you don't include the author of the text
> you're commenting on. I sheepishly admit that I sometimes skip over
> your messages because of this :-)

You know what, you're the second person to comment on that recently, and
that motivated me to snoop around MS Outlook (which is mandatory at my
workplace) to try and figure out how to make message quoting work.

Like you and most people, I like each line of the original message to be
prefixed with a >. There is an option in Outlook for doing that, but I
had tried to use it several times in the past and it never worked. So I
developed this strange style of quoting that you didn't like (and
neither did I).

But I just gave it another try, and this time, it works. Thx for
motivating me to try again.

Adrian Howard wrote:

> Some examples:
> * Clean XHTML/CSS validation as a sign that the app will present well
> on all browsers
> * Using the presence of ALT tags as a sign of accessibility.
> * Using a computed "colour contrast" value as a sign of legibility
> * Using the Kincaid formula or similar as a sign of readability

  * Use pure XHTML, so all that's accessable to the testage
  * Run the site's pages thru Tidy and ask if it's accessible

Those tests sound weak, but some GUIs must internationalize and
localize correctly. Users of some rare language are probably familiar
and tired of the same dumb bugs in their GUIs. So switch to each
language and run all those tests again.

Next, do it even if your GUI is not HTML. MS's RESX files are of
course parsable as XML. I wrote

http://www.c2.com/cgi/wiki?MsWindowsResourceLint

to scan the localized RC files looking for bugs. The program has an
extensible framework so you can add in any kind of test you can think
of.

(At SYSTRAN, I spent a week writing the predecessor of that program. I
didn't notice they didn't nano-manage me during that week because they
were preparing to fire me. So when they did, my last act was to send
to all their executives a complete, automated report describing every
usability issue in every supported locale of every product, with
instructions how to run it again as part of their test server. The
total error count was >4k, in a company that's supposed to do
localization as a core competency!)

> 1) The system take a snapshot of the HTML/CSS of each page in a web
> app whenever somebody commits a change
> 2) Have a flag you can set on each page once you have reviewed them
> 4) Automatically notify you when a reviewed page changes, and have a
> failing test until you mark it as reviewed again

That is a technique under the umbrella I call "Broadband Feedback".
However, marking the test as failing is unfair to programmers, who
just want to check in an innocent change that doesn't break anything.
Move the "reviewed" flag from the bug collumn to some other collumn!

To achieve Broadband Feedback, automate the steps. The reviewer should
simply turn on a web interface that displays each changed GUI, and
reviews the change in the website - not necessarily in the target
program. That's why I wrote this:

http://www.zeroplayer.com/cgi-bin/wiki?TestFlea

(Click on a green bar.)

Imagine if you were the Sanskrit linguist for a project. Wherever you
are (even up a mountain in Nepal), you the project's web site. You get
a page like that; maybe it contains only unreviewed items, or maybe
unreviewed items have a grey spot next to them.

You inspect each GUI, verifying it uses correct Sanskrit, then you
switch the record to Reviewed.

For more complex usability needs, a test batch could also upload
animations of the program in use.

> No we cannot make a computer say whether an arbitrary thing is
> usable. However we can make a computer spot many of the instances
> where a usability design decision that we have made is actually being
> implemented correctly.

The adoption of Agile techniques in the game industry, today, is at
about the same place as Agile adoption was in business 6 years ago.
One common FAQ (unanswered even on many game projects) is this:

   if the highest business value feature is Fun, how can you
   write an acceptance test for that?

The answer is the same as for any other untestable property (security,
robustness, availability, usability, fault tolerance, etc.). Fun is a
non-functional requirement that generates many functional
requirements, each of which can be tested.

In games, that requires designers to occupy the Onsite Customer role,
and author their scenarios as scripts that test a game automatically.
A scenario should run a hero thru a level and ensure they kill every
monster.

Next, games are very dynamic and emergent. A change to a Maya file
here can cause a bug, or a lapse of Fun, in game levels over there.
One way to preserve Fun without locking down every file is to use Gold
Master Copy tests on aspects of a game's internal details.

For example, two runs thru the same scenario should generate the same
log file. A programmer could change the code in an innocent way,
changing the log file without afflicting Fun. But these tests should
run as often as possible, so the programmer will revert their change,
then make a _different_ innocent change which might work.

These kinds of tests can't even easily pinpoint bugs, so run them as
often as possible, so the cause must be the most recent edit. Treat
these tests as seismograph readings, of earthquakes deep beneath the
surface.

--
   Phlip
   http://c2.com/cgi/wiki?ZeekLand  <-- NOT a blog!!

[ Sorry for any duplicates -- Jared ]

Greetings,

I go to 20+ conferences a year and while many of the conferences have
excellent programs, I often find myself learning the most from the
after-hours activities. Often, these activities happen in bars, with a
group of like-minded, extremely bright people. No specific agenda is
on the table, yet somehow, the conversation turns out to be fun,
thought provoking, and interesting.

Inspired by some excellent podcasts I listen to regularly, I thought
we could reproduce the fascinating discourse I've experienced at these
non-official conference events for everyone's benefit. I contacted
some folks who I thought would make great conversation and, to my
surprise, they all jumped at the chance to partake in our little
experiment.

  From this was born the first SpoolCast. It's a 90-minute recording of
fascinating conversation on topics of user experience, usability, and
design.

Joining me for the first SpoolCast are:

+ DeWayne Purdy from the University of Northern Iowa
+ Kyle Pero from UsableInterface.com
+ Lyle Kantrovich from Human Factors International
+ Rashmi Sinha from Uzanto
+ Nate Bolt from Bolt|Peters

In this inaugural recording, we discuss:

+ What can we learn from the new Brown University web site?
+ What does it mean to be usable?
+ Why is MySpace so successful?
+ Which is better designed, the new Brown Web Site or Craigslist?
+ How important is the design of a home page? (I think not so much.
    Everyone else disagrees.)
+ The value of social networking
+ The UPA Body of Knowledge project
+ The design experience, as it applies to conference design

I've divided the recording into four parts, to make it easier to
listen to during your commute or while you're out doing errands.
(Alternatively, you can just listen on your computer.)

The first part of the SpoolCast is available at
http://tinyurl.com/qe3ks

The other parts are available in the Brain Sparks Audio Library:
http://www.uie.com/audio

The transcript for this first session is available at
http://tinyurl.com/fydka

If you use an RSS reader or iTunes, you can subscribe to our podcast
feed: http://www.uie.com/podcast/ (This way you'll be notified when
future SpoolCasts are available.)

I hope you enjoy listening as much as we enjoyed recording it.

Jared M. Spool
Gang Leader, SpoolCast Crew

On 6 Sep 2006, at 15:47, Desilets, Alain wrote:
[snip]
>> 1) The system take a snapshot of the HTML/CSS of each page in a web
>> app whenever somebody commits a change
>> 2) Have a flag you can set on each page once you have reviewed them
>> 4) Automatically notify you when a reviewed page changes, and have a
>> failing test until you mark it as reviewed again
>
> I like that.
>
> Basically, the tool automatically identifies when it looks like some
> kind of UI design decision has been made (either intentionally or
> unintentionally) and flags it for review.

Yup. You can make it more useful by making the snapshots only focus
on "interesting" things (e.g by ignoring boilerplate text that
changes often, or by having more focussed reviews on components
rather than the whole app (e.g. translation text.)

Things to be careful of:
* the review process becoming a bottleneck
* the review process becoming an excuse for not educating the team
* the review process becoming an excuse to stop writing automated
tests, or avoid getting the UI concepts into the code

> If I wanted to do this for say, an Eclipse development environment,
> are
> there components I could use to easily implement it?

No idea. I don't spend much time in the Java/Eclipse world. We've
hand rolled stuff to do the job.

[quoting stuff snipped]
> But I just gave it another try, and this time, it works. Thx for
> motivating me to try again.

Thanks!

Cheers,

Adrian

Hi All;

I invite you to join "Software Requirements Engineering" yahoo group.

Post message: Requirements-Engineering@yahoogroups.com

Subscribe: Requirements-Engineering-subscribe@yahoogroups.com

http://groups.yahoo.com/group/Requirements-Engineering



To share your experience about req. engineering, please join us.

Best regards,

Kasim Sen
Moderator

I'm suprised no one's posted about this yet:

http://seattlepi.nwsource.com/business/283686_software04.html

This is an article about the office space that the Microsoft Mobile
Devices UXP team is moving into and how it will aid and inform their
design process. What they describe seems like it was pulled directly
out of the Agile playbook, although they're not using it for Agile
development. To me, this says that Agile techniques may have more
benefits for UXP design/process in addition to speed...

Thoughts?

- Fred

Hello Everyone,

Diaspar Software, ProjectSuccess, GreenPepper™ and Pyxis are proud to
present our 3rd installment of the XP Day North America series, XP Day
Montreal 2006. XP Day is a one-day extreme programming conference to
be held in Montreal, Quebec September 23, 2006.  For more information
see below, but for those who prefer browsing a website instead of
reading plain text, visit: www[dot]xpday[dot]info.

If you are looking for an opportunity to learn more about Extreme
Programming without having to spend an entire week at a large
international XP conference, XP Day Montreal fits the bill.  XP Day is
a one-day event with activities for anyone interested in Extreme
Programming, whether you're:

* An executive wondering how to improve your software development
team's ROI.
* A manager looking for ways to increase your team's effectiveness.
* A skeptic, hoping to challenge some of the most experienced and
outspoken XP practitioners.
* A programmer itching to experience a real XP project room.
* An experienced practitioner, hoping to exchange ideas or experiences
with other practitioners.

For those of you who missed out on Agile 2006, this would be an
excellent opportunity to meet, attend tutorial sessions and even work
with some of the XP community's most notable practitioners, for a
fraction of the cost.

XP Day events are interactive!
- Tutorials
We are fortunate to have respected leaders of the XP community
providing world-class instruction and discussion on the fundamentals
of XP.

* Laurent Bossavit, keynote and recipient of the 2006 Gordon Pask
award for contributions to the agile community. Laurent's keynote
address is entitled "They do things differently there" wherein we will
speak of cultural gaps, ways to bridge them, and why that is relevant
to the software industry.

* Michael Feathers will also provide a tutorial entitled "API design
as if testing mattered" to show how API design can be adapted to make
software more testable."

* J.B. Rainsberger, recipient of the 2005 Gordon Pask Award, will
provide an "Introduction to XP" tutorial.

- Open Space
You can collaborate intensively with both local and invited advanced
practitioners on issues that challenge you most. If the tutorials
don't cover it, you can work through your burning questions in Open Space.

- Panel Discussion
We are pleased to offer a panel discussion entitled "Your customer is
more important than you think". Laurent, Michael, JB, Francois
Beauregard and Dave Rooney will discuss why an involved customer is
critical to the success of your software projects.

- Project Room
If you're looking to dive in and immerse yourself in XP, join the XP
Project Room, where you'll have the opportunity to work on project
with respected experts. Not sure what's going on? No problem! Join the
project any time and someone will bring you up to speed quickly, just
like on a real XP project!

- Cost
XP Day is only $249 CND + GST (7%). Our conference cost includes a
morning breakfast and a hot Indian buffet for lunch.  For those with
more domestic appetites, sandwiches will also be on hand. Coffee &
Soft Drinks will also be available throughout the day.

If you're looking for more information or would like to register,
visit our website: xpday[dot]info

If you have any questions with regards to this event, please don't
hesitate to contact me at the email address listed above.
Hope to see you all there!

Niraj Khanna
XP Day Montreal.

P.S. To the moderator of this group, please support XP Day by allowing
2-3 additional posts on this group.  Thank you.

> My imp got an iPod nano.

> How do I copy MP3 files into it (from PC)?

Now if iPod was invented by the greatest usability experts in the world, why
should a GUI specialist have to ask such a question?

At least I wasn't asking "where's the Delete key on my Mac?"...

Here's what was happening. To get the iPod icon in the iTunes interface, you
have to plug in the iPod, and let its driver raise iTunes automatically.

This means when my Imp wants to charge her iPod, I have her plug it into a
computer without iTunes installed. Because when iTunes pops up, it switches
the desktop preferrences (without permission) so all my MP3s and online
radio run in iTunes.

Oh, and it changes them for every user, not just the currently logged in
user. And it changes them each time, not just the first time it runs.

Then, to add insult to attrocity, if the iPod is registered to one user (my
Imp), and I plug in the iPod while another user is active (me), the iPod
pretends it thinks I'm trying to "borrow" the tunes locked in its storage,
and it offers to switch ownership to me and erase the iPod.

Focus on the line "pretends it thinks". That's what it's all about, folks.
Ripping people off under the excuse you are preventing them from ripping you
off.

--
   Phlip
   http://www.greencheese.us/ZeekLand <-- NOT a blog!!!

> > My imp got an iPod nano.
>
> > How do I copy MP3 files into it (from PC)?
>
> Now if iPod was invented by the greatest usability experts in
> the world, why
> should a GUI specialist have to ask such a question?

Yep. Now buy a new computer and see how long it will take you to
transfer your iPod songs to that new computer. Took me the better part
of a day to do it, hunting around in various forums and mailing list.
The solution involved copying all my iTunes files to an external HD,
then copying them to the new computer, and then registering the new
computer so that it could use tunes from my iTunes account.

So much for Apple Usability. I must admit thouh, Napster is no better
either, as I have ranted about previously on this list.

Alain

Desilets, Alain wrote:

> Yep. Now buy a new computer and see how long it will take you to
> transfer your iPod songs to that new computer.

But.. but you might be STEALING those songs!

(Put another way, iPod's number 1 customer is the RIAA, not you!)

Then a Mac-rophile visits and sees my music library, stored as, uh,
files, and the first thing he asks is "why aren't you using iTunes",
as if the choice was obvious. (Like "Why aren't you usind TDD?")

Sigh...

--
   Phlip
   http://c2.com/cgi/wiki?ZeekLand  <-- NOT a blog!!

On 11 Sep 2006, at 14:29, Phlip wrote:
[snip]
> Then a Mac-rophile visits and sees my music library, stored as, uh,
> files, and the first thing he asks is "why aren't you using iTunes",
> as if the choice was obvious. (Like "Why aren't you usind TDD?")
[snip]

Don't get be started on the iPod's modal volume control :-)

To bring this vaguely on topic...

Would an agile approach have built a better product?

Adrian

joe_dickason wrote:

> If there is a "Maintain Addresses" user story

What if that story were too big?

If you split the story into a low- and high-value part, usability must
survive that split. You can't put addresses in the database without at
least giving them a data entry field on the screen, and an output
somewhere.

The act of splitting a story is a form of analysis and design. The
team might agree that "maintain addresses" is a done deal. We have all
done the name-and-address thing before (some of us in Sanskrit! See
below).

If the story splits, however, the usability that goes with the
high-value feature must itself be high-value usability. So let's push
these two out of the iteration:

> - sort the list be begin date descending
> - display the primary address as bold and green.

The current iteration must target names and addresses, but no dates,
and no list. Further, the system only stores a primary address,
without any secondary ones.

> Are the decisions and mock-ups just documented in whatever form they
> occur – like a whiteboard diagram with notes all of over it?

They could, but my narrative shows the usability decisions stretching
out in time. The next iteration could require those lower-value
features, or other supporting features.

> Should
> all of this information be reflected through the user acceptance
> tests of the story?

Unfortunately yes. Otherwise, allowing usability to incrementally grow
could expose your GUI to the risk of unforseen changes. Users don't
like usability to change so easily.

> I know that it wouldn't be documented in a full-blown Functional
> Specification, but I wonder how do all the decisions in a 30 minute
> design meeting get noted to ensure everyone gets all the parts
> developed and tested.

All projects start with Community Agreements and Motherhood Stories,
describing what level of detail and sophistication are expected to go
with each story. Some projects are performance-driven, and others are
GUI-rich, for example. So these 30-minute meetings simply refer out to
many more minutes of actual learning and debate.

> Are there books and/or web articles that
> answer these types of questions?  I also read Extreme Programming
> Applied, but it didn't address my questions directly.

This draft focusses on the coding and acceptance tests aspects, but
not the usability itself:

http://www.zeroplayer.com/cgi-bin/wiki?TestFirstUserInterfaces

For the usability side, try /Designing Interfaces/ by Jenifer Tidwell.

--
   Phlip
   http://c2.com/cgi/wiki?ZeekLand  <-- NOT a blog!!

All:

I'm looking for some examples of companies where User Centered Design
practices have been cohabitating in an Agile context for some time,
and where you'd consider your approach to be reasonably successful.

Examples I know of and cite fairly often are Alias, LanDesk, & Yahoo.

If your company has been using what you'd consider to be both a fairly
rigorous Agile approach, and a fairly rigorous design approach [by
design I mean the outside of the software] could I have an hour of
your time over the phone to ask a few questions?  If you can spare the
time, please contact me off list and we'll arrange time to talk.

Thanks in advance.

-Jeff Patton
jpatton@...