RE: [user-assistance-discuss] Thoughts on Graphical Callouts

["Irwin, Barbara" <Barbara.Irwin@Eclipsys.com>]

That's an interesting point, but users can be handicapped in many ways -
including some who cannot read. Software systems are designed for many
functions, and the purpose of help systems is to help users navigate
those systems. Graphics (including those that lack artistic merit) are
one of many tools available for that purpose, and can be very efficient
where the written word is not. 

Individual help authors are in the best position to determine what their
users need, and can understand. They're the ones who receive feedback
directly from their users, and conduct usability studies. I think our
purpose here is to provide the widest tool-set possible, that will allow
authors to create help in a manner that meets the needs of their users.

From my perspective, what you're describing is an educational issue, not
a "tools" issue.


Barbara Irwin


-----Original Message-----
From: marbux [mailto:marbux@gmail.com] 
Sent: Monday, May 08, 2006 4:19 PM
To: Paul Prescod
Cc: user-assistance-discuss@lists.oasis-open.org
Subject: Re: [user-assistance-discuss] Thoughts on Graphical Callouts

On 5/8/06, Paul Prescod <paul.prescod@xmetal.com> wrote:
>
>
>
> Are you saying that a help authoring format SHOULD NOT support
graphics
> AT ALL because they are so often (in your opinion) misused?


Yes. The problem is enormous. The needs of handicapped end users have
been
all but ignored by virtually every Help system instance I have
encountered
since 16-character LED displays were first added to early computerized
typesetting systems so that highly-skilled operators (they weren't
called
"users" in those days) could view their input directly instead of
manually
reading punched paper tape or having to first render the data via a
mechanized hot type line caster such as a Linotype or on photographic
paper
in a phototypesetting  system.

Graphics (formally known as "art") in technical manuals was a rarity
except
for the covers until bit-mapped computer monitors reached the masses
along
with the MacIntosh. Prior to that, technical information was almost
exclusively conveyed by the written word or oral tradition. The
widespread
use of graphic images is a radical change imposed on software end users
over
the last 20 years or so and has been almost entirely executed by those
who
have scant comprehension of quality graphic design. (An oral tradition
of
graphic design knowledge dating back to medieval scribes was jettisoned
by
society shortly after the laser printer became affordable. The
custodians of
that oral tradition at the time, the journeyman typographer, saw more
than a
hundred thousand jobs disappear nearly overnight in the U.S. alone. The
International Typographical Union -- then the oldest trade union in
North
America -- dissolved and its remnants were folded into the Teamster's
Union.
Tasks were automated to the point that what little oral tradition
survived
was fragmented by specialization.

There is scant quality graphical design left in the developed nations.
We
are daily assaulted by ugly design on computer screens, now even in
newspaper page design, and aptly demonstrated by the gharish and crude
call-out images you linked in your previous post.

Software end users will not be inconvenienced by returning to first
principles of typography, conveying the written word. Flashy graphics
were
not needed before and they are not needed now. The graphic travesties --
routinely delivered by Help authors with the aesthetic sensitivity of a
water buffalo in full rut -- is not something for which end users are
crying
out. Only Help authors "need" them, but providing them with such tools
has
proved to have wisdom akin to unleashing a four-yea-old child in a room
awash with loaded guns. End users would benefit far more from the
relevant
resources and time being spent on writing and testing quality prose that
does a better and more thorough job of explaining how to perform tasks
in a
software application.

As I was told over and over again as an apprentice, you must master the
English language and typographical layout in black and white before
moving
on to using color. Aesthetics count. Now the populace of developed
nations
work in a software environment populated by software designers and Help
authors who were never exposed to such wisdom. Depriving them of their
"pretty graphics" toys does them no harm and would help them to apply
their
expertise in software usage to the task of informing software users how
to
use their programs.

Mere canvas and a brush do not an artist make, and taking the crayons
away
from the toddler who has been busily decorating the walls does him no
harm.


I cannot
> agree. Visually impaired people use software in different ways than
> other people and therefore will focus on different parts of the help.
> The visually impaired person will not care which button is to the
right
> of a particular text field. Instead they care about the keyboard
hotkeys
> on the dialog. Having a callout that describes the structure of the
> visual user interface is appropriate for one group of users. Having a
> page that describes keyboard commands is appropriate for a different
> group. We should encourage the writing of both rather than
discouraging
> either.


You are obviously new to the accessibility debate. That has been the
same
basic argument of those who resist handicapped accessibility from the
beginning. "Encouraging the writing of both" is a defense neither to a
lawsuit for an employer's failure to make "reasonable accommodations"
for a
worker's disability nor to a government procurement office's decision to
reject a bid because a software package does not meet procurement
accessibility standards.

I know. I became a lawyer after the advent of electronic automation
trashed
the thousand-year-old accumulated wisdom and graphic sensibility of the
typographic trade. I have worked with disabled persons both during my
career
and in my retirement from the practice of law.

"Encouragement" is scant comfort for the disabled worker whose
documentation
needs have been ignored by software and Help developers. Employers who
reject, demote, or discharge employees for such reasons act unlawfully
and
are liable for damages.

There is no time for mere "encouragement." The legal right to reasonable
accommodations for disabling conditions became effective many years ago.
I
certainly would marshal opposition to a Help authoring system XML
standard
that enables Help files being generated that do not comply with
accessibility guidelines and fully enable related standards such as
VoiceXML

This discussion would be more useful were it focused on how to
programatically ensure that Help authoring systems produce *only*
handicapped-accessible Help files.  I have proposed one solution. Do you
have another?

I do appreciate your emphasis on accessibility, however, and will try to
> incorporate ideas about that into any update to my callout roundup
> message.


Not an appropriate approach. Handicapped Accessibility is the law in the
U.S.
and many other countries. It is a minimum standard, not an aspirational
goal. A better approach might be to encourage some key accessibility
software developers to participate in this proposal's discussion.

I apologize for the strong words, but I respectfully suggest that the
Help
authoring community and Help authoring system developers are the
radicals
here. Help authors are not the end users of the software they develop
for.
The real end users are the people who operated the software documented
by
Help authors. Whiz-bang graphical feature wars ignore the needs of the
real
end users, which includes people with a civil right to have their
disabilities accommodated. You should not encourage or enable Help
authors
to violate the law. Your response demonstrates just how radical these
niche
industries have become.

This OASIS proposal could easily be turned in a cause celebre by
accessibility advocates. Please ponder the ethics of your position, and
consult your attorney afterward if you have any remaining doubts. There
are
weightier considerations afoot than graphical call outs.

No personal disrespect intended, but this proposal involves niche
industries
that have operated outside the law and the bounds of ethical behavior
for
many years. A strong shake-up is long overdue. The Help authoring system
development industry should not require a court decision to recognize
the
economic foolishness of delivering products that make it easy to violate
the
law. Should such a decision be rendered against a Help author or his or
her
employer, I suspect the developer of the Help authoring system will
quickly
find itself without customers.

Best regards,

--Marbux