[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]