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.
Christine -dot- Anameier -at- seagate -dot- com wrote:
> Bruce Byfield responded, in part:
> "if you like branching out into interface design, then you might be
> able to talk more intelligently to the programmers, and make sure
> that the Print icon is positioned so she can see it."
>
> I don't know about you, but in cases like that, I print out a screen
> capture, circle the Print button, draw an arrow, and add a note saying "Why
> don't we put the Print button here instead?" And I explain why.("If
> Debbie's resolution is set to 640x480--which isn't unlikely, on her 14"
> monitor--she'd have to scroll down to see it, and a lot of users don't
> think to scroll.")
Yes, you can do some useful interface design on this level. However,
it's even more useful to know that some widget sets don't support a
particular feature, or that a particular program limits the
positioning of certain elements. If you don't have this knowledge,
your suggestions may be useless to the programmer. If they are, then
you might also lose some of that programmer's respect, which could
make your dealings harder with him or her next time around.
Also, interfaces are the last things that most programmers worry
about. Sometimes, if you want to suggest a compete redesign, the
quickest and most convenient way of working is to sit down and do
the interface yourself. You probably won't want to make everything
functional, but you'll carry your point more easily if you show
exactly what the GUI could be like, instead of just doing a sketch.
> I'm also not clear on how understanding programming makes it easier to
> write an end-user troubleshooting procedure... or any other end-user
> documentation, really.
Because you may be able to trace the problem, and nose around for
alternatives. This is especially useful when you need to provide a
work around, or when an action can have multiple results. The
alternative is trial and error, which may work, but is likely to
take longer and may be limited by the interface.
Naturally, you don't tell Debbie the Hapless User (I imagine her as
the heroine of a Victorian melodrama, being tied to the railway
tracks) to open the code up and read it. But, if you can see how the
program works, you may very well be in a better position to tell her
what to do from her perspective.
--
Bruce Byfield, Outlaw Communications
Contributing Editor, Maximum Linux
604.421.7189 bbyfield -at- axionet -dot- com
"The Queen was in her chamber, a-combing of her hair,
There came Queen Mary's spirit and It stood behind her chair,
Singing, 'Backward and forward and sideways may you pass,
But I will stand behind you till you face the looking-glass.'"
- Rudyard Kipling, "The Looking-Glass"
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Develop HTML-based Help with Macromedia Dreamweaver! (STC Discount.)
**NEW DATE/LOCATION!** January 16-17, 2001, New York, NY. http://www.weisner.com/training/dreamweaver_help.htm or 800-646-9989.
Sponsored by an
anonymous satisfied subscriber since 1994.
---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
