2023:Article Template

BE AWARE: The first line of any article should be {{AutoVersion}} This creates the version control box below.

This article is about an older version of Grooper.

Information may be out of date and UI elements may have changed.

2025

2023

Start with a quick one to three sentence "glossary" style definition of the subject to introduce the topic here. The glossary term should be added to the Glossary page and transcluded from there.

Optional: Expand the introduction here with a few more sentences (only if necessary). Longer "about" or "overview" information should be included in the article's first major section heading.

All articles should include Grooper ZIP files. ZIP files should be linked at the start of the article before the first section heading. Use the "download-box" style to call out downloads like the one below. See the Article Standards for more specifics on Grooper ZIP standards.

You may download the ZIP(s) below and upload it into your own Grooper environment (version 2023). The first contains one or more Batches of sample documents. The second contains one or more Projects with resources used in examples throughout this article.

A note on sections in articles

Use sections (h2) to break up information in your article.
Use sub-sections (h3, h4, etc) to further break up complex information into more consumable (and linkable) parts.
While we have gone away from a rigidly prescribed section structure in our articles, the following 4 sections should likely be included in each article, in some way.

First Section: What is it?

Tell the reader what the feature/configuration object is.
Explain what it does.
This section is for overviewing the feature. It should be a "view from above" or "at a glance" in terms of detail. Include enough information so the reader can generally understand the feature's function.

Include screenshots, illustrations or a small supademo to overview what the feature is.

You may name this section whatever you think is most appropriate. Or just name it "What is {ArticleTopic}?"

Second Section: What is it for?

Tell the reader how the feature/configuration object is used.
Explain why people use this feature.
- What problem does it solve?
- If it prepares content for downstream processing, what is it doing and how does it help?
This section is about helping the reader understand the feature's utility and usefulness. If a user doesn't understand a feature's purpose, they are less likely to use it and more likely to misuse it.

Include screenshots, illustrations or a small supademo to overview the feature's use.

You may name this section whatever you think is most appropriate. Or just name it "What is {ArticleTopic} used for?"

Third Section: How do I set it up? (Or for UI Elements - How do I use it?)

For configuration objects

Explain how to configure the feature.
You must include at least describe the most "basic" or "standard" configuration.
For more complicated features, this section will likely result in several sub-sections detailing different configuration scenarios.

Must include supademos for each configuration scenario. This is likely to be the most supademo heavy section.

For UI Elements

Explain how to configure the feature.
You must include at least describe the most "basic" or "standard" configuration.
For more complicated features, this section will likely result in several sub-sections detailing different configuration scenarios.

You may name this section whatever you think is most appropriate. Or just name it "How to set up {ArticleTopic}"

Fourth Section: Examples

How does it work?

If you can't adequately explain the topic in the introductory paragraph, the "About" section will allow you to expand. What differentiates the Wiki from the is the Wiki answers "How? and Why?" where the Help Documentation answers "What?". Help Documentation explains "what" something is in Grooper. Wiki articles should expand this to "how" something functions and is used. The About section expands on how something works in Grooper. You can't always get a good idea of how something works in Grooper with the description given in the help documentation. The About section gives you more room to demonstrate how something works.

This should be a high level/general explanation.
Visual aids are encouraged, including:
- Diagrams
- Document screenshots
  - Be sure all documents are "public facing". They cannot come from a client or have personal data. Use public records or mocked up documents.
- Grooper UI screenshots
Screenshots and images are highly encouraged here to aid your explanation. Most people learn better with visual aids.
This section should be mostly conceptual. The "How To" and "Use Cases" section can reinforce your explanation here with specifics.

How To

How do I use it?

Here, guide your readers through configuring Grooper to solve a problem around the topic.

Set goals. Explain what the problem is, what the desired result is, and how the topic addresses it before getting into configuration specifics
These instructions should guide the reader step by step of how to do something in Grooper.
- Number your steps to keep readers on the right path.
- Show. Don't tell. Use screenshots to show the reader what they will see in Grooper.
You can have as many "How To" sections as necessary.
- If a single set of instructions starts to get complicated, with many many steps involved, break it up into a series of How Tos.

Current screenshot guidance:
- BE AWARE: As of Q4 2023, DO NOT use tabbed containers for screenshots. We are phasing out tabbed containers.
- Use full screen screenshots.
- Detail steps on the screenshot itself.
- Text steps should be typed above each screenshot.
- Don't crowd the screenshot with words. Keep text breif and "to the point" on screenshots. Use the text steps above the screenshot to explain further if needed.

Example screenshot with how to text:

With the Execute step selected, go to the "Activity Testing" tab.
Select the document from the "EDI Integration - Batch" in the Batch Viewer.
Click the "Test" button to test the activity and get extraction results.

Use Cases

This section is optional. Only detail a use cases section if it is well thought out, descriptive and adds to the article. Don't feel you need to add this section if you don't have a good use case example.

Why do I need it?

Use Cases provide specific context of how the topic is applied in the "real world". Here you can detail solutions the topic addresses.

This should be a more specific/example driven explanation.
Screenshots can be very helpful here.
- Be careful what images you use. Any documents need to be "Public Facing", lacking any proprietary client or personal data. Use public records or mocked up documents.
Include multiple examples when possible.

Version Differences

As Grooper improves, its implementation changes. If a new version changes how a topic is configured, it should be pointed out here.

This section is optional. Only outline important differences from in-support versions of Grooper. For example, if Grooper changed from version 2.90 to 2021 but 2.90 has reached EOL, you don't need to document the change in a 2024 article.

Wiki Article Versioning Guidance

All new articles should be written from the perspective of the current release version of Grooper.
- Articles written in the Main wiki namespace are assumed to cover the current version.
Articles written for older versions are migrated to a namespace corresponding to their version number
- For example, if this article was originally written for version 2.72 it would be moved into the 2.72 namespace and renamed "2.72:Article Template".
Articles from older versions are linked at the top of each article thanks to the {{AutoVersion}} markup at the first line of the article.
If you need to link to an article from a specific version, be sure to include its namespace in the link. The following would link to the 2.72 version of this article:
- 2.72:Article Template