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.
> So here is my question, which I fear sounds blasphemous. Have any of
> you ever strayed from strict technical accuracy to convey a concept
> more understandably?
This is related more to UI design, so feel free to delete now if you're
not interested...
We have been having an argument with Engineering because they
want to present something in the UI as technically accurate, but
some of us have argued that it will only be confusing to the
customers.
We manufacture datalogger hardware and software. For years, the
communications software has accessed the COM port, which in turn
accesses the datalogger directly. Now, we have developed a version
of the software that is client/server based. The server is actually
what accesses the datalogger, and the client application accesses
the server to get its data from the datalogger. To complicate matters
further, our newer OSs are using a packet-based communications
protocol.
We have a screen that has a "Connect" button, from which you can
collect data, set the clock, monitor values, etc. Some of the
engineers argue that because the client is not actually connecting to
the datalogger, but connecting to the server that is connecting to the
datalogger, that it is technically inaccurate to have a Connect button.
Also, in the packet-based network, a "link" is being maintained only
long enough to transfer the packet and then the link is dropped.
My argument is that people have been "Connecting" to the
datalogger for years, and they don't really care what is technically
correct. In their minds, they want to connect to the datalogger,
collect the data, and disconnect. They really don't care if it is the
server connecting to the datalogger or the client -- bottom line, they
want their data. To take a Connect button away after its been there
for 8 years would only confuse many of our users.
I think I am winning this battle, and the Connect button will stay.
So yes, sometimes it might be more beneficial to the user to portray
something other than what is technically correct...
Order RoboHelp Office X3 by March 14 and receive a $100 mail-in rebate,
plus FREE WebHelp Merge Module and FREE iMarkup Software, for a
total giveaway value of $439! Order today at http://www.ehelp.com/techwr-l
Help celebrate TECHWR-L's 10th Anniversary starting this month!
Check out the contests at http://www.raycomm.com/techwhirl/special/contests/
Happy birthday to you, happy birthday to you, happy birthday TECHWR-L....
---
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.
