TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:underutilization of optionsin software programs From:Karel van der Waarde <waarde -at- GLO -dot- BE> Date:Thu, 25 Jun 1998 18:49:13 +0100
What do we know about the underutilization or hidden functionality of options
in software programs?
I know one study on Unix that shows that people spend 70% of their time
working with 20% of the options (and are happy) (Carroll & Olson, 1988)
There seem to be at least two strands:
I do not use the other options for the following reasons
1. I am NOT aware of their existence
2. I am aware of them, but find usage problematic for the following reasons
- They are not relevant for my tasks
- It would take too long to find and learn how to use these. I prefer to
follow a method that may be less efficient but that is quite effective
enabling me to achieve what I want
Clearly there are various factors that affect hidden functionality:
- the type of software: wordprocessor, database, e-mail, browser,
DTP-program, illustration program, ...
- task: setting up preferences, templates, styles and grids requires more
options than applying them.
- personality: iconologists, manual-readers, explorers, ...
- interface: if options are easy to find, explore, remember, and use,
would they be used more often?
- support: online or on paper.
Has anyone found any studies on 'how much of a software program is
underutilized and why?'
I am also interested in the specific question if and how screen captures in
software documentation can alleviate the problem. My guess is that screen
captures help because they can entice the user into trying out something, for
example because the picture shows the (spectacular) results an option may
offer to the user, in addition to explaining the
program/symbol/icon/function/option.
Kind regards,
Karel van der Waarde
waarde -at- glo -dot- be
&
Hans van der Meij
meij -at- edte -dot- utwente -dot- nl