Embedded help for a web based application?

["Hart, Geoff" <Geoff-H -at- MTL -dot- FERIC -dot- CA>]

Pooja Malhotra has been asked <<... to develop an embedded help for a web
based application, where, access to various pages is role-based( n number of
roles). One of the roles involved is of an Operator (job: data entry) and
other of a Supervisor (job: approve the data entered by the operator). But I
have been asked to produce a generalized help, where we have TOC, Index,
Search and all the help pages involved. Should I consider restricting the
Operators from accessing help pages provided only for
the Supervisor (and also other roles)?>>

Assuming that an operator has no access to a supervisor's special tools or
menu options, there's no need to restrict access to the Help files. If the
operator can't perform any supervisor functions, then they will never
encounter the context-sensitive help for those functions. If they find the
help via the index, they still won't waste any time reading about functions
that they'll never be able to use. And if they do, what harm could this
possibly do?

<<Also, our organization has actually modified our client's existing
application, so at every step, I am making certain assumptions, for example,
the operator knows where the Customer ID comes from OR the Supervisor must
him/herself assign a new Customer ID!!! Can I not ask the developers to
modify the GUI? - its not user-friendly at all. I guess not, Right?>>

You can always ask them to modify the GUI, and if they like and respect you
and you can make a persuasive case, they'll probably even make the
changes--time and deadlines and managers permitting, of course. If they
can't, it's rarely a good assumption that users will know everything (in
your case, where to find IDs or how to create them). The really nice thing
about online help is that you can build in cross-references: "In this step,
type in the Customer ID. CLICK HERE to see a list of IDs and instructions on
how to create new ones." Those who need the information will click, those
who don't won't even read the last part of the sentence.

<<I have a feeling that I should ask to speak to the client because there
are so many things which our client is not disclosing to our developers and
are very unclear.>>

That's a recipe for disaster. You end up doing exactly what the customer
asked (honoring the letter of the contract) instead of doing what they need
(honoring the spirit of the contract). In the end, they have no legal
grounds to complain about the result, but you can bet they won't come back
to give you more work in the future. Many clients are great at assigning
blame rather than taking responsibility.

--Geoff Hart, geoff-h -at- mtl -dot- feric -dot- ca
Forest Engineering Research Institute of Canada
580 boul. St-Jean
Pointe-Claire, Que., H9R 3J9 Canada 

"Wisdom is one of the few things that look bigger the further away it
is."--Terry Pratchett

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Order RoboHelp X3 and receive a $100 mail-in rebate, plus FREE 
RoboScreenCapture, WebHelp Merge Module and iMarkupSoftware, for a total 
giveaway value of $473! Order here: 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.