CHI-WEB Archives

ACM SIGCHI WWW Human Factors (Open Discussion)

CHI-WEB@LISTSERV.ACM.ORG

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
"Williams, Natalia" <[log in to unmask]>
Reply To:
Williams, Natalia
Date:
Thu, 19 Jul 2001 10:04:28 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (426 lines)
Thanks to everyone for their suggestions. The insight into the many reasons
why this is "teaser" idea wrong gave me ammunition to take back to the
application group. The opinions on why this may work gave me more to ponder.
Unfortunately, I think their minds are made up--they're including them in
this release. I've given my 2c and documented it, so they can't say that
they got my ok. FYI, the application we're developing is an application for
our commodities traders, and, if any of you have worked with this particular
demographic, know that they don't put up with much. I expect immediate :)
feedback from them. The nice thing is that the people in the application
group who want the grayed-out buttons in WILL be the ones fielding the
calls. Hopefully this will teach them not to decide what is best for the
user and allow usability testing rather than evaluation against the
heuristics. Anyway, thanks again to everyone that replied! Below are some
group opinions:


***********************************************************
Quite simply Natalia, this seems cruel.

If anything, it could turn people off using the very feature when released
as people will get annoyed with it and probably used to it not being
available.

I can't see the requirement to tease people - I've never seen this in a
commercial package unless it was part of an optional 'upgrade' from say,
shareware, to the fully functioning version.  If you offer a greyed out
option with 'control' to 'fix' this then it will frustrate the users
needlessly.

Craig.

***********************************************************

I totally agree with you. The application should not act as a teaser in any
way. Any future modifications to the application should be noted in a new
version release document, not as teasers in an existing application. My
philosophy, like yours, always ask the question:
"Why play mind games with the user?" Keep the user focused on the current
application features, not future features of the current application.

--
Scott Martin
xwave solutions
www.xwave.com

***********************************************************

I always use a simple and straightforward approach:
disabling is for controls which are not usable in certain circumstances. If
the
conditions are not met, the button becomes enabled.
removing is for controls which are never applicable.
In your case, the buttons are never applicable so they should be removed.
The user interface can only be a market instrument to convey the ease of use
of
the current product, not what is ahead. Marketing for future releases shoudl
be
done by other means, not by the user interface.

My 2 c,

Rik Manhaeve
Belgium

***********************************************************

-----Original Message-----
From: Wim Putzeys [mailto:[log in to unmask]]

Putting in disabled buttons is similar to putting "under construction"
messages in a web site: it's very annoying. Users will also interpret
these buttons as disabled because of a bug rather than as a sign of
something to come. It conveys the impression that the product is only
half-finished and that the developers didn't have the time to create a
product that's as good as it could be.

It would be more effective to describe the features of their next
release on their website or in their brochures, so users can see they're
buying a a stable product with a vision underlying it. This approach
would also take the guesswork out of figuring out what those disabled
items exactly mean.

***********************************************************
I've experienced this sort of thing so many times. It's always a hard fight.
Of course you are correct: greying-out of a control indicates that it is
temporarily unavailable and that the user's actions (e.g. choosing different
data, different modes, etc) can change the state so that the control is
enabled.

The central question is: who would benefit from having these disabled
controls as part of the application? I don't think it's really for the
users' benefit. It seems more that it is for the application group's
benefit. So who is the application being written for?

--
Cameron Hayne ([log in to unmask])
Hayne of Tintagel

***********************************************************

I agree with your argument that disabled functionality, while intended as a
"teaser"
will ultimately be an irritant to users trying to use the disabled function
and spend
time actually clicking around furiously trying to "activate" the button(s).

Imagine a car with a break peddle that triggers a recording "Coming soon!"
instead
of stopping the car. Nice.

I'm afraid this is one of those times when gee-whiz marketing will do long
term damage to the product's credibility and brand.

Baron Lane
www.randomlabs.com

***********************************************************
My suggestion is to conduct a user testing to know whether the application
is still usable with the disabled buttons. That's what you do if you care
about the targeted users.

Adi

***********************************************************

-----Original Message-----
From: iY gnoY [mailto:[log in to unmask]]

> they're putting the disabled options in a teasers so that the
> users can see
> that they are incorporating suggestions into future releases.

Wow.  That's a stretch.  How are ppl supposed to infer that?  Disabled
buttons are currently used to denote functions that are not available,
usually due to a modal state.  Right now in Outlook, I don't have access to
the font menu because I write my emails in ASCII mode.  They're not grayed
out because I'm using Outlook Express and I need to upgrade to Outlook 2000.

Your app group is wrong.  You should argue that if they really want to put
in teasers about upcoming functionality, they should do so properly -- maybe
a small box on the side that explains the situation, maybe a one-time splash
panel (ugh, kind of like a Tip of the Day type thing).  You might be able to
compromise to NOT graying out the buttons but treating them in a different
way -- outlining them in, I dunno, red or something -- when the use clicks
on these buttons, a dialog box opens which explains the coming-soon
functionality.

***********************************************************


-----Original Message-----
From: Peter Sullivan [mailto:[log in to unmask]]

That's very misleading.  The customers will be trying to figure out what
"modes" will make the buttons active.  Have them put it in the code
commented out for the next release (if that makes him feel better), but not
customer visible.

***********************************************************

Natalia,

The technical writer email list recently had a discussion on this subject.
You can find the thread by going to
http://www.raycomm.com/techwhirl/archives/0107/index.html and find the
thread entitled 'future functionality.' Most felt that it was not a good
idea and there were a variety of reasons suggested.

Sarah


***********************************************************

I've done software development and you are entirely correct.

"Teasers" or even placeholders are entirely inappropriate in shipping
software.  They break the implied contract and require users to
adjust their understanding every time they look at the element.  I've
seen this in beta tests and it's extremely annoying.

In summary: if a feature is displayed, it had better be enabled, or
the users will assume that the software is broken.  And they'll be
right!

Avi

***********************************************************

Ask them how they feel when they do a web search, follow a good-looking
appropriate sounding link, and arrive at the page only to find "Under
Construction" message.

 Build a "What's coming" page, hang it off "Help" somewhere, and forget the
nonfunctional buttons.

Mike Boyink
HermanMiller.com

***********************************************************

I agree with you.  I work on similar projects - we develop software
applications for the US Military.  According to the User Interface
Specification for the Defense Information Infrastructure, (a spec often
required by the military for our software apps) options never available
should not be included.
My advise would be to attempt (good luck!) to convince the BAs/application
group to submit another form of confirmation (hold a meeting, submit a
document?) to the users/customers that these options will be incorporated in
upcoming releases.

Melissa Wills


***********************************************************

I think the positive of these "coming attractions" buttons outweigh the
negatives.

Yes, you may annoy some folks but the grayed out convention is pretty clear.


On the plus side you keep people involved.  If they need a feature and see
your competition
has it they may switch.  If however they like your product to this point and
see that the
feature is coming they can sit tight knowing the inconvenience of the
missing feature is
temporary and they do not need to go through the pain of learning another
system.

Further, users may see your plans and respond with ideas for improvement
before you have much
development time invested in (potentially) bad (or less than optimum) idea.
At OpinionLab
we always believe that feedback is a good thing.

The strongest argument against would be if the new features are really
ground breaking and your
development resources are limited.  In that case you run the risk of tipping
your hand to
a competitor that may beat you to market with your own idea.  On the flip
side, by having
the phantom buttons on your site you can claim to have the feature first
before its ready
to go.

Hope these thoughts were helpful

Robin Liddell
OpinoinLab

***********************************************************

My argument regarding the teaser button topic is simple; don't set yourself
up for a negative user reaction to innovation.

By including the grayed out or disabled button, over time, you will
essentially frustrate the user by dangling it in front of them or confuse
them by showing them something they cannot use. At first the user MAY see it
as a gratifying addition and except that it cannot be used. The mechanism
for educating the user on this abnormal behavior will either be in the form
of application documentation (or a sales rep), some type of read me text, or
through customer service. Customer Service comes into play when the user
cannot figure out how to use the disabled functionality since it looks to be
implemented. When you look at the added cost for customer service just to
tell the user that they cannot use the functionality, the scenario becomes
less attractive.

Now, if the options were not offered as a visual aspect of the newest
release the user would not have the impression that is was added. This is
good since it wasn't.

Essentially why set your users frame of mind to be "It's about time the next
version came out" or "Why did they release without everything being done, I
wonder what else doesn't work" when you can set a more positive one.

John Cicinelli
Type T
Sr. Information Architect


***********************************************************

You might ask the people pushing for this if they're willing to take
all the support calls from users trying to activate those grayed-out
features.  :-)

Alternatively, the things you're describing don't sound all that out
of the ordinary; putting grayed-out icons for these functions would
emphasize that the application's developers are behind on the feature
curve. Ask 'em if they're trying to cultivate an image of ineptness ...

Or you could try a restaurant menu analogy: would you go back to the
restaurant that described the wonderful items you could order -- but
sometime in the future, not now?

Random thoughts, but I totally support your perspective; showing the
user something they can't use is nuts.

HTH!

***********************************************************

Agreed. Reminds me of auto makers who leave "blank" buttons for
"future options". They look just like the other controls, but nowhere
will you find documentation or learn about what those buttons can do.

One of the more sizeable risks in showing disabled buttons is that
users might try to get those functions working, and will have no luck
doing so. Even if the purpose of the features is mentioned in the
documentation, there will be no way to activate them, and that's
incredibly frustrating. Count on dissatisfaction with the product,
complaints, and customer support nightmares. "Disabled buttons" may
be surprisingly difficult to explain to many users.

Best of luck.

--adam
--
adam baker, interaction designer
http://www.merges.net/

***********************************************************

This certainly is in the realm of web usability! I'd say it speaks to
one of the most basic problems of usability-- user frustration.
Including "teasers" is a fantastic way to frustrate users and make
using the product an unenjoyable experience.

First of all, how long does it take a person to realize that the
greyed-out buttons aren't off because of a particular mode? When I
see a function I want to use and it's greyed-out, I spend time trying
to determine how to change the settings to make it available.
HORRIBLE for task-completion if there's no way to activate the
buttons!

Second of all, the more "stuff" on the screen, the more confusion for
the user who is trying to complete a task using the functions that
*are* available. Simplicity.

Thirdly, without doing extensive interaction design *including* the
functionality in question, how can you make a good decision about the
bast way to expose the product's complete set of functions?

Bottom line: If the client wants happy customers, she/he won't include
teasers.


***********************************************************

-----Original Message-----
From: Miriam [mailto:[log in to unmask]]

That would drive me up a wall in a very, very short time.

It might be a nice compromise to include documentation of the future
features; as a user, I would appreciate that but the greyed-out
non-functioning things would also be very confusing - not to mention a
kludgey waste of code (that ought to strike a chord with them).

Good luck.

***********************************************************

I agree with you.  Everything presented to the user should be useful and
usable.  If it is not functioning, it should not be there.  The disabled
features make the user think, create doubts and  background noises.

I am sure the developers can hide these icons for now and show them when the
function really works.

Good luck!

- Cindy

***********************************************************

I agree with you.  I would not have
the buttons available there.  If they want to tease users or inform them of
new features and functionality they should have a section devoted to
upcoming features.  A look for these new features coming soon section.  This
would enable the user to look on their own without being frustrated in
trying to use the features disrupting their normal workflow.  My 2 cents.

Bryon

***********************************************************

-----Original Message-----
From: Kyle Drummond [mailto:[log in to unmask]]

My two cents...

giving that user a button that they cannot use will teach them not to use it
in the future. My fear is that by the time it is released they will actually
be trained to ignore it because it will be ingrained as "that button that
does not work".

***********************************************************

My quick opinion:
Your users will view these disabled icons as either (a) broken or
(b)contextual buttons that only become active in a certain state.  Either
way frustration with your application will quickly set in as they see that
their "incorporated[sic] suggestions" (a)don't work at all or (b) they can'
t figure out how to make them active.  You will be building "trust" that
these icons should not be used because they are unpredictable.

Thanks,

Shep McKee

***********************************************************
***********************************************************
Natalia Williams
User Interface Developer
Application Architecture
Mirant Americas, Inc.

    --------------------------------------------------------------
       Tip of the Day: Don't use automated replies to postings
               About CHI-WEB: http://www.sigchi.org/web/
         Vacations, holidays and other subscription changes:
             http://www.sigchi.org/web/faq.html#vacations
    --------------------------------------------------------------

ATOM RSS1 RSS2