Consider changing variable markers in documentation

A quick additional thought:

It’s not ideal for printed or screen-reader purposes, BUT:

a hover effect on parameters might be very helpful, where

[range[18],[65]]

is what you see, but if you hover over [18] the expression [18] gets a background-highlight effect, and the tooltip shows

[18] (hard parameter)
{!!minimum-age} (indirect)
<changecount> (variable)

or something like that. Just brainstorming here…

Certainly something like this can help. In practice, still, the problem is that mid-level users often are uncertain exactly where/how a variable can be swapped in. Having filter parameters jump out somehow, with clarity about the common ways that curly and angle brackets look in practice, would be ideal.

2 Likes

While I’m not generally a fan of obscuring TW mechanisms behind documentation macros, I do think that a procedure (or perhaps a <$docs.filters> widget, as @Scott_Sauyet suggested) might be the best way to balance ease of input with the need for more sophisticated (and ideally, transparent) display. Here’s a quick, procedure-based mockup of the sort of dynamic display I would find most useful myself, borrowing some inspiration from @EricShulman’s earlier suggestion:

\function .docs-param-config() [[$:/temp/docs-config/]] [<storyTiddler>] +[join[]]

\procedure .docs-param(label)
	\function .param-type() [<.docs-param-config>get[text]] ~string
	\function .param-display()
		[<.param-type>match[variable]then[<XX>]]
		~[<.param-type>match[transclusion]then[{!!XX}]]
		~"[XX]"
		+[search-replace[XX],<label>]
	\end .param-display
<<.param-display>>
\end

\procedure .docs-param-select()
<$select tiddler=<<.docs-param-config>> class="tc-float-right" default="string">
	<option>string</option>
	<option>variable</option>
	<option>transclusion</option>
</$select>
\end

<pre><<.docs-param-select>>
[range<<.docs-param end>>]
[range<<.docs-param begin>>,<<.docs-param end>>]
[range<<.docs-param begin>>,<<.docs-param end>>,<<.docs-param step>>]
</pre>

Sample output:
image

Obviously that <pre>...</pre> section is terrible to type or read; my main goal here was simply to show the sort of dynamic display I was envisioning. Ideally the code needed to turn

[range[<begin>]]
[range[<begin>],[<end>]]
[range[<begin>],[<end>],[<step>]]

(or similar) into a <pre> block with the appropriate macros could itself be contained in a hypothetical <$docs.filters> widget, but I haven’t done much work with custom widgets myself and am not very confident with the $slot mechanism, so I’ll leave that as an exercise for anyone who feels inspired. I took a crack at this in a later post in this thread.

Edit: I think @Springer’s concern about screen readers may apply here too… while the filters themselves would be plain-text (and could be easily copy-pasted, etc.) the selection mechanism might be less transparent…

3 Likes

I’ve been thinking along the same lines, but keep getting stuck on how to mark this up so that this would work. It also increases the burden on docs maintainers, and there’s already a dearth of that. But as I was also planning on making the opposite point in response to @Nemo, perhaps I’m still mostly confused.

I’m less concerned about ease-of-typing here than some others. Documentation is meant to be read much, much more than it’s written. It feels like a fairly minor thing.


I feel a little like, “Scott, meet Scott” here. Sorry.

Took me a while to research how to get them on a (non-french) mac:

\ (option + backslash) = «
add shift to above for »

It occurs to me that if all filter parameters were typed this way on tw-com, they could still by default DISPLAY as square brackets (!), but with some kind of css that helps us easily overlay info about how anything within that parameter expression (internally coded as «18» or whatever) responds to these 3 very important ways that parameters can be specified.

This is fantastic! I think this is the best pointer for the correct direction we’ve seen yet.

While I wouldn’t mind making a stab at a widget-based version, I can’t make any commitments; I haven’t done much with them either, and I don’t know what time I’ll have.

One nasty problem. We really would like to show each of the following:

[range{tid1},{tid2}]
[range{!!fld1},{!!fld2}]
[range{tid1!!fld1},{tid2!!fld2}]

but that would require an additional string for each parameter name.

Not to mention the possibilities of mix-and-match:

[range<start>,[100],{!!count}]

My head’s hurting!

1 Like

Hmm, why? That feels entirely backward to me. For me, the whole point is to not confuse users into thinking that our “replace-me” tokens are legitimate syntax, or, worse, that they are the only legitimate syntax.

I also want to stress again that there are two distinct uses of filters in the operator documentation. Here, I’m worried about the syntax descriptions. But there are also examples. For those, I feel like the solution is obvious, if tedious: just add enough of them to get a feeling of the variety of options that are available. But they need none of this special handling. People should be able to cut and paste them directly.

2 Likes

Technically it suffices to do the third, right?

The first and second just default to text field and currentTiddler. Granted the long form might be intimidating, since it’s rarely actually needed, and is visually noisy compared to {!!fieldvalue} or {tidreference}

Right, so I was thinking about the relevant CSS (that would swoop in when there’s a parameter, expressed as «18» (or whatever) behind the scenes… so that [18] is displayed, while ALSO adding GUI styling that cues the viewer to recognie that whole expression as a unit, AND adds a hover-tooltip with suggestions about indirect and variable expressions.

After someone sees that kind of thing and explores it a couple times, they might recognize the visual style of a parameter, and get used to thinking that square brackets around parameters are valid, but not like square brackets at the edge of a filter expression. They always open up into these more nuanced possibilities.

I don’t like the idea of actually using «» characters in a way that can be seen / copied though … because I think that whatever code we have should be copy-pasteable and should just … “work”. (And like you I’m worried about confusion… new users thinking they should be figuring out how to type « and » :grimacing: )

Is there a smart way to get tw-com to overlay a kind of “smart syntax” about where what’s being shown is a filter-operator parameter and somehow make a tooltip there?

1 Like

I was thinking about that too. I’d initially considered providing a select widget on a per-param basis, so you could change the display of a given param “in place”… but that would sacrifice the ability to copy an entire filter line, and I think it would be far less screen reader-friendly. I ultimately concluded that providing just one realistic sample per category would still be better than what we’ve got currently, and hopefully readers will understand that they can mix and match. (Though if we’re handling most of the display with procedures and/or widgets anyway, it wouldn’t be difficult to add a note pointing this out explicitly, or even a few links to other relevant tiddlers.)

As for the various types of transclusion, it wouldn’t be too much trouble to add a line item for each; we’d just have to decide which default tiddler title to use. I did consider adding an option for HelloThere!!field; I’d decided against it as I feared it might suggest that “HelloThere” actually had the specified field and would produce a meaningful result.

1 Like

Even apart from the whole test-case tiddler mechanism, surely a couple common-sense tiddlers, with recognizable names and field values, would be helpful at tw-com, right?

So, {{SolarSystem!!planet-count}} or {{JeremyRuston!!favorite-color}} or {{MotovunJack!!birthyear}} would then be directly available as field value references. :slight_smile:

1 Like

Absolutely. This is my top concern as well.

I think procedures are the simplest way to do this without adding any new syntax to the parser. For instance, I can quickly tweak the code I shared above to add some (ugly) highlighting to my example:

\procedure .docs-param(label)
	\function .param-type() [<.docs-param-config>get[text]] ~string
	\function .param-display()
		[<.param-type>match[variable]then[<XX>]]
		~[<.param-type>match[transclusion]then[{!!XX}]]
		~"[XX]"
		+[search-replace[XX],<label>]
	\end .param-display
@@<<.param-display>>@@
\end

image

Of course, I’d want something a little less eye-searing for the actual docs! But I do like the idea of using CSS classes to provide some additional visual cues; it emphasizes that the brackets are part of the parameter. And if we were using <span> instead of @@, it’d be easy to add tooltips and aria-labels, too.

1 Like

I said I wasn’t going to attempt a custom widget, but apparently I couldn’t help myself. Here’s a self-contained example (raw code follows at the end of the post): Sample $docs.filters.tid (2.0 KB) (Now revised as discussed in post #55, below)

It converts code like this…

<$docs.filters>
[range«end»]
[range«begin»,«end»]
[range«begin»,«end»,«step»]
</$docs.filters>

into output like this:

I have to confess that I had no idea how to type guillemets myself. (For my fellow Windows users, it’s Alt-174 for « and Alt-175 for »; the numbers must be typed on your numpad.) I’d really prefer a more standard character for use on TW-com, but I copy-pasted a few of them anyway to use as quick delimiters; they are, if nothing else, easy to read, and unlikely to appear in sample filters.

Other notes:

  • I used $wikify to capture the value of <$slot $name=ts-raw /> for use in filtering, but surely (hopefully?) this isn’t best practice…?
  • I used <<color primary>> to add some quick, palette-responsive color to the parameters. For a more polished version, we might prefer a more thoughtfully chosen palette. (Perhaps a different color for each type of parameter?)
  • I didn’t put a lot of effort into styling the $select widget, but IMO, it would look better either outside the bounds of the <pre> block or inline with the first line of code.
  • I added a quick tooltip to the $select to help clarify its use, but obviously, a <<lingo>> macro would be preferable. We could also include more explanatory text before or after the codeblock; here, I was trying to keep the display as clean as possible.

Full sample code:

\widget $docs.filters()
\function .docs-param-config() [[$:/temp/docs-config/]] [<storyTiddler>] +[join[]]

\procedure .docs-param(label)
	\function .param-type() [<.docs-param-config>get[text]] ~string
	\function .trim-label() [<.param-type>!match[string]] :then[<label>trim[]] ~[<label>]
	\function .param-display()
		[<.param-type>match[variable]then[<XX>]]
		~[<.param-type>match[transclusion]then[{!!XX}]]
		~"[XX]"
		+[search-replace[XX],<.trim-label>]
		:map[<.param-type>match[variable]then{!!title}search-replace:g[ ],[-]else{!!title}]
	\end .param-display
<span class="tc-param"><<.param-display>></span>
\end .docs-param

\procedure .docs-param-select()
<$select
	tiddler=<<.docs-param-config>>
	default="string"
	class="tc-float-right"
	tooltip="Select a type of parameter to see it used in the following filters.
You may mix and match parameter types within a single filter run."
>
	<option>string</option>
	<option>variable</option>
	<option>transclusion</option>
</$select>
\end .docs-param-select

\whitespace trim

<style>
.tc-param { color: <<color primary>>; }
</style>

<<.docs-param-select>>
<pre>
	<$wikify name=content text="<$slot $name=ts-raw />">
	<$list
		variable="output"
		filter="""[<content>search-replace:g[«],[<<.docs-param "]search-replace:g[»],[">>]]"""
	>
		<<output>>
	</$list>
	</$wikify>
</pre>
\end

<$docs.filters>
[range«end»]
[range«My Tiddler»]
[range«begin»,«end»]
[range«begin»,«end»,«step»]
</$docs.filters>
3 Likes

Wow wow wow!

The educational value of being able to select among the three kinds of parameter will certainly help folks grasp the flexibility of parameter syntax very quickly. AND whatever choice is active, the text is selectable, and is valid as-is without any new mystery characters.

People still have to understand that there can be a mix, and that the indirect reference doesn’t have to be a field of the current tiddler. But this is powerful stuff!

I’m tinkering with adding a hover-effect — maybe even a tooltip. But this is already inspiring!

1 Like

Quick note, in case this limitation wasn’t already noticed: this proof-of-concept doesn’t yet parse spaces within a parameter value, as for example happens in tw-com’s examples for documenting addprefix and addsuffix operators:

https://tiddlywiki.com/#addprefix%20Operator%20(Examples)

IMO there is no need to create new doc-macros. I did test UPPERCASE placeholders and it looks good.

Preview: TiddlyWiki v5.3.8 — a non-linear personal web notebook

1 Like

I did very little testing, so all corrections, enhancements, and other feedback are much appreciated!

Here’s an updated version that should correct the issue: Sample $docs.filters.tid (2.0 KB)
I’ll update the code in my previous post as well.

In addition to correcting to account for multi-word values (just a matter of adding quote marks around the parameter), I added a couple of additional lines to my .param-display function:

\function .trim-label() [<.param-type>!match[string]] :then[<label>trim[]] ~[<label>]
\function .param-display()
[<.param-type>match[variable]then[<XX>]]
~[<.param-type>match[transclusion]then[{!!XX}]]
~"[XX]"
+[search-replace[XX],<.trim-label>]
:map[<.param-type>match[variable]then{!!title}search-replace:g[ ],[-]else{!!title}]
\end .param-display
  • The final :map run replaces any spaces in the parameter with hyphens when displaying variable parameters. I didn’t make the same substitution for {!!field}-type parameters since field names can theoretically include spaces, but we certainly could do so there as well.
  • .trim-label removes any leading or trailing space from non-literal parameters — and here, I did trim fields as well. You could have a field name with a trailing space, but IMO it’s asking for trouble, and not something we want to promote.

As a side note, I’m not entirely happy with my use of search-replace to substitute the param name; I chose it primarily because it felt more efficient than using addprefix and addsuffix (which can also be problematic when used with brackets, particularly [ — which merely looks like a mistake — and ] — which actually disrupts the filter parsing). If anyone has a more elegant solution, I’d love to hear it.

I’ll also note that while I do see the appeal of adding this extra functionality to all the sample filters, I really designed it while thinking of the syntax illustration “filters” currently used for filter operators like range (https://tiddlywiki.com/#range%20Operator) and search-replace (https://tiddlywiki.com/#search-replace%20Operator). The addprefix tiddler doesn’t seem to have one at present (perhaps because it’s harder to abstract?), but if I were writing one, I might do something like

Cat Garden [[Favourite Armchair]] +[addprefix<prefix>]

or the following, in my proof-of-concept syntax:

<$docs.filters>
Cat Garden [«Favourite Armchair»] +[addprefix«prefix»]
</$docs.filters>

OK – That’s interesting and should be explored further. – But transclusions need to be more generic. We do use field transclusions for every filter. So those examples can be confusing too.

I think the uppercase placeholders are somewhat clearer than the current “syntax” filters, and certainly lower-impact than a dynamic display in terms of macros required. But we would need to add additional tables illustrating dynamic usage (as you’ve done here) for every operator tiddler, so I’m not sure I’d call it easier as quick solutions go.

The problem I see with “fake code blocks” that consist of <pre> only will probably be screen readers.

We need to make sure that accessibility is part of our improvements, if we need to touch a lot of tiddlers anyway.

1 Like

Absolutely. My demo was really just a proof-of-concept; I’d hope and expect that it would be significantly improved before it got anywhere near the live TW-com code. Unfortunately, I haven’t studied accessible web design, so I don’t feel qualified to make recommendations on that front.

1 Like

Note: I have as yet not tried the code examples above of @etardiff but I would like to see a blend of active tooltips/popup, copy to clipboard, « » and UPPERCASE.

Worth considering, but I don’t think it addresses the fact that such values can be replaced with [ ] { } and < >. As in Scotts reply @Scott_Sauyet

  • If copying syntax from the documentation you don’t need to enter « » you need to replace/delete them.

I contest this for the following reasons;

  • Just find out how to do so and you can enter them from the keyboard
  • We can provide an editor toolbar and other tools to use this and other select characters
  • This is only needed when writing documentation and could even be applied through a macro.

And

This is in part what establishing « » or other unused brace as a standard does. Handle the alternative braces.

The popup could include the ability to copy the different forms without the «» however as I said these need only be replaced, and decision to be made when writing code as to which braces are appropriate. To get a working but possibly inappropriate syntax is not that helpful.