Re: Non-existent "features"

["Martin, Chuck" <chuckm -at- EVOLVESOFTWARE -dot- COM>]

I disagree.

It's a simple design concept: if the function isn't in the software or
doesn't work, don't use the UI element (menu command, button, etc.) that
represents it. Anything else is a lie to the user.

If a function is obsolete (no longer in the program), get the old menu
command out of there. If you want to make changes in the design to
improve usability (I assume that's why things would be made obsolete),
then make the changes and make a clean break. Don't leave the visual
clutter from previous versions.

Providing a "this feature isn't available anymore...." message is bad
design. It first leads users to think that the function is there
(otherwise, why would the menu command be there), then frustrates them
by leading them down a dead end that wastes their time.

It's the same thing for "future implementations." Don't make users
expect to find a feature only to tell them when they try to use it that
they can't yet do what they want. Only marketing gets to make promises
to customers that they don't intend to keep; don't do it in the program
interface.

If you lie too many times to the user in the interface, they'll dump
your program and find one that is honest.

On Wednesday, February 25, 1998 10:10 AM, Geoff Hart (by way of "Eric J.
Ray" <ejray -at- raycomm -dot- com>) [SMTP:geoff-h -at- MTL -dot- FERIC -dot- CA] wrote:
> Marci Abels wondered about <<some features [that] are
> on the menu but not operational because they are now obsolete, as far
> as the programmers are concerned, and some features are still up in
> the air regarding future implementation.>>
>
> For the obsolete features, there's a simple and elegant solution:
> leave the menu choices in place so you don't surprise anyone who is
> expecting them to be there, but instead of performing some program
> function, pop up a dialog box that says "This feature is no longer
> supported by the software. If you need to perform this task, here's
> how to do it under the new version of the software... [short summary]
> See the XXX section of the online help for details." This ensures
> that you don't run into problems with users forgetting to skim the
> readme or "changes since last version" part of the software; besides,
> even geeks like me who do read such things inevitably end up
> forgetting which features got de-implemented. As well, if you add the
> feature back in again, your menu choice is already in position and
> all the developers need to do is add in the code subroutine.
>
> As for the features intended for future implementation, you can
> modify this trick to come up with something a bit less effective but
> still functional. Use the same message, but substitute "this has not
> yet been implemented" for "is no longer supported". Again, when the
> developers finally do add the feature, they simply cut out the
> message text and replace it with the code module. Hopefully, they
> also remember to tell you so you can document the new feature, but
> just in case they don't, make sure _you_ are the one who does the
> writing of the messages, and keep a folder of them. A week or two
> before the ship date (longer, if appropriate), go back to the folder
> and try each menu choice to see whether it still presents the message
> or whether it's been replaced with functional code.
> --Geoff Hart @8^{)}
> geoff-h -at- mtl -dot- feric -dot- ca



--
"You don't look American."
"Everyone looks American, because Americans are from everywhere."

- Doonesbury
Chuck Martin, Technical Writer
Evolve Software                  | Personal
chuckm -at- evolvesoftware -dot- com        | writer -at- best -dot- com
www.evolvesoftware.com           | www.writeforyou.com