No announcement yet.

User Manual Enhancement

  • Filter
  • Time
  • Show
Clear All
new posts

  • User Manual Enhancement

    It would be wonderfully helpful to know what these things are called so that you can then find them in the style editor and effect changes. Backcolor, forecolor is fairly understandable, but what the heck is the name of the object on the screen? For example, the gray backcolor of the user information corner of a post -- what is that box called? The blue icon just to the left of the title of a thread or forum, what's it called, and perhaps even better, where is it located in the system so that if one wanted to replace with something else, they could?

    It's somewhat like having a picture of the multi-buttoned remote control for a new hi-def TV that outlines the buttons, what they're called and what they do. It shouldn't be too difficult to print up a few screenshots, enumerate the various buttons, areas, lines, boxes, icons, graphics, etc. and provide a matching list of what those screen areas are called in the style editor, or any of the other editors for that matter.

    Click image for larger version

Name:	namesofthesethings.png
Views:	106
Size:	224.5 KB
ID:	4455459 Click image for larger version

Name:	namesofthesethings2.png
Views:	86
Size:	229.6 KB
ID:	4455460

  • #2
    Always something on my to-do list. Just have to get time to do it.
    Translations provided by Google.

    Wayne Luke
    The Rabid Badger - a vBulletin Cloud demonstration site.
    vBulletin 5 API


    • #3
      Originally posted by Wayne Luke View Post
      Always something on my to-do list. Just have to get time to do it.
      My company writes custom accounting (full GL-Receivables-Customer/Member Management-Payables-Assets-Inventory, POS, payroll, event management and internet-based payment solutions (an internet-based Golf TeeTime reservation system written completely in PHP is another one of our add-ons) and when we started changing over from an MS-DOS 6.2 system to Windows back in 1994, we completely rewrote our user manuals, too. Then I did it again with pictures and full internal indexing and linking because our customers said they wanted it. It's 1300+ pages of documentation and that doesn't include the tech docs, which easily eclipse that.

      I just wanted you to know that I understand the issue of finding time to write documentation. I just wanted to toss out an idea that's likely been mentioned before. In my case, since we have many, many executable modules that make up our system and they don't use CSS, I've had plenty of practice with screen shots and descriptions. That usually results in a screen shot showing active information and descriptions on the first page of the manual, with smaller inserts of portions/buttons/text boxes/etc. in other places that match the documentation text. Users can call up the documentation for a module by clicking HELP in our menu bar and go from there.

      The documentation was intended to provide (a) users with something they had requested and (b) a chance to lessen customer support calls, in "where is this" or "how do I set up a special interest," etc.

      We were successful with (a). But we failed on (b). End users are generally lazy (as you know) and won't use the darned thing when all they have to do is click HELP. But personally, I find a truly complete user guide to be tremendously helpful, especially when trying to follow a procedure. We enumerate our procedure into steps and if a user calls to say "it didn't work" and we ask them, "Did you do steps 1, 2 and 3?" and they say, "No, I didn't think I needed those," We just have them call up the procedure in the manual and read step 1, which says, "DON'T SKIP ANY STEPS." And then we tell them to try again.


      widgetinstance 262 (Related Topics) skipped due to lack of content & hide_module_if_empty option.