Skip to content

Commit 4214bed

Browse files
authored
Merge pull request #130 from redhat-documentation/issue-126
WIP: Add [system:abstract] to concept, reference, procedure templates
2 parents f49c516 + 63b6c6a commit 4214bed

5 files changed

+126
-58
lines changed

modular-docs-manual/content/topics/using_text_snippets_or_text_fragments.adoc

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -7,9 +7,9 @@
77
// * ID: [id="my-concept-module-a_{context}"]
88
// * Title: = My concept module A
99

10-
// The ID is used as an anchor for linking to the module. Avoid changing it after the module has been published to ensure existing links are not broken.
10+
// The ID is an anchor that links to the module. Avoid changing it after the module has been published to ensure existing links are not broken.
1111
[id="using_text_snippets_or_text_fragments_{context}"]
12-
// The `context` attribute enables module reuse. Every module's ID includes a variable that sets the context, such as {context}, which ensures that the module has a unique ID even if it is reused multiple times in a guide.
12+
// The `context` attribute enables module reuse. Every module ID includes a variable that sets the context, such as {context}, which ensures that the module has a unique ID even if it is reused multiple times in a guide.
1313
= Text Snippets or Text Fragments (Pseudo-modules)
1414
//In the title of concept modules, include nouns or noun phrases that are used in the body text. This helps readers and search engines find the information quickly.
1515
//Do not start the title of concept modules with a verb. See also _Wording of headings_ in _The IBM Style Guide_.

modular-docs-manual/files/TEMPLATE_ASSEMBLY_a-collection-of-modules.adoc

Lines changed: 44 additions & 18 deletions
Original file line numberDiff line numberDiff line change
@@ -2,45 +2,71 @@
22
//
33
// <List assemblies here, each on a new line>
44

5-
// Retains the context of the parent assembly if this assembly is nested within another assembly.
6-
// For more information about nesting assemblies, see: https://redhat-documentation.github.io/modular-docs/#nesting-assemblies
7-
// See also the complementary step on the last line of this file.
5+
////
6+
Retains the context of the parent assembly if this assembly is nested within another assembly.
7+
For more information about nesting assemblies, see: https://redhat-documentation.github.io/modular-docs/#nesting-assemblies
8+
See also the complementary step on the last line of this file.
9+
////
10+
811
ifdef::context[:parent-context: {context}]
912

10-
// Base the file name and the ID on the assembly title. For example:
11-
// * file name: my-assembly-a.adoc
12-
// * ID: [id="my-assembly-a"]
13-
// * Title: = My assembly A
13+
////
14+
Base the file name and the ID on the assembly title. For example:
15+
* file name: assembly-my-user-story.adoc
16+
* ID: [id="assembly-my-user-story_{context}"]
17+
* Title: = My user story
18+
19+
The ID is an anchor that links to the module. Avoid changing it after the module has been published to ensure existing links are not broken. Include {context} in the ID so the assembly can be reused.
20+
////
21+
22+
[id="assembly-my-user-story_{context}"]
23+
= My user story
24+
////
25+
If the assembly covers a task, start the title with a verb in the gerund form, such as Creating or Configuring.
26+
////
1427
15-
// The ID is used as an anchor for linking to the module. Avoid changing it after the module has been published to ensure existing links are not broken.
16-
[id="a-collection-of-modules"]
17-
// If the assembly is reused in other assemblies in a guide, include {context} in the ID: [id="a-collection-of-modules_{context}"].
18-
= A collection of modules
19-
//If the assembly covers a task, start the title with a verb in the gerund form, such as Creating or Configuring.
2028
:context: assembly-keyword
21-
// The `context` attribute enables module reuse. Every module's ID includes {context}, which ensures that the module has a unique ID even if it is reused multiple times in a guide.
2229
23-
This paragraph is the assembly introduction. It explains what the user will accomplish by working through the modules in the assembly and sets the context for the user story the assembly is based on. Can include more than one paragraph. Consider using the information from the user story.
30+
////
31+
The `context` attribute enables module reuse. Every module ID includes {context}, which ensures that the module has a unique ID so you can include it multiple times in the same guide.
32+
////
33+
34+
[role="_abstract"]
35+
This paragraph is the assembly introduction. It explains what the user will accomplish by working through the modules in the assembly and sets the context for the user story the assembly is based on. The text that immediately follows the `[role="_abstract"]` tag is used for search metadata.
2436
2537
.Prerequisites
2638
2739
* A bulleted list of conditions that must be satisfied before the user starts following this assembly.
2840
* You can also link to other modules or assemblies the user must follow before starting this assembly.
2941
* Delete the section title and bullets if the assembly has no prerequisites.
42+
* X is installed. For information about installing X, see <link>.
43+
* You can log in to X with administrator privileges.
3044
31-
// The following include statements pull in the module files that comprise the assembly. Include any combination of concept, procedure, or reference modules required to cover the user story. You can also include other assemblies.
45+
////
46+
The following include statements pull in the module files that comprise the assembly. Include any combination of concept, procedure, or reference modules required to cover the user story. You can also include other assemblies.
47+
////
3248
3349
include::modules/TEMPLATE_CONCEPT_explaining_a_concept.adoc[leveloffset=+1]
34-
// [leveloffset=+1] ensures that when a module starts with a level-1 heading (= Heading), the heading will be interpreted as a level-2 heading (== Heading) in the assembly.
3550
36-
include::modules/TEMPLATE_PROCEDURE_doing_one_procedure.adoc[leveloffset=+1]
51+
////
52+
[leveloffset=+1] ensures that when a module title is a level 1 heading (= Title), the heading will be interpreted as a level-2 heading (== Title) in the assembly. Use [leveloffset=+2] and [leveloffset=+3] to nest modules in an assembly.
53+
////
54+
55+
include::modules/TEMPLATE_PROCEDURE_doing_one_procedure.adoc[leveloffset=+2]
56+
include::modules/TEMPLATE_PROCEDURE_reference-material.adoc[leveloffset=2]
3757
58+
[role="_additional-resources"]
3859
== Additional resources (or Next steps)
60+
////
61+
Optional. Delete if not used.
62+
////
3963
4064
* A bulleted list of links to other material closely related to the contents of the assembly, including xref links to other assemblies in your collection.
4165
* For more details on writing assemblies, see the link:https://github.com/redhat-documentation/modular-docs#modular-documentation-reference-guide[Modular Documentation Reference Guide].
4266
* Use a consistent system for file names, IDs, and titles. For tips, see _Anchor Names and File Names_ in link:https://github.com/redhat-documentation/modular-docs#modular-documentation-reference-guide[Modular Documentation Reference Guide].
4367
44-
// Restore the context to what it was before this assembly.
68+
////
69+
Restore the context to what it was before this assembly.
70+
////
4571
ifdef::parent-context[:context: {parent-context}]
4672
ifndef::parent-context[:!context:]

modular-docs-manual/files/TEMPLATE_CONCEPT_concept-explanation.adoc

Lines changed: 26 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -2,29 +2,42 @@
22
//
33
// <List assemblies here, each on a new line>
44

5-
// Base the file name and the ID on the module title. For example:
6-
// * file name: my-concept-module-a.adoc
7-
// * ID: [id="my-concept-module-a_{context}"]
8-
// * Title: = My concept module A
5+
////
6+
Base the file name and the ID on the module title. For example:
7+
* file name: con-my-concept-module-a.adoc
8+
* ID: [id="con-my-concept-module-a_{context}"]
9+
* Title: = My concept module A
10+
////
911

10-
// The ID is used as an anchor for linking to the module. Avoid changing it after the module has been published to ensure existing links are not broken.
11-
[id="concept-explanation_{context}"]
12-
// The `context` attribute enables module reuse. Every module's ID includes {context}, which ensures that the module has a unique ID even if it is reused multiple times in a guide.
13-
= Concept explanation
14-
//In the title of concept modules, include nouns or noun phrases that are used in the body text. This helps readers and search engines find the information quickly.
15-
//Do not start the title of concept modules with a verb. See also _Wording of headings_ in _The IBM Style Guide_.
12+
////
13+
The ID is an anchor that links to the module. Avoid changing it after the module has been published to ensure existing links are not broken.
14+
////
1615

17-
A short introductory paragraph is required for the concept module.
18-
It will provide an overview of the module.
16+
[id="con-my-concept-module-a_{context}"]
17+
18+
////
19+
The `context` attribute enables module reuse. Every module ID includes {context}, which ensures that the module has a unique ID so you can include it multiple times in the same guide.
20+
////
21+
22+
= My concept module A
23+
////
24+
In the title of concept modules, include nouns or noun phrases that are used in the body text. This helps readers and search engines find the information quickly. Do not start the title of concept modules with a verb. See also _Wording of headings_ in _The IBM Style Guide_.
25+
////
26+
27+
[role="_abstract"]
28+
Write a short introductory paragraph that provides an overview of the module. The text that immediately follows the `[role="_abstract"]` tag is used for search metadata.
1929

2030
The contents of a concept module give the user descriptions and explanations needed to understand and use a product.
2131

2232
* Look at nouns and noun phrases in related procedure modules and assemblies to find the concepts to explain to users.
2333
* Explain only things that are visible to users. Even if a concept is interesting, it probably does not require explanation if it is not visible to users.
2434
* Do not include any instructions to perform an action, such as executing a command. Action items belong in procedure modules.
2535

36+
[role="_additional-resources"]
2637
.Additional resources
27-
38+
////
39+
Optional. Delete if not used.
40+
////
2841
* A bulleted list of links to other material closely related to the contents of the concept module.
2942
* Currently, modules cannot include xrefs, so you cannot include links to other content in your collection. If you need to link to another assembly, add the xref to the assembly that includes this module.
3043
* For more details on writing concept modules, see the link:https://github.com/redhat-documentation/modular-docs#modular-documentation-reference-guide[Modular Documentation Reference Guide].

modular-docs-manual/files/TEMPLATE_PROCEDURE_doing-one-procedure.adoc

Lines changed: 37 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -2,18 +2,28 @@
22
//
33
// <List assemblies here, each on a new line>
44

5-
// Base the file name and the ID on the module title. For example:
6-
// * file name: doing-procedure-a.adoc
7-
// * ID: [id="doing-procedure-a"]
8-
// * Title: = Doing procedure A
9-
10-
// The ID is used as an anchor for linking to the module. Avoid changing it after the module has been published to ensure existing links are not broken.
11-
[id="doing-one-procedure_{context}"]
12-
// The `context` attribute enables module reuse. Every module's ID includes {context}, which ensures that the module has a unique ID even if it is reused multiple times in a guide.
5+
////
6+
Base the file name and the ID on the module title. For example:
7+
* file name: proc-doing-procedure-a.adoc
8+
* ID: [id="doing-procedure-a_{context}"]
9+
* Title: = Doing procedure A
10+
////
11+
The ID is an anchor that links to the module. Avoid changing it after the module has been published to ensure existing links are not broken.
12+
////
13+
14+
[id="proc-doing-one-procedure_{context}"]
15+
16+
////
17+
The `context` attribute enables module reuse. Every module ID includes {context}, which ensures that the module has a unique ID even if it is reused multiple times in a guide.
18+
////
19+
1320
= Doing one procedure
14-
// Start the title of a procedure module with a verb, such as Creating or Create. See also _Wording of headings_ in _The IBM Style Guide_.
21+
////
22+
Start the title of a procedure module with a verb, such as Creating or Create. See also _Wording of headings_ in _The IBM Style Guide_.
23+
////
1524

16-
This paragraph is the procedure module introduction: a short description of the procedure.
25+
[role="_abstract"]
26+
Write a short introductory paragraph that provides an overview of the module. Procedure modules should include the steps that users perform and address user motivation.The text that immediately follows the `[role="_abstract"]` tag is used for search metadata.
1727

1828
.Prerequisites
1929

@@ -25,15 +35,29 @@ This paragraph is the procedure module introduction: a short description of the
2535

2636
. Start each step with an active verb.
2737

38+
. Include one command or action for each step with the exception of simple follow-step, for example:
39+
.. Do this thing and then select *Next*.
40+
.. Do this other thing and then select *Next*.
41+
42+
. Use an unnumbered bullet (*) if the procedure includes only one step.
43+
44+
.Verification steps
45+
////
46+
Delete this section if it does not apply to your module. Provide the user with verification methods for the procedure, such as expected output or commands that confirm success or failure.
47+
////
48+
49+
. Start each step with an active verb.
50+
2851
. Include one command or action per step.
2952

3053
. Use an unnumbered bullet (*) if the procedure includes only one step.
3154

32-
//.Verification steps
33-
//(Optional) Provide the user with verification method(s) for the procedure, such as expected output or commands that can be used to check for success or failure.
3455

56+
[role="_additional-resources"]
3557
.Additional resources
36-
58+
////
59+
Optional. Delete if not used.
60+
////
3761
* A bulleted list of links to other material closely related to the contents of the procedure module.
3862
* Currently, modules cannot include xrefs, so you cannot include links to other content in your collection. If you need to link to another assembly, add the xref to the assembly that includes this module.
3963
* For more details on writing procedure modules, see the link:https://github.com/redhat-documentation/modular-docs#modular-documentation-reference-guide[Modular Documentation Reference Guide].

modular-docs-manual/files/TEMPLATE_REFERENCE_reference-material.adoc

Lines changed: 17 additions & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -2,21 +2,26 @@
22
//
33
// <List assemblies here, each on a new line>
44

5-
// Base the file name and the ID on the module title. For example:
6-
// * file name: my-reference-a.adoc
7-
// * ID: [id="my-reference-a"]
8-
// * Title: = My reference A
5+
////
6+
Base the file name and the ID on the module title. For example:
7+
* file name: ref-my-reference-a.adoc
8+
* ID: [id="ref-my-reference-a_{context}"]
9+
* Title: = My reference A
910

10-
// The ID is used as an anchor for linking to the module. Avoid changing it after the module has been published to ensure existing links are not broken.
11-
[id="reference-material_{context}"]
12-
// The `context` attribute enables module reuse. Every module's ID includes {context}, which ensures that the module has a unique ID even if it is reused multiple times in a guide.
13-
= Reference material
14-
//In the title of a reference module, include nouns that are used in the body text. For example, "Keyboard shortcuts for ___" or "Command options for ___." This helps readers and search engines find the information quickly.
11+
The ID is an anchor that links to the module. Avoid changing it after the module has been published to ensure existing links are not broken.
12+
////
1513

16-
A short introductory paragraph is required for the reference module.
17-
It will provide an overview of the module.
14+
[id="ref-reference-material_{context}"]
15+
////
16+
The `context` attribute enables module reuse. Every module ID includes {context}, which ensures that the module has a unique ID even if it is reused multiple times in a guide
17+
////
18+
= Reference material
19+
////
20+
In the title of a reference module, include nouns that are used in the body text. For example, "Keyboard shortcuts for ___" or "Command options for ___." This helps readers and search engines find the information quickly.
21+
////
1822

19-
A reference module provides data that users might want to look up, but do not need to remember.
23+
[role="_abstract"]
24+
Write a short introductory paragraph that provides an overview of the module. The text that immediately follows the `[role="_abstract"]` tag is used for search metadata. A reference module provides data that users might want to look up, but do not need to remember.
2025
It has a very strict structure, often in the form of a list or a table.
2126
A well-organized reference module enables users to scan it quickly to find the details they want.
2227
AsciiDoc markup to consider for reference data:

0 commit comments

Comments
 (0)