- – - – - – - – -
RSVP to: nyc-rsvp (at) ixda (dot) org
- – - – - – - – -
Please join the NYC IxDA community for our July event:
“The Naked Interface—Liberating Brain, Body, and Digital Interactions”
Throughout the electronic age, people have become accustomed to
interacting with digital
Dan Saffer wrote:
I guess I'm questioning whether error messages are the correct way to
teach users anything.
Are you really questioning, Dan, or are you being polite and giving them the
benefit
of the doubt? :-)
Me, I would state it outright: Error messages are *not* the correct way to
Yes, error prevention is a primary goal, but I will play devil's
advocate here and modify that to state, prevent errors whenever
possible, but if you can't prevent the error (because of system or
code limitations or something else that can't be changed immediately),
present a well-crafted message
Absolutely, Chaunceh. My point is not that error messages are not necessary,
but that they are not sufficient.
Elizabeth
Chauncey Wilson wrote:
Yes, error prevention is a primary goal, but I will play devil's
advocate here and modify that to state, prevent errors whenever
possible, but if
I wrote:
My point is not that error messages are not necessary,
but that they are not sufficient.
And that they are not the best starting point.
Elizabeth
--
Elizabeth Buie
Luminanze Consulting, LLC
www.luminanze.com
Welcome to
As for best practices, I see those as more granular than, say, do
ethnographical research. I'd say it would be particular ways, techniques,
methodologies that have been shown to generally produce good results. But
they are more focused on *how* you do things rather than the end result,
Hi,
Here's another context. The Nokia Series 60 UI Style Guide (from
2005) touches on this issue and prohibits the dimming of unavailable
menu items. They outline the rationale for hiding or erroring
instead and allow for either, depending on the situation.
If/when drawing conclusions
On Jul 2, 2008, at 4:12 PM, Jeff Howard wrote:
The Series 60 user interface does not use dimming of menu items.
But they don't say why. Without a good reason, I think this is a poor
decision.
Jack
Jack L. Moffett
Interaction Designer
inmedius
412.459.0310 x219
http://www.inmedius.com
Regarding:
http://www.ixda.org/discuss.php?post=30937
In my company we have very good experiences using this method:
http://portal.acm.org/citation.cfm?id=1028050
The Instant Data Analysis (IDA) allows us to conduct a usability evaluation
with 5 users per day and have feedback to the developers
Hi,
I have a new job with a client working on a business application. Right now
they
have their simple search configured so that if a user searches on the letter a
the results contain all objects with the letter a anywhere in the name. I
realize and they realize that this is not ideal and
I have no research to back this, but here is an idea you can try:
Rule 1:
Alphabetical Titles [Yeah I know Jared is probably going to hate
this :)]
Rule 2:
Alphabetical Categories
Rule 3:
Letter's appearance in titles
Example:
(A)BC for filing [Papers]
(A)necdotes for searching [Papers]
(A)pple
On Jul 3, 2008, at 7:26 AM, Elizabeth Buie wrote:
Me, I would state it outright: Error messages are *not* the correct
way to teach them.
Yes, but nothing says Don't press that button better than a couple
of electrodes emitting 10,000 volts. They won't make the mistake
again, I tell
Let see, the usability ethics code restricts electric shock features
to less than 270 volts and remember that amperage is the more critical
voltage.
Chauncey
On Thu, Jul 3, 2008 at 9:30 AM, Jared Spool [EMAIL PROTECTED] wrote:
On Jul 3, 2008, at 7:26 AM, Elizabeth Buie wrote:
Me, I would
Doh! I should have said affinity diagram with clustered results of
sites features and functions. I apologize for mistyping and causing
confusion!
We used Morae to perform the tests, so we initially spent time
logging comments, observations and errors. Once complete we had a
giant
My 2 cents - the people who chose to not only users to do something that is
not allowed by the system, but further codified this little turdblossum (I
wonder how much user testing was involved validating this design decision)
need electroshock. There are many ways to solve whatever problem space
For all the improvements in UIs to ATMs it's not clear to me they are
addressing the core issue, which is the chain of responsibility and
accountability that builds trust.
I haven't deposited anything at an ATM since I read the fine print on
my ATM transaction record.' That fine print explicitly
In fact, based on this conversation, I'm going to toss out one other
possible best practice:
The system should never present an error message to a user unless the
user has done everything right but the system itself cannot respond
correctly. Users should otherwise never be allowed to make
IxDA Boston is pleased to announce our most successful event to date. We
were honored to have over 75 local designers, developers and thinkers come
to see 9 talks on methodologies, techniques, findings and new technologies.
For those who could not attend we will be releasing the audio slide
Jared Stanley Milgram Spool writes:
Yes, but nothing says Don't press that button better than a couple
of electrodes emitting 10,000 volts. They won't make the mistake
again, I tell you.
Quite right!
--
Elizabeth Buie
Luminanze Consulting, LLC
www.luminanze.com
Way back when during my days at Microsoft, I worked on an OS project that
had the goal of eliminating all error messages in much the way you
suggested.
We found that in simple, webish, apps, this was easier to manage than say,
Excel or Word. In complex apps the amount of data entry or
Hi Heather,
Here's my thoughts. Hope they help.
Mitch
--
Some consistency issues:
- some blue text is links (bottom nav), some is not (text headings)
- some white text is links(top nav), some is not (body text)
- some blue links (bottom nav) have a hover state of white and underlined,
one
The system should never present an error message to a user unless the user
has done everything right but the system itself cannot respond correctly.
Users should otherwise never be allowed to make errors.
I second that. In fact, I preach it often.
-r-
We found that in simple, webish, apps, this was easier to manage than say,
Excel or Word. In complex apps the amount of data entry or scripting like
functionality made it prohibitively expensive to handle all the error cases
well (or to eliminate the many gratutious error messages).
The
Are the responses to this site just further proof that interaction designers
can't be happy with anything?
The learning curve is low, the experience is rich. It's enjoyable,
interesting, and engaging. It offers a search method so you can still find
books not showing, and even offers an easy way
On Thu, Jul 3, 2008 at 12:39 PM, Robert Hoekman Jr [EMAIL PROTECTED] wrote:
Are the responses to this site just further proof that interaction designers
can't be happy with anything?
Of course. That's the first tenet of IxD, is it not? If users don't
like something, the problem clearly lies
On Jul 3, 2008, at 9:55 AM, Scott Berkun wrote:
Error messages are popular simply because they are the cheapest
interaction a programmer has - it's much less work to handle users
with errors than it is to write code that gracefully resolves issues
on its own.
So like in many cases, the
Yes - I'd go even further and blame development tools. Here's a theory:
1. The design of development tools is indifferent to the making of good UI.
2. Programmers are efficient (or lazy :)
Therefore
3. Programmers will tend to make bad UI... until development tools make it
almost as easy to
Random question:
I'm looking for a good photo of the internals of a copier with the 1,2,3
and color coded handles for clearing a paper jam. It's proving harder
than you'd think to get a good one.
Anyone got a good source?
Welcome
COMPANY: Cisco Systems Inc.,
URL: www.cisco.com
JOB LOCATION: San Jose, CA
JOB TITLE: Senior Visual Designer
JOB DURATION: Permanent
JOB DESCRIPTION:
Job Description:
Cisco is looking for Senior Visual Designer to join the User Experience
Team within the Voice Technology Group (VTG). In
Can anyone present any convincing arguments for *not* using a remote
card sorting technology - like websort.net? And instead insisting that
card sorting must be performed in person?
Tangent: what is your opinion on performing card sorting one-to-one
individually vs in a group? ...
Aaaand
Check out http://www.websort.net/
On May 14, 1:52 pm, Gomez, Marla A [EMAIL PROTECTED] wrote:
We are looking to do a visualcardsortwith users that are geographically
dispersed across the globe. Ideally, we want to find a tool that will allow
users to drag and drop things to create their own
The system should never present an error message to a user unless the
user
has done everything right but the system itself cannot respond correctly.
Users should otherwise never be allowed to make errors.
I second that. In fact, I preach it often.
Okay, so what about this situation:You come
One way to prevent this would be to disable the button and give it
that grayed out visual treatment until they enter a dollar amount but that
would mean that when they arrive at the page they'll see a broken button.
Agreed, assuming most people actually look at the button prior to completing
Reasons to do a card sort in person: I want rich, qualitative feedback
from participants; I am combining the card sort with other
tasks/activities. In person card sorts are useful If you are trying to
learn how participants think about a domain. Doing it in person will give
you a lot of
There's another way to approach this, that I think at least conceptually can
help the designer make the right choices. We should all eradicate the word
error from our design vocabularies.
I propose that the user NEVER makes errors. The user may do unexpected things,
or provide unexpected
I propose that the user NEVER makes errors. The user may do unexpected
things, or provide unexpected input, or act in ways that the system is not
sophisticated enough to deal with. Or that the sponsor of the system chooses
not to deal with. But no error has occurred.
Kinda touchy-feely,
Steve wrote:
Reasons to do a card sort in person: I want rich, qualitative
feedback from participants
I agree, the card sort session is often an opportunity to elicit
conversations from the participants that are lost when you do the
card sort remotely.
// jeff
. . . . . . . . . . . . . .
37 matches
Mail list logo
