1 / 23

Efficient User Documentation System for Different User Types

Enhance user documentation for Beginners, Intermediates, and Advanced users with specific page types, tags, and rewarding system. Incorporate "tree view" navigation and advanced search engine for better usability and engagement.

wolfe
Download Presentation

Efficient User Documentation System for Different User Types

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. ]po[ Docu Wiki

  2. Types of Readers • Beginners • These users have just started using ]po[. • Need to learn about the possibilities of the system • Need to understand how to search for information and how to enter basic information • Beginners should start off with “Process Tutorials” • Reference pages need to link to relevant Process Tutorials • Intermediates • These users have started to use the system regularly during their work, for example as Project Managers or Senior Managers • Start to question the behavior of the system • Need to understand the specific semantics of fields • Need help to organize their information in ]po[ • Will read the object_type_xxxx pages with the meaning of the fields • Advanced • These are usually the Application Admins of a customer • Needs very specific information about object fields or the type of information displayed. • Need information about the parameters and permission settings modifying the behavior of the system • We need to link to parameters in the pages where the parameters are used.

  3. Page Types Beginners Localization („de” - German) Module („Finance“) Process („Timesheet Invoicing“) Package („intranet-invoicing“) (only as reference) Tutorial(?) („Timesheet Invoicing“) „Tutorial“ and „Object Type“ are the main page types in the Docu-Wiki. All other pages are basically indices to these pages. Intermediate Object Type („Expense“) Entry pointsfrom ]po[ help View/Edit Page („Expense View Page“) List Page („Expense List Page“) Portlet („Project Expense Portlet“) Entry pages from ]po[: List- View and Edit-pages link to their respective pages in the Wiki. These pages represent entry-points for the user and should contain links to useful associated pages. Advanced API-DOCIntegration(?) DatabasePPTs(?) Parameter („ ..“)

  4. General Ideas/Requirements • Tag each page with object_type, module and process. Tags are used for automatic “related tutorials” • We need a “tree view” like MS-Office help • We need a special “help-search” engine that only indexes help topics • Statistics per page tell us where we need to extend the documentation • User can rate pages for “usefulness” • Users can leave comments/discuss around pages using General Comments (GC) package • A reward system should deliver “contributor of the week/ month”. Each page should have a list of contributors with link to the contributor’s web page. • Mark each page from 1-5 with “advancedness” • A full-text search engine should index all pages • All pages should be Google-friendly and search engine optimized!

  5. Tags • All Wiki pages can be tagged • We need to define a standard set of tags throughout the Wiki • We want to use tags to show the user the list of “related tutorials” for each page • We need to cover a “query” such as: “Give me the list of all tutorials related to costs” => Each tutorial needs to be tagged as “tutorial” (=type of page) and with the object types related to the tutorial

  6. Open Questions • Should we import/link to procedures and procedure package lists in api-doc from the Wiki? • All page types should have the same structure. We still need to define this structure. • We need a “contents” tree at the left or right side of the help page that allows the user to move within the help pages. This tree needs to be organized by type of page. • Should we use “Wiki folders” to structure contents? For example, we could create all “tutorial” or “object type” pages within a specific folder and avoid tags this way?

  7. Types of Pages • This sections lists all available types of pages in the documentation Wiki

  8. Tutorial Page • Naming: tutorial_project_tracking • Audience: Beginners and some Advanced users • Description: A short description of the tutorial • Contents: Either a re-formatted PO-Guide, or a PowerPoinst presentation. • In general, it’s OK to have relatively long tutorial pages, that’s good for being indexed by Google • Long tutorials may have several sections. Each section should have a naming “tutorial_project_tracking_01” etc. Not sure about the _01, might be other

  9. Name of the database table, but singular! Object Type Page • Naming: object_type_im_project (all underscores) • One page per object_type • Description of all database fields • Description of “status” lifecycle and their meaning • Description of “type” sub-types and their meaning • Permissions • Privileges involved • Object’s permission • References • Package where the object type is defined • Module to which the package belongs • Processes where the object type appears • Tables related to the object_type • Project • Company • User/Person • … (50)

  10. Object View Page • Naming: view_page_im_project • References • Object type of the object displayed • Link to object’s permissions • Components displayed • Project View Page • Company View Page • … (~30)

  11. Object New Page • Naming: new_page_im_project • References • Object type of the object displayed • Link to object’s permissions • Components displayed • Project New Page • Company New Page • … (~30)

  12. Object List Page • Naming: list_page_im_project • References • Object type of the object displayed • Meaning of filter fields • Link to object’s permissions • Specific List Page permissions if applicable • Project List Page • User List Page • Company List Page • … (~30)

  13. Portlet • Naming: portlet_home_workflow_inbox • The portlet page is a kind of “entry point” when users click on a portlet’s help button. The portlet page mainly links to the business object, the package and the processes related to the portlet. • References • Page where the portlet appears • Object type of the object displayed • Link to object’s permissions • Home Workflow Inbox • Home Project List • … (~100)

  14. Package All underscores, even if the package is written with dash. • Naming: package_intranet_core • Description (from package manager) • License • References • Object types defined in the package • Module to which the package belongs • api-doc functions defined in the package • (package names according to package manager) • intranet-core • intranet-hr • intranet-freelance • intranet-freelance-rfqs • … (~150)

  15. Process • Naming: process_project_tracking • Description • from PO-Users-Guide manual • References • Module to which the process belongs • Object type related to the process • Packages related to the process • Project Tracking • Project Planning • Invoicing • HR Recruiting • HR Training • Sales • Marketing • Translation Mgmt • Ticket Mgmt • … (~30)

  16. Module • Naming: module_finance • Description • high-level from Web site • References • Object type related to the module • Packages related to the module • Finance • Project Management • Service Management • HR • Inventory Management • … (~15)

  17. Pattern Page • Naming: pattern_project_name_generator • Description • High-level description of the pattern. Example: The “Project Nr Generator” represents a “number circuit” for generating unique project numbers. • References • Object type related to the pattern • Packages related to the pattern • Project Number Generator • Sales Pipeline • … (~100)

  18. Category • Naming: category_project_types (exactly like in /intranet/admin/categories/, but without the “Intranet”). • Description • Detailed description of categories • References • Packages related to the category • Intranet Project Types • Intranet Project Status • … (~100, according to /intranet/admin/categories/)

  19. Parameter • Naming: parameter_basepathunix • Description • high-level from Web site • References • Packages related to the parameter • Object types related to the parameter • BasePathUnix • TimesheetPermissionPolicy • … (~500, copy from parameter page)

  20. Localization Page • Naming: l10n_de (de=German) • These pages represent the home-pages for the localization of ]po[ into different languages and provide the translators with a discussion forum. • Translators may discuss about terminology etc. • Additional language specific pages should be prefixed with “l10n_de_xxxx”.

  21. Glossary Entry • Naming: glossary_portlet • Defines terms used in the help texts • Tagged with tag “glossary”

  22. Examples

  23. Example: object_type_im_project • Beginner: For an introduction to project please see: • Project Tracking Tutorial • Project Management Tutorial • Project Invoicing Tutorial • A project represents units of work. • A project may contains several sub-projects and tasks. • Fields: • Project name: A human readable name of the project. Project names at the same level are unique (duplicates are not allowed). Project names are indexed by the search engine. • Project nr: A short name of the project. The project nr are generated automatically by the system using the [project nr generator]. • - … • Project Status: Description of lifecycle status and their meaning • Project Type: Description of sub-types and their meaning • Permissions • References • Package where the object type is defined • Module to which the package belongs • Processes where the object type appears • Tables related to the object type • Project • Company • User/Person • … (50)

More Related