On Sat, 2004-07-31 at 04:26, Ron Jeffries wrote:
> I have in recent months encountered two or three people who didn't know
> that when you are in a pull-down state box, and trying to get to, say,
> Michigan, you don't type MI, you type M, M, M until you get the one you
> want. They were all delighted to learn this.

That's an interation idiom I'm a little suspcious of; it only works when
users are dealing with a fixed list of choices that they're very
familiar with. It makes me crazy that Windows doesn't just let me type
MI, acting as if what I really meant was to dart briefly to the first M
listing and then jump back to the first I listing.

Happily, I see that Mozilla is smart enough to support both modes.


William

--- In agile-usability@yahoogroups.com, "Larry Constantine"
<lconstantine@f...> wrote:
> I think you both might have misunderstood something. First, an
interaction
> context is not a metaphorical place, its an abstraction of a part
of the
> user interface. That is, an interaction context is an abstract
piece of the
> real user interface--such as a window, page, screen, or tab panel--
with the
> particular realization left unspecified. There is nothing
metaphorical about
> it.

I think we're in agreement - but my use of english may be a bit
imprecise.  When explaining it to others, I like them to think of the
house metaphor or a workbench metaphor - a physical place with
furniture or tools lined up to complete tasks.  I like them to think
of navigation as the act of walking from room to room - and long
navigation paths as long hallways.  In my original post, I use people
washing a baby in the kitchen sink to metaphorically hint that people
use software in ways unanticipated by its original designer.  So,
while the interaction context may be an abstraction for part of the
user interface, I find using metaphor to describe it helpful.  Then I
start getting lost in my own metaphor and mix up my terminology... ;-)

> I agree with Josh that goal-directed design might be improved by a
more
> explicit incorporation of interaction contexts, but personas, which
model
> users rather than interfaces or parts of interfaces, are certainly
not used
> in this manner by most people I know doing what they think is goal-
directed
> design. Personas in GDD stand in for user roles in usage-centered
design.
> User roles are just a different slicing-and-dicing of what we need
to know
> about users.

There's where the physical place metaphor starts to work.  If a
particular persona "walks into" a particular interaction context,
what information and tools would they see there?  Personas share
contexts as people share rooms.  In my kitchen are fridge, sink,
oven, and playskool little people zoo.  The people using the kitchen
are me, my wife, and my 2 year old.  We try to make it a friendly
place for all of them.  I find that thinking of the user interace of
software the same way helps me design - and understanding the
difference between people and places - people being external to the
software places being the software itself - understanding that helps
me design software that stands up to change a little better.

The interaction context as the notion of a place wher tasks are
executed is a pretty helpful thing.  I've seen lots of software
that's very task-centric - different context for each task.  I've
seen lots of software that's unaware of the different kinds of people
interacting with it.  I've seen lots of software that makes
navigation from one context to another more difficult than it should
be given the usage - akin to placing the master bath down the hall
from the master bedroom.

I digress - I mostly wanted to admit I'd use metaphoric wrong in my
original post - but defend and encourage the use of the term in
regards to the interaction context.

thanks for posting Larry!

-Jeff

-- jon

-----Original Message-----
From: Larry Constantine [mailto:lconstantine@...]
Sent: Saturday, July 31, 2004 5:49 PM
To: agile-usability@yahoogroups.com
Subject: RE: [agile-usability] Mouse Abuse [Was: Designing for incremental delivery vs. big-bang delivery]

I have been following this thread while doing a training this week with
barely time to read much less reply. I'll respond to several different
postings in one rush.

Keyboard "shortcuts" like <Tab> to go to next field or <Alt>+<Tab> to switch
windows are interaction idioms (yet another useful Alan Cooper coinage).
Like idiomatic expressions in ordinary language, they do not really make
sense but have acquired meaning through conventional association that has
little or no relationship to their literal meaning (if any). They are not in
any reasonable sense intuitable.

Supporting <Tab> and <Shift>+<Tab> is an absolute requirement for all
Windows apps and Web forms not only because it’s the standard but because
many (though certainly not all) users expect it. The ones who don't know
about or expect it are unaffected but the ones who routinely rely on it are
deeply affected if you don't do it or do it right. Getting it right is more
than just supporting field-to-field tabbing but supporting it in a way that
enhances usability, which means getting the right tab order that makes sense
with the likely use of fields, sequencing vertically or horizontally
depending on the workflow and how user thinks of the fields, planning the
right field behavior onfocus and onblur, etc. For some users (heavy
keyboarders, production staff, etc.) in some applications, these details can
make as much as 40-50% difference in end-to-end productivity.

Back to Jeff's original post, the preference for keyboard or mouse is not
only an individual trait but it is heavily conditioned by context. Some
evidence suggests that, aside from habit and manual skills, users shift
between mousing and keyboarding to fit how they see the immediate task or
the upcoming one. (For example, changing from one idiom to the other when
they reach the bottom of a screen with content "below the fold.")

Contrary to the claims of keyboard fanatics and the now largely discredited
early Apple research, one technique is not necessarily or universally faster
than the other. In general, most people can type successive keystrokes
faster than a move-to-mouse, saccade-and select, move-back, but this is not
always the case nor is it the whole story. For example, all but highly
trained clerks doing repetitive heads-down data entry make a distinct
(sometimes fairly long) pause at the end of entering each field anyway
during which they typically reread what they have typed, confirm its
content, form the intent to move on, mentally select the method (interaction
idiom), and execute it. In most work contexts where there is not high volume
input, the impact of the user choosing the "wrong" idiom is minimal.

In any case, as interaction designers (or developers subbing in as
interaction designers) we have a responsibility to understand our users and
the context of use. Responding to the Phlip remark about expecting keyboard
competence and weaning users off help, we always have to see the
"time-and-motion" thing in the larger context. In a POS app, the total
number of fields and user steps per customer is typically relatively modest.
The savings of seconds here or there through keyboard rather than mouse
operation will be unlikely to have much impact on the length of the queue.
Far more important is presentation and interaction design that reduces the
chance of error and that promotes rapid learning and acquisition of skill
(high turnover means many users will be still ramping up). Just one need for
a supervisor void can cancel out the gains from thousands of keyboard-only
steps. Or consider the user typing-and-tabbing at a snail's pace because
they are trying to figure things out on a poorly conceived screen. Or the
clerk flumuxed by a message that makes no sense....

As we consultants say, it all depends. By exquisite attention to what nurses
actually do when charting and managing patient care, right down to shaving
milliseconds here and there, we and the crack team at McKesson were able to
speed these tasks by almost 50% while cutting training time to a fraction of
what it was.

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

-- jon

-----Original Message-----
From: Larry Constantine [mailto:lconstantine@...]
Sent: Saturday, July 31, 2004 5:49 PM
To: agile-usability@yahoogroups.com
Subject: RE: [agile-usability] Re: principles for UI architectures

Jeff and Josh,

I hate to jump on two such good friends and colleagues in one positing, but
I think you both might have misunderstood something. First, an interaction
context is not a metaphorical place, its an abstraction of a part of the
user interface. That is, an interaction context is an abstract piece of the
real user interface--such as a window, page, screen, or tab panel--with the
particular realization left unspecified. There is nothing metaphorical about
it.

I agree with Josh that goal-directed design might be improved by a more
explicit incorporation of interaction contexts, but personas, which model
users rather than interfaces or parts of interfaces, are certainly not used
in this manner by most people I know doing what they think is goal-directed
design. Personas in GDD stand in for user roles in usage-centered design.
User roles are just a different slicing-and-dicing of what we need to know
about users.

All that said, from an architectural standpoint, there is sometimes a fairly
simple connection between personas and the target user interface
architecture in that, if you are designing to multiple personas, you do want
all the needs of each persona to be supported by a closely coupled
collection of interaction contexts.

Cheers friends,

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


> -----Original Message-----
> From: Joshua Seiden [mailto:joshseiden@...]
> Sent: Saturday, 31 July 2004 7:18 AM
> To: agile-usability@yahoogroups.com
> Subject: RE: [agile-usability] Re: principles for UI architectures
>
>
> > > I'm wondering if there
> > > are some principles for UI architectures, similar
> to
> > > modularity in design, that facilitate the
> evolutionary
> > > development of the HLD parts, rather than requiring
> a
> > > "full scope" pass up front?
> > > --->
> > > This is an interesting notion that I haven't seen
> mentioned before.
> > > Anyone have any leads on this?
> > >
> > Here's what makes high level design more resilient
> for me:
> >
> > I'm using C&L's Usage-Centered Design.  They describe
> an interaction
> > context.  An interaction context is a metaphoric
> place you go to do
> > similar tasks.
>
> Cooper's goal directed design system uses personas in
> this manner. Interaction contexts, as you describe them
> Jeff, don't exist as a named entity in this system, but
> instead are implied by the notion of a primary persona.
> GDD would be improved, I suspect, by stealing this
> notion of interaction contexts.
>
> JS
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>

-- jon

-----Original Message-----
From: acockburn@... [mailto:acockburn@...]
Sent: Saturday, July 31, 2004 5:25 PM
To: agile-usability@yahoogroups.com
Subject: [agile-usability] http://c2.com/cgi/wiki?SystemsPersonalities

I started this discussion at

http://c2.com/cgi/wiki?SystemsPersonalities

and would enjoy anyone from this list either joining the wiki or discussing it here

 

==============================================
Alistair Cockburn
President, Humans and Technology

Phone: 801.582-3162            Fax: 775.416.6457
1814 E. Fort Douglas Circle, Salt Lake City, UT 84103
mailto: acockburn@...
http://alistair.cockburn.us/

Author of
"Surviving Object-Oriented Projects" (1998)
"Writing Effective Use Cases" (Jolt Productivity Award 2001)
"Agile Software Development" (Jolt Productivity Award 2002)

"La perfection est atteinte non quand il ne reste rien a ajouter,
mais quand il ne reste rien a enlever." (Saint-Exupery)
==============================================

-- jon

-----Original Message-----
From: Gary [mailto:macomber@...]
Sent: Saturday, July 31, 2004 6:12 PM
To: agile-usability@yahoogroups.com
Subject: Re: [agile-usability] Re: Mouse Abuse [Was: Designing for incremental delivery vs. big-bang delivery]

One place I worked could serve as the poster child for non-agile UI
Guidelines work.  They spent a couple of years trying to put together a
set of UI Guidelines, starting from some arbitrary point and going to
they completed everything.  Meanwhile, those of us working with
Development had to pretty much make stuff up to meet the current
questions, get the UI group to approve, convince Development, iterate.
Then they might actually come out in the unwieldy, pretty much unusable
guidelines, at some distant point in the future - so they may or may not
have been known to other groups...

Have you had any luck "sanitizing" the negative examples so they portray
the kernal of the issue without the trappings of the specific real-world
example?

I'm a strong believer in just-in-time specific guidelines within a
general framework.  Deal with today's questions, there usually are
enough of them.

gary


Ron Vutpakdi wrote:
> --- In agile-usability@yahoogroups.com, Gary <macomber@s...> wrote:
>  > I'm curious, are you tailoring the tip sheets to the critical issues
>  > they are dealing with at the time?
>
> Where possible, yes, and if a developer has a specific question that
> is of general interest, I'll make a tip sheet out of it (albeit partly
> because I need ideas for decent tip sheets).
>
> I do stay away from negative examples unless they are so generalized
> that people are highly unlikely to interpret the example as a directed
> attack on their baby.
>
>  >
>  > Once had a very good Developer tell me that if the UI style guide
> (for a
>  > product line) was more than a few pages and didn't consist of annotated
>  > pictures it wouldn't get used.
>
> Unfortunately, the longer something is, the less likely people are
> going to read pretty much anything unless they're interested in the
> topic or they're required to read it.  Just a human tendency, I think.
>
> Ron
>

-- jon

-----Original Message-----
From: William Pietri [mailto:william@...]
Sent: Sunday, August 01, 2004 3:45 AM
To: agile-usability@yahoogroups.com
Subject: Re: [agile-usability] Mouse Abuse [Was: Designing for incrementaldelivery vs. big-bang delivery]

On Sat, 2004-07-31 at 04:26, Ron Jeffries wrote:
> I have in recent months encountered two or three people who didn't know
> that when you are in a pull-down state box, and trying to get to, say,
> Michigan, you don't type MI, you type M, M, M until you get the one you
> want. They were all delighted to learn this.

That's an interation idiom I'm a little suspcious of; it only works when
users are dealing with a fixed list of choices that they're very
familiar with. It makes me crazy that Windows doesn't just let me type
MI, acting as if what I really meant was to dart briefly to the first M
listing and then jump back to the first I listing.

Happily, I see that Mozilla is smart enough to support both modes.


William

-- jon

-----Original Message-----
From: acockburn@... [mailto:acockburn@...]
Sent: Friday, July 30, 2004 6:52 PM
To: agile-usability@yahoogroups.com
Subject: [agile-usability] Re: Designing for incremental delivery vs. big-bang delivery

Alistair,

would you mind telling a story I've heard you tell before about an
application written using use cases.  It was built, things seem to be
fine until you discovered the users were often interrupted and the
work needed to be set aside.  You guys had big UI impact to support
that.  I think you know the story.  That's the sort of environmental
condition Charlie is talking about.  It'll be a better story if you
tell it.

thanks,
-Jeff

--->

 

Well, it was actually a little different from that (the only story I can think of

along those lines...)

 

It was a client-server app, second delivery cycle (3-month delivery cycles), and it was taking, at that stage, around 5 seconds round trip to the database.  We had the rule that we had to show the app to a real, expert user twice before delivering, so we did it at about the 6 and 9 week marks.

 

This particular tried the thing out and said, "Will it always take that long?"

We said, "Well, it will be tuned to be a bit faster, but basically, yes, why?"

She said, "Well, in this case, I'm only typing in lists of damaged goods we donate

to charity, so it's a heads-down typing job --- I never look up, just type in from pages of

printout.  If I have to wait 5 seconds for each one, I'll never get done."

We, shocked, asked, "What about typing errors?"

She said, "It only is used for tax-deduction purposes, so if there are a few typos, it really

doesn't matter. What matters is that I can type heads-down."

 

We were, of course, shattered by this news, and had to redesign that section of the app

so that no trips to the server entered into her typing loop.

 

that's the story I have --- Alistair

-------------------------------------------------------------------------------------
--- In agile-usability@yahoogroups.com, "Charlie Trainor"
<charlie.trainor@c...> wrote:
The reason I argue for going to the user rather than inviting them
in, is
that in "real life", people have interruptions, noisy surroundings,
colleagues asking questions, other applications running on their
computer,
and so forth.  If (and this is a big if) you can do your usability
testing
in such a real environment, you are better off.  This is true even at
early
stages of design, when you are checking out basic metaphors and
models for
structuring the product.  Many products do fine under ideal
conditions when
the user can focus, but don't provide the user enough guidance and
context
(and graceful handling of strange user behaviour) to support
suboptimal
conditions. 

- Charlie
--- End forwarded message ---

-- jon

-----Original Message-----
From: Adam Carter [mailto:a.carter@...]
Sent: Saturday, July 31, 2004 1:43 AM
To: agile-usability@yahoogroups.com
Subject: Re: [agile-usability] Mouse Abuse [Was: Designing for incremental delivery vs. big-bang delivery]

Randy MacDonald wrote:
> I thought the Windows GUI standards meant one didn't have to tell users
> what Tab means.

How many users read GUI standards?

Adam

-- jon

-----Original Message-----
From: Gary [mailto:macomber@...]
Sent: Saturday, July 31, 2004 9:02 AM
To: agile-usability@yahoogroups.com
Subject: Re: [agile-usability] Mouse Abuse [Was: Designing for incremental delivery vs. big-bang delivery]

Hi,

On my laptop keyboard there are 2 arrows - 1 pointed left, 1 pointed
right, now which way did they go?   ;-)

gary

Phlip wrote:
> Adam Carter wrote:
>
>  > ...I don't
>  > think there is anything
>  > intuitive about pressing the tab button to change
>  > fields, unless of
>  > course you already know about it.
>
> There's a little arrow -->| on the key cap.
>
>
> =====
> Phlip
>   http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
>

-- jon

-----Original Message-----
From: Adam Carter [mailto:a.carter@...]
Sent: Saturday, July 31, 2004 3:47 AM
To: agile-usability@yahoogroups.com
Subject: Re: [agile-usability] Mouse Abuse [Was: Designing for incremental delivery vs. big-bang delivery]

And? Isn't that the indent symbol from typewriters? How does that make
it intuitive to change focus? If anything the intuitive use for tab
would be indenting text not moving from one field to the next.


> There's a little arrow -->| on the key cap.
>
>
> =====
> Phlip
>   http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces

-- jon

-----Original Message-----
From: Randy MacDonald [mailto:randy@...]
Sent: Saturday, July 31, 2004 10:27 AM
To: agile-usability@yahoogroups.com
Subject: Re: [agile-usability] Mouse Abuse [Was: Designing for incremental delivery vs. big-bang delivery]

I expect that behavior if the pulldown has an edit field on top, but am suprised when it doesn't have an edit field, when the list focuses on funny places, which are perfectly sensible if I recall my most recent keystrokes, which is what the edit field does for me.

 

As another example, I get to "LONDON" in a list of cities by pressing "M" then a series of Up's.

----- Original Message -----

From: Ron Jeffries

To: agile-usability@yahoogroups.com

Sent: Saturday, July 31, 2004 7:26 AM

Subject: Re: [agile-usability] Mouse Abuse [Was: Designing for incremental delivery vs. big-bang delivery]

On Saturday, July 31, 2004, at 12:17:33 AM, Randy MacDonald wrote:

> I thought the Windows GUI standards meant one didn't have to tell users what Tab means.

It's odd and fascinating how few end users have read the Windows GUI
standards, and how even fewer have understood them. :)

I have in recent months encountered two or three people who didn't know
that when you are in a pull-down state box, and trying to get to, say,
Michigan, you don't type MI, you type M, M, M until you get the one you
want. They were all delighted to learn this.

Ron Jeffries
www.XProgramming.com
Writing code is not an exercise in manliness.  -- Mark Hahn

----- Original Message -----

From: Jon Kern

To: agile-usability@yahoogroups.com

Sent: Sunday, August 01, 2004 10:40 AM

Subject: RE: [agile-usability] Mouse Abuse [Was: Designing for incremental delivery vs. big-bang delivery]

what's a type writer?

 

something that spits our Integer, Double, Currency, BigDecimal, HashTable?

 

-- jon

-----Original Message-----
From: Adam Carter [mailto:a.carter@...]
Sent: Saturday, July 31, 2004 3:47 AM
To: agile-usability@yahoogroups.com
Subject: Re: [agile-usability] Mouse Abuse [Was: Designing for incremental delivery vs. big-bang delivery]

And? Isn't that the indent symbol from typewriters? How does that make
it intuitive to change focus? If anything the intuitive use for tab
would be indenting text not moving from one field to the next.


> There's a little arrow -->| on the key cap.
>
>
> =====
> Phlip
>   http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces

----- Original Message -----

From: Jon Kern

To: agile-usability@yahoogroups.com

Sent: Sunday, August 01, 2004 10:40 AM

Subject: RE: [agile-usability] Mouse Abuse [Was: Designing for incremental delivery vs. big-bang delivery]

LUXEMBURG would be faster...

 

-- jon

-----Original Message-----
From: Randy MacDonald [mailto:randy@...]
Sent: Saturday, July 31, 2004 10:27 AM
To: agile-usability@yahoogroups.com
Subject: Re: [agile-usability] Mouse Abuse [Was: Designing for incremental delivery vs. big-bang delivery]

I expect that behavior if the pulldown has an edit field on top, but am suprised when it doesn't have an edit field, when the list focuses on funny places, which are perfectly sensible if I recall my most recent keystrokes, which is what the edit field does for me.

 

As another example, I get to "LONDON" in a list of cities by pressing "M" then a series of Up's.

----- Original Message -----

From: Ron Jeffries

To: agile-usability@yahoogroups.com

Sent: Saturday, July 31, 2004 7:26 AM

Subject: Re: [agile-usability] Mouse Abuse [Was: Designing for incremental delivery vs. big-bang delivery]

On Saturday, July 31, 2004, at 12:17:33 AM, Randy MacDonald wrote:

> I thought the Windows GUI standards meant one didn't have to tell users what Tab means.

It's odd and fascinating how few end users have read the Windows GUI
standards, and how even fewer have understood them. :)

I have in recent months encountered two or three people who didn't know
that when you are in a pull-down state box, and trying to get to, say,
Michigan, you don't type MI, you type M, M, M until you get the one you
want. They were all delighted to learn this.

Ron Jeffries
www.XProgramming.com
Writing code is not an exercise in manliness.  -- Mark Hahn

Ron Jeffries wrote:

> I have in recent months encountered two or three
> people who didn't know
> that when you are in a pull-down state box, and
> trying to get to, say,
> Michigan, you don't type MI, you type M, M, M
> until you get the one you
> want. They were all delighted to learn this.

Uncle Ron said something very relevant here, and it
might have gone over a few heads.

Ron said "when you are in a" combo box.

He did not say, "When a combo box displays the unique
keyboard focus emphasis."

When a control has the focus, the user does not "feel
like" the window manager will route keystrokes to that
control. They just feel like they are "in" the
control.


=====
Phlip
   http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces



__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail

Jon Kern wrote:

> the favorite Cooperism for me is "the inmates are
> running the asylum"

A favorite Dot-Bomb era e-mail tag line:

  The inmates have stock options in the asylum.



=====
Phlip
   http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces



__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail

Paul Hodgetts wrote:

> So, I'm wondering what would happen if we just did
> the
> interface work as required by the feature we're
> working
> on.  Why can't we approach UI design like we do
> evolutionary code design?

The term "all roads lead to Rome" doesn't just mean
than roman civil engineers started from home. It
anyone carting their goods from their little farm or
crafts shop, chosing the direction away from the
barbarians, would eventually encounter a Roman tax
collector.

Agile processes sort features in order of business
priority.

A project must finish its primary set of features
before working on a secondary set. For the first few
iterations, only the primary ones get any design
attention, coding attention, or tool support.
Reviewing an iteration’s results assists adding new
User Stories to the stack, and assists resorting the
stack before the next iteration.

Some Agile literature admits a diagnosis of nebulous
or rapidly changing requirements indicates an Extreme
Programming prescription. This sophistry appeases
those with positive experiences converting relatively
motionless requirements into planned designs before
implementing them. But we don’t care if all the
requirements are carved in granite.

Source code supporting the primary features, written
first, experiences the most test runs over its
remaining lifetime.

Finished primary usability designs assist specifying
new secondary usability designs, so their details
reinforce the primary features. All versions lead
users to the features of highest business value.

All roads lead to Rome.

Refactors invest secondary features into the primary
features’ code, amplifying the testing pressure that
constrains the primary features.

Implementing features by business priority is a design
technique.

> Every once in a while, I found we got into a local
> maxima
> that needed a little extra work to break out of into
> a
> better larger-scale design, but because everything
> was
> clean and minimal already, even though there was a
> little
> flurry of extra work to adjust for the new
> structure, it
> went smoothly with little risk and impact to the
> project.

When tests drive development and make changes safe,
the search for the set of features that maximizes
users’ productivity becomes a simple hill-climbing
algorithm. The Customer always fearlessly picks the
steepest slope from the current location. This
simplifies requirements gathering. While nobody can
agree on the details for low-priority features, the
high-priority ones compel attention. Implementing
those features teaches how to specify the lower value
features, so they support the higher ones.

To avoid rework, XP teams boost user productivity
early and often. The Planning Game sorts User Stories
in order by business value. This is a hill-climbing
algorithm—a search for the maximum productivity boost
from the current position. On hills without secondary
peaks, the shortest path up is always the steepest
path from each point. In the space of programming, a
hill-climbing algorithm encounters no secondary peaks
if all application features can deform continuously.
Simple Design, Merciless Refactoring, and Test-Driven
Development create designs that change smoothly and
safely.


=====
Phlip
   http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces



__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail

Jon Kern wrote:
> UI Guidelines, what good are they?

They are essential and generally useless, see below
>
> In folks' experiences, what sorts of things are covered in the guidelines?
>
> I've seen extensive guidelines that cover look and feel, pixel
> indications for buttons and text, spacing between buttons on a dialog,
> and all sorts of <yawn> mechanistic things.

I've seen them cover everything like colors, spacing, font, size,
general page layouts, preferred UI solutions to various business
processes (use a left nav tree and a right panel details when the user
is trying to find a specific resource and maintain concept of where it
is in the overall organization) - going beyond the mechanistic.  I have
also seen them linked to UI widget libraries and template page designs
>
> Whoop-dee-dooo... i'd be more impressed if these guidelines were
> flexibly built into the UI code framework such that developers did not
> have to spend one iota of time following said guideline

I agree completely, but getting there has proven to be elusive.  I've
worked at places where we built UI widget libraries.  Great concept, but
in practice the widgets didn't get used - they never quite seemed to
have the right functionality, so new ones were coded from scratch.

Any ideas on how to reach the goal?
>
> are there any real guidelines out there? You know, the kind that stop
> idiotic UIs from being birthed?

Guidelines don't prevent (or create) idiotic UIs, people do - this is a
process question and involves involving the UI folks up front and
throughout the process.  It also means giving them the resources to do
their job.
>
> I find Microsoft the most egregious offender of UI design. (If you are
> offended, just pull up "File | Save As" dialog in Word. And if you are
> still offended, then "Houston, we have a problem!") But I bet all of the
> MS apps follow the "MS UI Guideline Gold Standard for World Domination"

One of the continuous source of amusement is how MS doesn't follow their
own guidelines, though they seem to be getting better at it...
>
> -- jon

gary

Gary wrote:

> I've seen them cover everything like colors,
> spacing, font, size,
> general page layouts...

At a research gig, a particular hot-head computer
scientist had enough clout to override even our
civilians' understanding of usability. When he'd
insist on a certain layout, nobody would even have the
nerve to complain.

For example, he wanted the Launch button in the lower
right, a pad of configurable event buttons above it
(to be hit after it), and a display area on the left
containing a rotating shape.

I figured out the metaphor, and explained to everyone
he had reinvented the microwave oven. Everyone howled.


=====
Phlip
   http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces



__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail

Gary wrote:

> I've seen them cover everything like colors,
> spacing, font, size,
> general page layouts...

At a research gig, a particular hot-head computer
scientist had enough clout to override even our
civilians' understanding of usability. When he'd
insist on a certain layout, nobody would even have the
nerve to complain.

For example, he wanted the Launch button in the lower
right, a pad of configurable event buttons above it
(to be hit after it), and a display area on the left
containing a rotating shape.

I figured out the metaphor, and explained to everyone
he had reinvented the microwave oven. Everyone howled.


=====
Phlip
   http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces



__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail

-----Original Message-----
From: Gary [mailto:macomber@...]
Sent: Monday, 2 August 2004 9:33 a.m.
To: agile-usability@yahoogroups.com
Subject: Re: [agile-usability] UI Guideline Experiences [Was: Re: Mouse Abuse [Was: Designing for incremental delivery vs. big-bang delivery]]

Jon Kern wrote:
> UI Guidelines, what good are they?

They are essential and generally useless, see below
> 
> In folks' experiences, what sorts of things are covered in the guidelines?
> 
> I've seen extensive guidelines that cover look and feel, pixel
> indications for buttons and text, spacing between buttons on a dialog,
> and all sorts of <yawn> mechanistic things.

I've seen them cover everything like colors, spacing, font, size,
general page layouts, preferred UI solutions to various business
processes (use a left nav tree and a right panel details when the user
is trying to find a specific resource and maintain concept of where it
is in the overall organization) - going beyond the mechanistic.  I have
also seen them linked to UI widget libraries and template page designs
> 
> Whoop-dee-dooo... i'd be more impressed if these guidelines were
> flexibly built into the UI code framework such that developers did not
> have to spend one iota of time following said guideline

I agree completely, but getting there has proven to be elusive.  I've
worked at places where we built UI widget libraries.  Great concept, but
in practice the widgets didn't get used - they never quite seemed to
have the right functionality, so new ones were coded from scratch.

Any ideas on how to reach the goal?
> 
> are there any real guidelines out there? You know, the kind that stop
> idiotic UIs from being birthed?

Guidelines don't prevent (or create) idiotic UIs, people do - this is a
process question and involves involving the UI folks up front and
throughout the process.  It also means giving them the resources to do
their job.
> 
> I find Microsoft the most egregious offender of UI design. (If you are
> offended, just pull up "File | Save As" dialog in Word. And if you are
> still offended, then "Houston, we have a problem!") But I bet all of the
> MS apps follow the "MS UI Guideline Gold Standard for World Domination"

One of the continuous source of amusement is how MS doesn't follow their
own guidelines, though they seem to be getting better at it...
>
> -- jon

gary

Hi Lauren,

> I have developed a set of guidelines for our team to use.
> Everyone had input and  we all agreed on them. We tried not to
> include anything that wouldnt be followed.
>
> However - a couple of months later - how do i get people to
> follow them?

Before trying to get people to follow them, find out what is
conflicting with the agreements.

> But then the tricky thing is - how do you tell if someone has
> legitimately decided to go against the guideline ( I believe
> there are certain cases this is possible ???? ) or just
> forgot?

Ask them.

> Perhaps we need to have "compulsory" guidelines and
> "suggestion" guidelines.

Try putting a human face to every guideline.  Each guideline
became a guideline because it serves some specific people in some
specific ways.  The guideline becomes something like a surrogate
for those beneficiaries -- but the document doesn't have a human
face.  If the guideline isn't guiding people, put the people back
into conversation.  Invite the beneficiaries into the room with
the developers to have a conversation about how the guidelines
help, and what is happening as a result of the guidelines not
being followed.

Dale

--
Dale Emery, Consultant
Collaborative Leadership for Software People
Web:    http://www.dhemery.com
Weblog: http://www.dhemery.com/cwd

Self-evident, adj.  Evident to one's self and nobody else.
--Ambrose Bierce

Lauren Berry wrote:

> Who uses Visual Studio + Source safe?

Agile projects use ContinuousIntegration, which leaves
all code checked out all the time.

;-)

=====
Phlip
   http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces




__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail

Lauren Berry wrote:

> Do any of you have good ways to get the developers
> to follow
> guidelines...? is it education that is required?
> talking to actual
> users? hmmm....

This is part of review in general.

I am researching how to configure unit tests to take
pictures of their tested windows, and upload these to
a server, for rapid review.

=====
Phlip
   http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces



__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail

-----Original Message-----
From: Phlip [mailto:phlipcpp@...]
Sent: Monday, 2 August 2004 1:07 p.m.
To: agile-usability@yahoogroups.com
Subject: RE: [agile-usability] Re: Mouse Abuse [Was: Designing for incremental delivery vs. big-bang delivery]

Lauren Berry wrote:

> Who uses Visual Studio + Source safe?

Agile projects use ContinuousIntegration, which leaves
all code checked out all the time.

;-)

=====
Phlip
  http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces


     
           
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail

On Fri, 2004-07-30 at 08:24, Jeff Patton wrote:
>
> Mike - thanks for your post.  For those on the list going to XP/Agile
> Universe, consider attending the workshop Mike and William are
> hosting: http://www.xpuniverse.com/schedule/W5  Also for those
> attending who want to listen to 3 hours of my rants, consider
> attending this: http://www.xpuniverse.com/schedule/T16

Thanks for the plug, Jeff. The workshop should be fun. We're hoping to
get a good mix of people, so that attendees will be able to hear a
variety of perspectives in a short time. We'll try to squeeze everybody
in, but if anybody would like to be sure of a spot, please contact me
off-list at william@... and I'll put your name down.

We were a little concerned that it would be tempting to go off on long
theoretical digressions; to keep things grounded we will be getting
everybody involved in developing a UI for an imaginary sample project,
chorewheel.com. We are also a bit worried about our Wednesday-morning
time slot, so we will make sure that coffee and treats will be
available.

William

On Sun, 2004-08-01 at 17:22, Lauren Berry wrote:
> But then the tricky thing is - how do you tell if someone has
> legitimately decided to go against the guideline ( I believe there are
> certain cases this is possible ???? )
> or just forgot?  Perhaps we need to have "compulsory" guidelines and
> "suggestion" guidelines.

My two default answers, somewhat vague, would be "automation" and
"teamwork".

Regarding "automation", I try to make it so that the easy thing is the
compliant thing. If it's easy to use the standard widgets and the
standard automated tests for those widgets, then people have to take a
positive action to break the guideline.

For example, in the web project I'm working on, there's a Page class
that contains common page structure and helper methods to do common
things. There's also a PageTestCase that checks certain universals for
every page. It's still possible to override those superclass methods or
rewrite things from scratch, but as you UI professionals know, people
generally do the easy thing. If your people aren't doing it, it might
not be easy enough yet.

And by "teamwork", I mean taking advantage of the common culture to
encourage following of norms. XP's promiscuous pairing and frequent
non-developer review mean there are plenty of opportunities for
something accidentally forgotten to be remembered.

Now if people remember the guidelines but silently ignore them, that's a
culture problem, where I'd follow Dale's excellent advice.

William

--- In agile-usability@yahoogroups.com, Gary <macomber@s...> wrote:
> Have you had any luck "sanitizing" the negative examples so they
portray
> the kernal of the issue without the trappings of the specific
real-world
> example?

Generally, yes.  If the core/trigger example is in one of our
products, I take the negative example and at least redo the example in
a wireframe (rather than taking a pure screen shot).  More often, I'll
capture the essense of an example and then generalize it by changing
the domain or making the example so generic it could be anywhere.

For example, there are a number of places in applications where depths
are presented as "1823.19281918174018181 ft" which is, of course,
completely nonsensical since the precision is about 0.1 feet (if
that).  Rather than taking a scren shot from a specific application, I
would make a wireframe showing an unspecified depth presented as above
and then another one showing the depth presented as "1823.2 ft".

Ron

--- In agile-usability@yahoogroups.com, "Lauren Berry" <laurenb@c...>
wrote:
> But then the tricky thing is - how do you tell if someone has
> legitimately decided to go against the guideline ( I believe there are
> certain cases this is possible ???? )
> or just forgot?  Perhaps we need to have "compulsory" guidelines and
> "suggestion" guidelines.

Yes, our guidelines tend to be divided into "must" and "should" sorts
of guidelines.  But, there always has to be enough wiggle room for the
"it depends" sorts of situations.

>
> Do any of you have good ways to get the developers to follow
> guidelines...? is it education that is required? talking to actual
> users? hmmm....
>

Unfortunately, the developers have to care to follow them.  They
either have to care about how the users perceive their UIs (feedback,
clips from usability tests) *or* they have to care because their
managers make them care.

Ron