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

["Paul Neshamkin" <pauln@helpauthors.com>]

IMHO, that's nonsense. Graphics need to supported, because, believe it or
not, there are those of us who use them correctly, and for a purpose. We
also are fully aware of accessibility, and support section 508 requirements.


And, incredible as it may seem, we are fully versed in design and
typographic standards. 

You must always design tools and standards/recommendations for
professionals, and then worry about the very real problem of making sure
that the majority of Help authors are truly professional.

Since I am a consultant and a trainer, I'm happy to do that.


Regards,
 
Paul Neshamkin
pauln@helpauthors.com
 
MS Help MVP
ComponentOne Doc-To-Help MVP & Certified Trainer
 
 
 

-----Original Message-----
From: marbux [mailto:marbux@gmail.com] 
Sent: Monday, May 08, 2006 7: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