 | |
#11
 
| |||
| |||
|
Re: Useful Manuals -
04-27-2007
, 12:08 AM
|
These days a lot of software links to features that are not specifically application related. Examples include Online Chat with a Help Desk, and Check for Updates. For a GUI I'd recommend a standard button (toolbar/menu, etc) that allows the user to jump to a web form where they can lookup and contribute to tips on a specific window/form or procedure. Using AccuTerm (wIntegrate?) you can easily launch browser windows from a green screen too. A forum allows for discussion, but isn't very good for finding content, as anyone who has searched for info in CDP will attest. Material like this needs to be audited for later consumption - you don't want people doing data entry to waste time searching through forum commentary. For forum discussions and for the feature above, I recommend someone with app knowledge should be assigned to summarize inquiries which is then provided in both standard docs and the online help to which someone would later jump before posting a forum inquiry. The process might be like this: - User clicks button and jumps to more help on the current screen. - When the help is exhausted they can send a note to Support or post to a company/app-specific forum. - When the issue is resolved or more info is available, the first help screen gets updated. A link could be posted back to the forum for related questions, but this will break if/when the forum changes. With a central repository of inquiries and solutions, both the IT staff and developers can see what problems people are having, and they can proactively make product and process improvements. This is good for end-user morale too because they get changes by asking questions. As we see here and elsewhere, most people have no problem asking questions but they are often very reticent to request changes. Seeing their feedback incorporated into the product makes users feel like they are contributing, which helps to deal with the "us and them" relationship often present between users and IT. I'm not saying this should replace a support desk but that it's another resource which allows everyone to work better. BTW, these same features should be available for the DBMS as well as in applications. It would be easy to add a web service to any DBMS where developers can ask questions of their Support provider (VAR or DBMS provider) simply by typing HELP followed by a question. This stuff isn't rocket science but so far no one doing it. *sigh* I can help to implement these processes if anyone is interested. Stay tuned for the Nebula Remote Support Environment which will have this feature - and much more... TG@ removethisNebula-RnD.com "Excalibur" wrote: Hi I would appreciate comments from developers , analysts et al on the best method of setting up manuals. We have produced heaps over the years using everything from Wordstar, Word, Jet to Pick Items. Invariably they act as a safety blanket for management who do not actually use the system and sometimes they even make a sale look more likely. However we design the screens to contain 95% of the info required to complete a job so operators rarely use them. What we realised a long time ago is that everyone uses a package differently and the sensible ones incorporate specific decisions in their QA manual. The rest re-invent the wheel every time an operator leaves. In fact some even dream up incredible scenarios such as printing the screen with the order and credit card details and manually doing the charge. This instead of installing the bank's new software update and continuing to use our automatic facility which does it in seconds. Yes there are hundreds of entries required, and yes he knew how to run the software as he had done so for years and we only found out when he was fired. What is needed is a "How do I Fix This" section that would be best served by being added to by the operator fixing the issue. One simply cannot dream up all the ways that a person will dream up to pull the gearstick out by the roots. I am considering many ways ,PDF could be possible with amendments from Word but this requires knowledge that operators do not necessarily possess. I thought of blogs, perhaps Tony or Dawn have knowledge of easy and cheap packages to do this. I would want to lock our bit and allow additions at will. This would also have the advantage that we could occasionally check what they were up to. Thanks in advance Peter McMurray |
#12
| |||
| |||
|
|
Hi I would appreciate comments from developers , analysts et al on the best method of setting up manuals. We have produced heaps over the years using everything from Wordstar, Word, Jet to Pick Items. Invariably they act as a safety blanket for management who do not actually use the system and sometimes they even make a sale look more likely. However we design the screens to contain 95% of the info required to complete a job so operators rarely use them. What we realised a long time ago is that everyone uses a package differently and the sensible ones incorporate specific decisions in their QA manual. The rest re-invent the wheel every time an operator leaves. In fact some even dream up incredible scenarios such as printing the screen with the order and credit card details and manually doing the charge. This instead of installing the bank's new software update and continuing to use our automatic facility which does it in seconds. Yes there are hundreds of entries required, and yes he knew how to run the software as he had done so for years and we only found out when he was fired. What is needed is a "How do I Fix This" section that would be best served by being added to by the operator fixing the issue. One simply cannot dream up all the ways that a person will dream up to pull the gearstick out by the roots. I am considering many ways ,PDF could be possible with amendments from Word but this requires knowledge that operators do not necessarily possess. I thought of blogs, perhaps Tony or Dawn have knowledge of easy and cheap packages to do this. I would want to lock our bit and allow additions at will. This would also have the advantage that we could occasionally check what they were up to. Thanks in advance Peter McMurray |
#13
| |||
| |||
|
|
Peter, At one time we kept our manuals in word docs, spread across 9 or 10 different servers in 2 or three different directories in 8 or 9 different versions.. Never worked and always out of date or out of synch. Jon Sisk came to our aid with a great idea - wiki!. We built a "one-to-many" documentation solution for our flagship 4GL, Nucleus, that now enables everyone to support the documentation in a central location. Check it out. http://www.nuwiki.com - revision control, comment control, everything you want a document server to do. It's running on UniVerse, hosted on an easyco server - 99%+ uptime and accessible from everywhere. It's a total mv solution, no php, no SQL, no perl, no C++, just a dedicated Nucleus application running a documentation server. Lee Bacall www.binarystar.com "Excalibur" <excalibur21 (AT) bigpond (DOT) com> wrote in message news:17eWh.17113$M.11755 (AT) news-server (DOT) bigpond.net.au... Hi I would appreciate comments from developers , analysts et al on the best method of setting up manuals. We have produced heaps over the years using everything from Wordstar, Word, Jet to Pick Items. Invariably they act as a safety blanket for management who do not actually use the system and sometimes they even make a sale look more likely. However we design the screens to contain 95% of the info required to complete a job so operators rarely use them. What we realised a long time ago is that everyone uses a package differently and the sensible ones incorporate specific decisions in their QA manual. The rest re-invent the wheel every time an operator leaves. In fact some even dream up incredible scenarios such as printing the screen with the order and credit card details and manually doing the charge. This instead of installing the bank's new software update and continuing to use our automatic facility which does it in seconds. Yes there are hundreds of entries required, and yes he knew how to run the software as he had done so for years and we only found out when he was fired. What is needed is a "How do I Fix This" section that would be best served by being added to by the operator fixing the issue. One simply cannot dream up all the ways that a person will dream up to pull the gearstick out by the roots. I am considering many ways ,PDF could be possible with amendments from Word but this requires knowledge that operators do not necessarily possess. I thought of blogs, perhaps Tony or Dawn have knowledge of easy and cheap packages to do this. I would want to lock our bit and allow additions at will. This would also have the advantage that we could occasionally check what they were up to. Thanks in advance Peter McMurray |
 |
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.