Document style guide

These guidelines should help you write Analytica documentation that is clear and consistent. The main goal is to avoid unnecessary words and convoluted grammar. Much of it is standard stuff for writers and editors, but some is specific for Analytica documentation. The guidelines apply to this Analytica wiki, to User Guides (currently distributed as PDFs), as well as help text and error messages within Analytica.

Feel free to edit any wiki pages to make them follow this guide more closely.

For style guidelines for Analytica models see Analytica model style guide.

Language

Use imperative, active voice, and present tense

Use imperative when explaining how to do something (as in this document).

Select Graph setup from the Result menu"
Not: The user should select select Graph setup from the Result menu.
And Definitely not: The Graph setup should be selected from the Result menu.

Especially, use imperative especially for a series of steps:

Select Graph setup from Result menu
Check Stacked option
Click OK

Use the active voice:

Avoid the passive voice.
not: The passive voice should always be avoided

With imperatives, the subject is implicitly "you", the user. In other cases active voice means you have to mention the subject explicitly. Often it's "You" (the user):

You can use Function F to ..., Not: "Function F may be utilized to ..."

Sometimes it's "Analytica":

Analytica displays an error message, 'Not: "An error message is displayed."

Given this documentation is all about Analytica, you can usually just say "it":

When you press ctrl+F, it opens the Find dialog.
'Not: When the user presses ctrl+F, the Find dialog is displayed.

Occasionally, you may want to mention "Analytica" to emphasize a special Analytica way of doing things"

Analytica uses name-based subscripting, instead of position-based subscripting common in other languages.

Use present not future tense for what Analytica does:

When you click OK, it closes the dialog.
Not: When you click OK, Analytica will close the dialog.

Introduce an example or a list of options or steps with a colon. Say "these" not "the following":

These are options for parameter X: (note the colon)
Not: The following are options for parameter X.

You, we, it, and Analytica

Refer to the reader or user as "you", and the writer(s) or Lumina as "we".
- Write: "We invite you to email us your comments" Not: "The reader is invited to email Lumina their comments.".

If the recipient would otherwise be ambiguous, write "Please email Lumina your comments." where "your" refers to the reader.

It's fine to refer to Analytica as "it" (she doesn't mind):
- Write: "When you click the button, it displays the dialog box." Not: "When the user clicks the button, Analytica will display the dialog box".
- Definitely not: "When the button is clicked, the dialog box is displayed"
- Mention "Analytica" by name only if "it" is ambiguous. (In Analytica documentation, "it" is rarely ambiguous.)

Common words and concepts

Use short words instead of longer synonyms -- e.g.

"use" not "utilize"
"let" not "allow".

Use "parameter" not "argument" for the things listed in parentheses in a call to a function, or the definition of a function (where the attribute is called Parameters.)

Use long dash or double-dash around examples or interjections (rather than parentheses), as in "Use a reducing function -- e.g. Sum or Min -- rather than a transforming function."

Click, Press, Select

You click a button or link (not click on).
You press a menu to see the menu options (the action is to press and hold)
You select a menu option.
You also select a node or text from a text field.
You press ;(not hit or depress) a key or key combination on the keyboard.

Label web links so that users get a reasonable idea of what they will find on the linked page.

Don't write "click this link" or "click here". People know about clicking links! The browser shows hyperlinked text in blue or underlined (or something) to show that it's clickable.

Analytica terminology

Capitalize terms used with a special meaning in Analytica -- such as, Variable, Object, Attribute, or Diagram -- to distinguish them from their common meaning, which is often subtly different.
There's no need to capitalize standard computer terms -- like, window, menu, button, mouse, keyboard -- or standard mathematical terms -- like, variable, function, parameter, array -- except when they're being used with a special Analytica take on the meaning, as for example, Variable.

Don't use node to mean a Variable or Object. A node is the visual representation in a Diagram of a Variable or other class of Object. An Object can have multiple nodes -- e.g., the original node and aliases, including input and output nodes. A Variable is just one Class of object. For views or operations that apply to all classes of Object, use Object rather than Variable. But, do use node when you are actually referring to creating, finding, moving, or deleting a node (including input or output field) in a Diagram.

Use Edition of Analytica to mean Player, Professional, Enterprise, ADE, ACP, etc..
Use Release as in Release 4.2.
Avoid version because it could mean either Edition or Release.

ADE and ACP are Editions of Analytica, just like Professional and Enterprise. So we don't need to say "Analytica and ADE" or "Analytica and ACP" as we have done often in the past. Optimizer is also an Edition, not an extension or option.

Titles

Page titles

use Sentence case, with the last word in singular, e.g. (User-defined attribute) to enable fast interlinking and readability of the wiki markup, such as

[[User-defined attribute]]s are suitable for creating attributes that do not exist. To create a new [[user-defined attribute]], proceed as follows.

Do NOT use all capitals in plural (e.g. User-Defined Attributes) because it adds visual clutter without adding new information, slows down wiki-linking and makes wiki markup harder to read and edit:

[[User-Defined Attributes|User-defined attributes]] are suitable for creating attributes that do not exist. To create a new [[User-Defined Attributes|user-defined attribute]], proceed as follows.

Titles of Analytica components, such as names of windows, functions etc: use the exact name and capitalization used in the software so that the users will not be confused by different terms.

There is no need to rename all existing pages, but use the suggested style for new pages or when merging multiple pages of similar content.

To make wiki markup easier to read and edit, do NOT use full urls in internal links, i.e. in links to other pages on the Analytica wiki: [http://wiki.analytica.com/index.php?title=User-defined attribute|User-defined attribute].

Lists

Use a bulleted list, like this, wherever appropriate.

Use a numbered or lettered list only where the items are intrinsically ordered, as in a series of steps that would not work in a different order:

Do this
Now do this
Finish up by doing this

There's no need for a period or comma at the end of each item in a list if they are single phrases (as above). But, do use a period if there are multiple sentences, as in this list.
Order the items in a list (or sections in a chapter) starting with the easiest or most-used first. Progress to the most complicated or obscure at the end. That way, readers scanning the list, will:
- find what they want sooner on average,
- read the easy stuff first, preparing them to understand the harder stuff that comes later, if needed.
- Alphabetic ordering adds little: If you already know the name of the function (or whatever), which you would need if you were going to search alphabetically, it's faster to use electronic search.

No list should be longer than 7 to 10 items. If there are more items, organize them as a hierarchy of lists by grouping related items into sublists.

Tables

Use wikitable format to create a table: Precede it by a colon (:)) to indent the table:

:{| class=wikitable
! 
! Column 1
! Column 2
|-
! Row 1
| Cell 11
| Cell 12
|- 
! Row 2
| Cell 21
| Cell 22
|}

The code above yields this table:

	Column 1	Column 2
Row 1	Cell 11	Cell 12
Row 2	Cell 21	Cell 22

See Guide to Converting Documents to MediaWiki for more.

Images

Use the wiki Upload file functionality to upload image files.

Indent images by one tab (precede by one colon (:)), as in:

:[[image:ImageFile.png]]

The wiki syntax for images with centered captions on white background is as follows.

One image:

:{|border=0
|bgcolor=white|[[image:ImageFile.png|frame|<center>Image caption.</center>]]
|}

Two images side-by-side:

:{| border="0"
|bgcolor=white|[[image:ImageFileOne.png|frame|<center>Image caption one</center>]]
|bgcolor=white|[[image:ImageFileTwo.png|frame|<center>Image caption two</center>]]
|}

or

:{|
|bgcolor=white|[[File:ImageFileOne.png|thumb|500px|<center>Image caption one</center>]]
|bgcolor=white|[[File:ImageFileTwo.png|thumb|500px|<center>Image caption two</center>]]
|}

For sample images created this way, see Kernel Density Smoothing and Node Alignment, Sizing, and Spacing.

Formulas

Indent mathematical formulas by one tab (precede by one colon (:)) and surround by <math> tags, e.g.

:<math>
E=mc^2
</math>

which results in

[math]\displaystyle{ E=mc^2 }[/math]

For help with mathematical formulas, see the Wikipedia help page.

Code

These guidelines make code easier to read. We strongly recommend them for code examples in this wiki, as well as Analytica models and libraries:

Indent code lines by one tab, by putting a colon, ":" at the start of each line.

Colons are better than spaces because spaces are harder to see and count in wiki markup, the code is easier to read on the more contrasting white background than the gray background displayed with using spaces, and the true-type font is sufficient to distinguish code from the surrounding text.

Capitalize the first character of the identifier of global Variables, Functions and other global objects, such as Speed_of_light, C, Sum().
For longer identifiers, use CamelCase to separate words, such as SpeedOfLight, DetermTable.

Use uppercase for key words and constructs, like IF...THEN.. ELSE, BEGIN END, FOR... DO... VAR, METAVAR etc.
Use lowercase for identifiers of local variables and parameters in Parameter Definition, upper case for indexes parameters, for example

Function Quadrate(x, y, i, j)

Some people prefer uppercase for Index parameters, as in:

Function Quadrate(x, y, I, J)

Use right-arrow "→" to mean "the preceding expression generates the following result":

 10^5 → 100K

Use Suffix notation for numbers, unless there is a reason not to. It's clear, compact, and Analytica's default.

Using spaces in code and expressions

Examples:

 a + b*c/(d - e)^2 AND (x < y) OR (u = v)
 Not: a+b *c/( d-e )^2 AND (x<y) OR ( u=v )
 Sum(10 + X, I) - (1 + X^2)/(X - 1)
 Not: Sum( 10+X,I )-(1+X ^ 2 )/( X-1 )

Guidelines

Add a space around low-precedence operators +, -, =, <, <=, >=, >, <>
Don't add space around high-precedence operators "*", "/", and "^".
Add a space after, but not before, separators ",", ":" and ";"
Don't put spaces after an open paren or bracket "(" or "[" or before a close paren or bracket: ")" or "]"

When specifying the actual or formal parameters of a function, use the same guidelines"

No space after or before "(" and ")".
Space after but not before separators ",", ":" and ";"
Use lowercase or camelcase for formal function parameters (except for indexes I, J, K)
Use uppercase first letter for qualifiers:

Function F(x: Number; I: Index; camelCaseX: Optional Text)

Not:

Function F( x : number; i:Index ; CamelCaseX : optional text)

Indent multiline expressions (Definitions) with four spaces per indent, the default provided by Analytica when you enter tab.

The Title of a user-defined Function should be identical to its identifier, using underscore "_" to replace any spaces or other non-alphanumeric chars. Add in a list of parameters without qualifiers in parens. The parameter list can omit rare optional parameters. That makes it easy to find and select Functions from a library -- e.g.

Function Flatten_array

Title: Flatten_array(x, I, J, J)

Parameters (x: [i, J]; I, J, K: Index)

Other typographic conventions

As we move the Analytica Tutorial, User Guide, Optimizer Guide, and ADE User Guide to the Analytica Wiki, we need to retain consistency of typographic conventions. In Framemaker, each of these is a character style (see tag in right column). Unfortunately, the wiki doesn't offer such special styles, so we adopt these conventions:

Type of Text	Typography	Example	Wiki Code	FrameMaker Character Tag
Special Analytica term	Capitalize and link when used with special Analytica meaning, but not when used in its normal sense.	Intelligent Arrays, Attributes	[[Intelligent Arrays]]	Default font
Window title, menus, menu item, dialog box title, panel title, and button label	Bold	File, Attribute Panel	'''File'''	UI Object
Analytica global object identifier or title, including variable or module	Bold	for example variable X, X	'''X'''	UI Object
Checkbox label and other input label	Italics	Edit Attributes setting for the Preferences dialog	''Edit Attributes''	UI Label
Key on keyboard	Italics	"Press Enter"; control+e	Press ''Enter''	Emphasis
Function name	Linked (which bolds functions when on their own page) with trailing parens, "()". No links needed when embedded in code.	Sequence()	[[Sequence]]()	Function
Formal parameter name -- i.e. the declared name of a function parameter distinct from the actual parameter, which is the value or expression passed in a call to a function	Use lowercase or "camelCase"; surround by by double angled brackets «a», except when inside formal parameter declaration (within parens after function name). Italicize optional parameters when inside parentheses. Code (courier) font so `I` appears distinct from the number 1.	`Sort(a, I, keyIndex ); «a», «I», «keyIndex»`	«a»How does one find these characters? - Install English (United States) International keyboard - for « use AltGr (Right-Alt) + [ - for » use AltGr (Right-Alt) + ]	Parameter
parameter qualifier	Capitalize to distinguish from formal parameter names	Bool, Text, Number	Bool	Parameter
Code and script examples, expressions and variable definitions	`Fixed width font, indented rows`	`MDTable(T,Rows,Cols,[Car_type,Mpg],'average','n/a')`	This can be done by 1) using colons (for indentation) and code tags: :<code>MDTable(T, Rows, Cols, [Car_type, Mpg], 'average', 'n/a')</code> 2) using colons and <tt> tags: :<tt>MDTable(T, Rows, Cols, [Car_type, Mpg], 'average', 'n/a')</tt> 3) putting a space at the beginning of the line (the code will be displayed in a gray box): MDTable(T, Rows, Cols, [Car_type, Mpg], 'average', 'n/a') 4) surrounding the code by <pre> tags (preferred method with multi-line code): <pre style="background:white; border:white; margin-left: 1em;"> MDTable(T, Rows, Cols, [Car_type, Mpg], 'average', 'n/a')	Code
Error message examples	`Fixed width font in italics, indented rows`	`You cannot evaluate a call to RunConsoleProcess directly from an input variable.`	This can be done by 1) using colons (:) in front of every row for indentation and <code> tags around every row::<code>''You cannot evaluate a call to RunConsoleProcess directly from an input variable.''</code> 2) using <pre>tags around text (preferred method with multi-line error messages): <pre style="background:white; border:white; margin-left: 1em; font-style:italic"> You cannot evaluate a call to RunConsoleProcess directly from an input variable.
Document name	Italics and Capitalized	User Guide	''User Guide''	Emphasis

Conventions for explaining functions and their parameters

The heading for the section of documentation on a function should contain the name of function and the most common parameters, without qualifiers. Don't include optional parameters unless they are usually used.

Function definition sections should use a Heading2 paragraph tag for the function title for the section.

In some cases, we include several related functions in one section. Then we should include them all in the same heading, e.g.

PDF(x) and CDF(x)

Conventions: Use the recommended name for each qualifier rather than its deprecated synonyms. Omit "Atomic" which is of more interest to the implementer than the user of a function.

Use these conventions for naming parameters that don't have otherwise meaningful names, to indicate what type is expected:

x, y, z: Numbers that may be scalar or array-valued.
I, J, K: Identifiers of Index variables
t, t1, t2: Text values (numbers will be coerced to text)
a, b, c: An expression that may evaluate to anything: Scalar or array, number or text, NAN, or reference.
p, q: A probability, a number between 0 and 1.
r: A reference
v: Identifier of variable.
expr: An expression, which is not evaluated before calling function
obj or o: A handle to an an Object (of any Class)
attrib: The identifier of an Attribute

Most named parameters in the User Guide that are not meaningful (unlike mean, min, mode) already follow these conventions. If any do not, we should consider changing them so they do.

Provide a page explaining these conventions, linked to from every function description.

Each function description should have these sections (where appropriate):

Title of section (usually 3= level) includes name of function and most common parameters.
Brief description of at least one simple case use.
Example(s)
Requirements: Expectations or constraints on parameters.
If there are many parameters, list them as a bulleted list, explaining each one
More complex examples
Syntax: Near bottom using (slightly cleaned) declaration syntax.

In this wiki, each section describing a function should contain a complete spec of its parameters, usually near the end of the section, with a format like this:
Parameter types: MakeDate(year: Coerce Atomic Positive; month, day: Optional Coerce Atomic Positive)
Note that the subhead Parameter types is a link to a page that explains the meaning of the parameter types and qualifiers.

Guidelines for Analytica wiki

Organizing documents with multiple pages

Organize the pages into a set of "documents", such as Tutorial, User Guide, Optimizer Guide, ADE User Guide, Analytica Reference Guide, Analytica FAQs, Analytica libraries.

Organize each document or section as a tree hierarchy -- i.e., where each page has a single parent -- although there may, of course, be many cross-references. A tree makes it easier for you to understand the organization, and go through all pages at a given level. It also makes it easier to generate a sequential PDF or printed document if we need to.

Show ancestor list (a.k.a. "bread crumbs") at the top of each page -- i.e. a list of links to parent, grandparent etc. For example, page SolverInfo should show

Analytica Reference Guide > Enhancements to Optimizer in Analytica 4.0 This helps you see where you are and lets you quickly move up one or more levels.

Organizing a page

Keep page names as short as reasonable.

Show ancestor list (see above)

Common subheads:
- Examples
- Syntax
- Tips
- See also
- History: Summarizes when a new feature was introduced or modified. Move all links like "New in Release 4.1" to the History section (or just delete them)

- Enhancement requests
- Documentation requests

What's new? and History

Many features have links to the "What's new" page from when they were first introduced, e.g.

What's new in Analytica 4.2? >

All of these links except the most recent (currently Release 4.6) should be moved to the History section at the end of each page, to minimize ancient "What's new" links of little interest to 99% of readers.