Although I find syntax highlighting very unhelpful, I do find judicious use of emojis (and unicode characters) useful in macro identifiers.
When it helps make certain things quick and easy to locate/identify.
Although I find syntax highlighting very unhelpful, I do find judicious use of emojis (and unicode characters) useful in macro identifiers.
When it helps make certain things quick and easy to locate/identify.
+1!
I also like to use emojis to visually structure my wikitext through HTML comments. For example:
\procedure table()
<!-- 🧮Logic -->
\function get.estimate() [subfilter<tasks>get[time-estimate]sum[]add<add-hours>]
\function get.spent() [subfilter<tasks>get[time-spent]sum[]]
\function time.estimate.field() [[time-estimate-$(Experience)$]substitute[]]
\function get.time.estimate.field() [{!!title}get<time.estimate.field>]
<!-- 🧱Markup -->
\procedure task() <$checkbox tag="done"> <$link/></$checkbox>
\procedure edit-table()
<$checkbox field="edit-table-data" checked="true" unchecked="false"> Estimate</$checkbox>
\end edit-table
\procedure table-template()
<<style>>
<table>
<caption>Estimated (depend on [[your experience|Profile]]): <$text text={{{ [get.estimate[]] }}} />h, Spent: <$text text={{{ [get.spent[]] }}} />h</caption>
<thead><$slot $name="thead-inner"/></thead>
<tbody><$slot $name="tbody-inner"/></tbody>
</table>
\end table-template
\procedure table-edited()
<$transclude $variable="table-template">
<$fill $name="thead-inner">
<tr>
<th rowspan=2 >Task/Skill</th>
<th colspan=<<ExperiencesCount>> ><<edit-table>></th>
</tr>
<tr>
<$list filter=<<Experiences>> variable="Experience">
<th><<Experience>></th>
</$list>
</tr>
</$fill>
<$fill $name="tbody-inner">
<$list filter=<<tasks>>>
<tr>
<td><$link/></td>
<$list filter=<<Experiences>> variable="Experience">
<td>
<$edit field=<<time.estimate.field>> type="number" placeholder=<<Experience>>/>
</td>
</$list>
</tr>
</$list>
</$fill>
</$transclude>
\end table-edited
\procedure table-displayed()
<$transclude $variable="table-template">
<$fill $name="thead-inner">
<tr>
<th>Task/Skill</th>
<th><<edit-table>></th>
<th>Time Spent</th>
</tr>
</$fill>
<$fill $name="tbody-inner">
<$list filter=<<tasks>>>
<tr>
<td><<task>></td>
<td>
<$select field="time-estimate">
<$list filter=<<Experiences>> variable="Experience">
<option value=<<get.time.estimate.field>> ><<Experience>>: <<get.time.estimate.field>>h</option>
</$list>
</$select>
</td>
<td><$edit field="time-spent" type="number" placeholder="Time Spent"/></td>
</tr>
</$list>
</$fill>
</$transclude>
\end table-displayed
<!-- 🎨Styling -->
\procedure style()
<style>
table {
width: 100%;
caption{
caption-side: top;
}
select {
width: 100%;
}
[type="text"],
[type="number"] {
width: 100%;
field-sizing: content;
}
button {
width: 100%;
&[disabled] {
border: highlight solid 1px;
background: unset;
}
}
}
</style>
\end style
<!-- 📃body -->
<$let
tasks="[list[]]:sort[tag[done]]"
edit-table-data={{!!edit-table-data}}
Experiences="Novice Beginner Intermediate Advanced"
ExperiencesCount={{{ [enlist<Experiences>count[]] }}}
add-hours={{{
[{Profile!!practical-experience}compare:number:gt[12]then[0]]
[{Profile!!practical-experience}compare:number:gteq[6]compare:number:lteq[12]then[10]]
[{Profile!!practical-experience}compare:number:gt[0]compare:number:lt[6]then[30]]
:else[[50]]
}}}
>
<%if [<edit-table-data>match[true]] %><<table-edited>><%else%><<table-displayed>><%endif%>
</$let>
\end table
<<table>>
[[Strategy for Study]]
I’m considering whether adopting a systematic emoji-based naming convention for pragmas and sections might help readability. For instance:
Pragma: \define : (definition)
Pragma: \function : (perform work)
Pragma: \import : (for variables to be imported)
Pragma: \parameters : (variable data)
Pragma: \procedure : (steps or instructions)
Pragma: \widget : (modular component)
Sub Sections:
Additionally, using for comments that explain code logic might be useful:
\function .ℹ️() [all[]]
<$list filter="
[[HelloThere]] [.ℹ️[This is a comment]]
" />
Original idea taken here: How to add "comments" to filter expressions - #7 by Yaisog
I’m not entirely sure if this approach is practical or accessible, but it seems to me like it could improve the user experience for those comfortable with emoji cues. Given your interest in UX (like your thoughtful approach to the save button icon), I’d be very curious to hear your opinion. If this is off-topic, let me know and I’ll start a new thread.
I think that is all very good stuff !
Pretty sure the great majority of folk would benefit from your approach.
Me, I figure because of my cognitive disability (ies?), I have a really hard time with associating semantic meaning to symbols. (Thirty years of using elevators, I still can’t make heads or tails of “open” and “close” buttons on elevators that use arrow symbols like “><” and “<>”.)
Symbols (with eye-catching colour) are, for me, just ways to find occurrences of a particular thing, to keep me from playing an annoying game of “Where’s Waldo.”.
I also have a hard time with comments appended to the end of a line of code. As I read top-down and left-to-right, I like to read a comment before I read the code. I get immediately irritated when I read something and after-the-fact run into something that tells me what I just read.
All of that said, you should pay no mind to any of that unless you must accommodate a doppelganger of my funky brain. If you do, then let the games begin !
This is very interesting and has a Bret Victor vibe.
I welcome visual attention anchors like indentation, syntax highlight and icons in my GUI apps.
At the same time I can’t stand emojis in my TUI/CLI apps, to the point that I’m cursing and raging when they are hardcoded and there’s no setting to turn them off
Right, semantic meaning for symbols are not necessarly universal, that’s why maybe it’s best to not overuse them in wikitext, especially if the aim is to make a few elements stands out
I often am unsure where to place my comments, what you say make a lot of sense! It’s also how jsdoc and phpdoc operate, first the comment, then the code - but I admit I never took the time to wonder why.
For me accessibility is very important, because I want my stuff to be usefull to as many people as possible. It’s always interesting to see the experience of others and improve the way we do things as a result!
If it helps I view this as the doors moving inward ><
, or outward <>
and ignore the open or close concepts. I think it can be hard sometimes to find a metaphor but when you do its is simple. But you do you, i will do me