Template talk:BSLjunc: Difference between revisions

From OniGalore
Jump to navigation Jump to search
No edit summary
m (+cat)
 
(2 intermediate revisions by 2 users not shown)
Line 3: Line 3:
A bigger issue is the space that it takes up. The one-line display such as <code>chr_dontaim [ai_name:string | script_id:int] on_off:int{0 | 1}</code> may not be appealing to Generation 2.0, but it fits on one line and does not break the flow of a page that supposedly contains some non-trivial scripting wisdom. Therefore, like in a coding textbook, an effort must be made to make those insets unobtrusive, less in-your-face if you will. A good (counter)example is [[BSL:AI_activity]] as it appears currently. Each section has some text about the meaning and effect of a group of commands, but before the text there's a list of the commands about to be described, and that "list" takes the form of an ill-shaped cluster of boxes that are not hidden by default (can't be hidden at all, for that matter), take up more space than the explanatory text, and remain very distracting while reading the text.
A bigger issue is the space that it takes up. The one-line display such as <code>chr_dontaim [ai_name:string | script_id:int] on_off:int{0 | 1}</code> may not be appealing to Generation 2.0, but it fits on one line and does not break the flow of a page that supposedly contains some non-trivial scripting wisdom. Therefore, like in a coding textbook, an effort must be made to make those insets unobtrusive, less in-your-face if you will. A good (counter)example is [[BSL:AI_activity]] as it appears currently. Each section has some text about the meaning and effect of a group of commands, but before the text there's a list of the commands about to be described, and that "list" takes the form of an ill-shaped cluster of boxes that are not hidden by default (can't be hidden at all, for that matter), take up more space than the explanatory text, and remain very distracting while reading the text.


If this template is modified to be less obtrusive/invasive of a pages's content, I can use it in tutorials; if not, I will use regular typesetting like in [[BSL:Frustum_and_fog]]
If this template is modified to be less obtrusive/invasive of a pages's content, I can use it in tutorials; if not, I will use regular typesetting like in [[BSL:Frustum_and_fog]].
:For example, this template, when transcluded, can display just the name of the variable or function in a monospace font, distinguishing between variables and functions either through a color scheme or through the use of parentheses, e.g., '''<code>am_invert</code>''' can imply a variable, whereas '''<code>ai2_passive(...)</code>''' can imply a function, even if in this context actual arguments for <tt>ai2_passive</tt> are not listed. Placing the mouse over that "code snippet" would call up a hoverbox with the full information about the signature and default values.
::[[User:Geyser|geyser]] ([[User talk:Geyser|talk]]) 11:26, 9 February 2018 (CET)


I agree that the system could use a visual redesign. I was never all that crazy about the size that the command boxes take up. I'll look into fitting all the info on one line. I can also probably create a "short listing" template that just shows the variable/function name with additional info as hovertext. --[[User:Iritscen|Iritscen]] ([[User talk:Iritscen|talk]]) 18:57, 10 February 2018 (CET)
For example, this template, when transcluded, can display just the name of the variable or function in a monospace font, distinguishing between variables and functions either through a color scheme or through the use of parentheses, e.g., '''<code>am_invert</code>''' can imply a variable, whereas '''<code>ai2_passive(...)</code>''' can imply a function, even if in this context actual arguments for <tt>ai2_passive</tt> are not listed. Placing the mouse over that "code snippet" would call up a hoverbox with the full information about the signature and default values. --[[User:Geyser|geyser]] ([[User talk:Geyser|talk]]) 11:26, 9 February 2018 (CET)
 
:I agree that the system could use a visual redesign. I was never all that crazy about the size that the command boxes take up. I'll look into fitting all the info on one line. I can also probably create a "short listing" template that just shows the variable/function name with additional info as hovertext. --[[User:Iritscen|Iritscen]] ([[User talk:Iritscen|talk]]) 18:57, 10 February 2018 (CET)
 
:All right, I've simplified the format for listing variables (functions will be more complicated, so I'm leaving them aside until we can agree on variables). How does look to you? Note the hovertext. --[[User:Iritscen|Iritscen]] ([[User talk:Iritscen|talk]]) 16:58, 20 February 2018 (CET)
::The hovertext for the variable name seems redundant, so I'd change it to display the default value instead (it's a bit counter-intuitive if the default value is displayed only when you hover over the type). So there can be not two hovertexts but one, for the whole field (only the variable name would work as a link to the variable's redirect page).
::Also, I'd make the type listing optional (either with two templates, "verbose" and "minimal", or with a parameter that gives "minimal" display by default). The lack of brackets is enough to identify the variable as a variable and not a function, and the hovertext in the "minimal" case can include the type, something like: "boolean; default value at game start: false".
::There can probably be a second line of hovertext as a reminder of a variable's effect or an indication of the "group" it belongs to - either picked from the database or supplied in the page's context through a parameter. Other than that, it's OK. --[[User:Geyser|geyser]] ([[User talk:Geyser|talk]]) 21:13, 20 February 2018 (CET)
 
[[Category:Table templates]]

Latest revision as of 02:43, 4 May 2022

The template is in itself not a bad idea, although the relative placement of the name/type/value and the respective fonts/colors can perhaps be improved for clarity (if it's all black and has the same typesetting, then the eye doesn't easily jump to the right information, even for someone who actually looks at these boxes rather than at the surrounding text, and knows what they're all about).

A bigger issue is the space that it takes up. The one-line display such as chr_dontaim [ai_name:string | script_id:int] on_off:int{0 | 1} may not be appealing to Generation 2.0, but it fits on one line and does not break the flow of a page that supposedly contains some non-trivial scripting wisdom. Therefore, like in a coding textbook, an effort must be made to make those insets unobtrusive, less in-your-face if you will. A good (counter)example is BSL:AI_activity as it appears currently. Each section has some text about the meaning and effect of a group of commands, but before the text there's a list of the commands about to be described, and that "list" takes the form of an ill-shaped cluster of boxes that are not hidden by default (can't be hidden at all, for that matter), take up more space than the explanatory text, and remain very distracting while reading the text.

If this template is modified to be less obtrusive/invasive of a pages's content, I can use it in tutorials; if not, I will use regular typesetting like in BSL:Frustum_and_fog.

For example, this template, when transcluded, can display just the name of the variable or function in a monospace font, distinguishing between variables and functions either through a color scheme or through the use of parentheses, e.g., am_invert can imply a variable, whereas ai2_passive(...) can imply a function, even if in this context actual arguments for ai2_passive are not listed. Placing the mouse over that "code snippet" would call up a hoverbox with the full information about the signature and default values. --geyser (talk) 11:26, 9 February 2018 (CET)

I agree that the system could use a visual redesign. I was never all that crazy about the size that the command boxes take up. I'll look into fitting all the info on one line. I can also probably create a "short listing" template that just shows the variable/function name with additional info as hovertext. --Iritscen (talk) 18:57, 10 February 2018 (CET)
All right, I've simplified the format for listing variables (functions will be more complicated, so I'm leaving them aside until we can agree on variables). How does look to you? Note the hovertext. --Iritscen (talk) 16:58, 20 February 2018 (CET)
The hovertext for the variable name seems redundant, so I'd change it to display the default value instead (it's a bit counter-intuitive if the default value is displayed only when you hover over the type). So there can be not two hovertexts but one, for the whole field (only the variable name would work as a link to the variable's redirect page).
Also, I'd make the type listing optional (either with two templates, "verbose" and "minimal", or with a parameter that gives "minimal" display by default). The lack of brackets is enough to identify the variable as a variable and not a function, and the hovertext in the "minimal" case can include the type, something like: "boolean; default value at game start: false".
There can probably be a second line of hovertext as a reminder of a variable's effect or an indication of the "group" it belongs to - either picked from the database or supplied in the page's context through a parameter. Other than that, it's OK. --geyser (talk) 21:13, 20 February 2018 (CET)