No touch tags - or flags on tiddlers without editing or changing the tiddler

Developers
, , ,
#26

@nemo, I agree that my proposal was pulling in too different a direction from what @TW_Tones meant to suggest (though we obviously overlap quite a bit in identifying the problems we’re tackling!).

So I’ve moved the bulk of my demo-linking and discussion to a separate thread, and I’ve tried to port over (to that thread) the reply-posts that were most directly engaged with my solution.

My solution is best described as “tag gets a disregard-list field to “mute” tag-children — suppressing them from the tag-end of the relation, without modifying the tag-children”.

#27

Thanks @Springer for your feed back, I finished later at night so left some gaps.

Sorry they were from reimagin tags. I removed them from the demos subtitle to assist

Once a flag is set on a tiddler mouse over that flag advises to remove use ctrl-Click

  • This is not cast in stone

I could say I missspelt there to test you, but I did not. I fixed this by simply renaming those two flag tiddlers.

  • This works without relink or any other games as flags names have no other special relationship.

Perhaps but I expect to return regularly to update it depending on your feedback. I have tidies it up a little. Feel free to provide specific improvements you would like to see.

Its just a common plugin I use when writting code and I can save changes but leave the tiddler in edit mode. It places extra buttons on the editor. Should be core options, at least in my view.

Great, I have some feedback which would have complicated things for me, in this discussion thread.

#28

Matters arrising

  • I used the class="tc-drop-down on the drop down but this is insufficent to replicate other dropdowns. I need to know more of the css to add padding and stop text being gray, is this documented anywhere?, if not it should be. Including for other core UI elements so tiddlywiki leads by example.
  • I would realy like to know how to do the oembed settings for tiddlyhost wikis to support rich links to such wikis. I am confident its doable.

What is importiant is I belive I have demoed the Proof of concept for the flag idea. In some ways it is trivial to implement and very effective. Of course I will improve the solution as it stands such as;

  • Listing tiddlers also with the same flag, when clicking on a specific flag
  • Adding icon, color and description options to flag tiddlers
  • Making the current tiddler a flag
  • move list to flag-list

However, unless I get seriouse objections I will Proceed (part time) to develop this solution further so it could blend into tiddlywiki seemlessly including;

  • No need to use the flag tag (eg add a flag-list field to make a flag tiddler)
  • A full suite of flag “filter operators”
  • Additional optional UI elements for handling flags similar to the tag editor and display
  • Enhance the flag dropdowns to work like the tag pill dropdown, including provisioning the adition of items (by tag) to that dropdown list, for hackability like reimagin tags makes use of.

[Edited] it is importiant to note that this mechanisium is;

  • friendly to missing tiddlers, such that you can “flag” a title that does not exist
    • I plan to add an example of this to the Demo - system tags
  • Is not leveraging the backlinks mechanisium but something similar could

[/edited]

Please provide further feedback and if you are interested, perhaps try out collaborating with me to build this.

#29

You should create an issue at Github about this one, so it will not be forgotten

1 Like
#30

Sure, but I try to have an answer before I raise an issue. I need an answer for my current wiki.

#31

Quoting from Tag ($:/tags/ViewTemplate) allowed to "disregard" some tag-children - #21 by TW_Tones but to here because this topic seems more suited

This is where I’m confused. If it’s as feature-rich but a different code set, then isn’t it parallel work? What benefit does it serve? Wouldn’t every plugin that enriches tags not enrich flags, so to keep the same richness there would forever be parallel work?

otoh, if it’s just a different mechanism to tag something, then I think a separate name is confusing.

Based on discussions so far and this topic title, the first of these I’d call “flags” and the second I’d call “no touch tags” - only to clarify during discussions to distinguish from the current tagging method, though maybe “tag assignments” or something would be even better)

#32

For a moment understand I use “flag” to differentiate it from the current tag system. It however has the advantage of differing by one letter. Especially If I build filter operators.

It seems you don’t sufficiently grasp the enormous difference between a tag which one or more exist on each and every tiddler with that tag, and specifically when added to a shadow tiddler edits each and every tiddler. Making it a tiddler.

  • In the case of core tiddlers this also overrides the default for everything else in the tiddler and effectivly demands twice the bytes.
  • It becomes difficult to determine if the tiddler has changed only its tags. or something less trivial, eg code changes.
  • Currently to transfer “tag tiddlers” between wikis it trivial, unless you want to transfer which titles it tags, but not transfer the actual tiddlers. So it is no longer trivial.

Flags on the other hand can be used to mark any tiddler, yes functionally like a tag, however the information about which tiddlers have a flag is retained within the flag tiddlers themself, not on the items which are flagged. We can only see that a flag exists on a tiddler by adding something to the view template, because unlike tags they are not contained within a field on each tiddler.

  • The disadvantages of tags are avoided with flags, the tiddler need not be edited, especially good when marking tiddlers in the plugin or core as only shadow tiddlers.
  • The flag tiddler can be dragged and dropped to another wiki, which if it handles flags, will immediately flag all relevant tiddlers if opened in the story missing or otherwise.
    • You can not tag a missing tiddler.
    • You can flag a missing tiddler. Have a look at the system tags
       tiddler to see this in action. It has practical uses.

So I would be reluctant to call them no-touch tags. They are fundamentally different even though they can be used in similar ways to categorise tiddlers, just as you may use fields on tiddlers, such as “keywords”, to do the same thing. For this reason I would also differentiate them using flag icons/symbols.

Have you seen my filter pills solution?. This too looks somewhat like tags but is driven by filters and again is substantially different as it is effectively dynamic.

  • I could have used the filter in the flags solution, on a filter pill, but I need the flag list and add/remove tools on tiddlers as well.

A conceptually different method needs to be differentiated from similar ones lest its difference be overlooked.

#33

Post script.

Implied but not stated is unlike tags which are used to drive much of the core and UI flags serve a different function and may be less likely to suffer from “pollution”, when the are too many flags to be practical, as sometimes occurs with tags. This is a good reason for them to exist in the subtitle and not as if they were tags and using a “like” tag pill.

[Edited]

I was going to use the backlinks operator here, however I ended using the listed operator, as a result we can look in the info tabs to see the “listed” items. Such that we can say that flats are effectively “titles listed”

#34

…

Everything you describe there (overriding core tids or creating shadow, lack of clarity on what has changed, transferring a tag set between wikis) I understand.

That’s the bit I disagree. Yes there is a difference in the mechanism behind the scenes in how a tid ends up tagged, but apart from the “I choose to be tagged” vs “I was tagged regardless” difference, I seems what you are describing is otherwise fundamentally the same.

I had not. I’ve found what I assume is it at https://bookmarklets.tiddlyhost.com/, but it’s not clear what it does or how it works.

#35

That’s a good point. The overlap of tags that drive the UI, and tags that users allocate to organise their content structure - that feels like it could be worth exploring.

(I have a vague recollection that classic TW had a system whereby tags could be hidden from normal display, thus avoiding visual pollution. I haven’t noticed the same in TW5, though I’ve not looked either, and feels like it could cause different confusion too - the clarity of tags is useful!)

#36

Well it is fine to “agree to disagree”.

One reason I do is I have implemented other ways than tags to organise information/tiddlers such as keywords, categories and subjects in part to influence or curate the values that such alternative organisation systems demand. Tags are a kind of all inclusive, ad hoc and permissive solution. Great for out of the box functionality however they start to fail when over used such that we even developed a term in this community (a fairly rare thing) which is “Tag pollution”. When there is an overuse of tags, they become overwhelming.

Perhaps only in the case of a read only wiki where naive visitors arrive.

I did personally once modify the existing tag handling to allow a display-filter on tag tiddlers, which the tag view template would use to determine if it should be displayed. I would still like to see that. However I still left them visible in the tag editor.

Again touching on Tag ($:/tags/ViewTemplate) allowed to "disregard" some tag-children

I wonder if this and another field on the tag tiddlers would go a long way with @Springer’s issue such as a list-filter on tags that is applied as a subfilter whenever listing a tag. That filter can contain both includes and excludes as desired and would be far simpler than a multi-field solution.

  • The local tiddler could override the tags list-filter by having a variable set, its own field, and if neither exists look for a global list-filter variable. The default being no list-filter/<<list-filter>>
Tag ($:/tags/ViewTemplate) allowed to "disregard" some tag-children
#37

I use TW almost exclusively on my phone, and I suspect I’m far from alone. Mouse-overs and modifier+click are Not available In that environment. I love the idea you’re exploring, but think some consideration of mobile users in the UI should be made.

2 Likes
#38

Your goal is a great one - minimizing the impact of tag/flag-only modifications to shadow tiddlers. However, by storing the flag assignments in the flag tiddler itself, you’ve “thrown the baby out with the bathwater”.

I think a better place to store flag assignments would be a third tiddler, following a naming convention based on the name of the flag (or flag tiddler). That way changing flag assignments would override neither the shadow tiddlers whose assignment is being added/removed, nor the flag tiddler itself (which may contain other behavior related to that flag). In effect, this “flag assignments tiddler” becomes a sacrificial shadow tiddler, the override of which preserves the ability to upgrade both the flag tiddler (with its plugin) and the shadow tiddlers (in core or other plugins) to which the flag has been assigned.

Further Thoughts

  • I think this would solve the “how to remove default tags” problem - default tag assignments would be in the plugin’s (or the core’s) flag assignments shadow tiddler. You could even design a UI for it that would detect when it’s been overridden, and show differences with the original shadow version, with buttons to selectively restore those differences
  • I also think this idea could be implemented with just wikitext. I do know JavaScript, but I’ve never really needed it with TiddlyWiki. (And I really don’t know how to get started with using it with TW in the first place. I haven’t yet found a great set of documentation on how to get started with that. The best intro I’ve seen is the source for TW5-Checklist, but that’s just for one of what I’m certain are many use cases.) From what I’ve read of the TW core code, core support of the flags concept would be helpful, even if just for performance reasons (creating and maintaining a cache of flag assignments, for example).
1 Like
#39

Hi @TW_Tones

I like the idea of “no touch tags”, but there’s something missing in your proposition: if a plugin provides a flag tiddler, and the user wants to “flag” or “un-flag” a user-created tiddler, they will have to modify a plugin-provided flag tiddler anyway, just like any other current plugin-provided tag, thus creating a shadow tiddler.
This use-case can be 100% “no touch” if flags are not stored in single “flag-tiddlers”, but if you store only the relationships in one or more tiddlers.
Example:
A plugin developer wants to use a “Product” flag. Then their plugin can provide a tiddler named “default-product” like this

title: $:/my/plugin/default-product
flagged-list: [[$:/my/plugin/tiddler 1]] [[$:/my/plugin/tiddler 2]]
flag-name: Product

If the user wants to flag a third tiddler, no need to modify “$:/my/plugin/default-product” tiddler, they can create a new tiddler:

title: my-product
flagged-list: [[My own tiddler]]
flag-name: Product

Also, to “un-flag” a tiddler, without touching any system tiddler, an “unflagged-list” field could be useful (but your proposition of a filter would also work for both “flagged” and “un-flagged” features).

Fred

2 Likes
#40

I think this makes for much more flexibility. But rather than a naming convention, I prefer:

but I would go a little further, and skip the lists, adding a single relationship tiddler for each combination.

title: Relationship/12345
tag: FlagMembership
tiddler: My own tiddler
flag-name: Product

We could use a naming convention here, removing the tag and using a title such as FlagMembership/12345 instead. This means that My own tiddler doesn’t need to know about the flag Product, and Product doesn’t need to know about My own tiddler, but they can still have an important relationship, and we can, for instance, apply a Product ViewTemplate to tiddlers such as My own tiddler:

title: ProductViewTemplate
tags: $:/tags/ViewTemplate
list-after: $:/core/ui/ViewTemplate/body

<% if [all[tiddlers]tag[FlagMembership]tiddler<currentTiddler>flag[Product]] %>

----------

Product Information here, with `currentTiddler` set to "<<currentTiddler>>"
<% endif %>

While @tw-FRed’s list fields allow some consolidation, I prefer the simplicity of one relationship, one tiddler.

And individual relationship types can hold more information than just the name of the flag and the name of the tiddler. For instance, we might think of a LineItem tiddler as a relationship tiddler between a Product and and Order. But as well as product-id and order-id, it might have additional fields such as unit-price and quantity. Flags would just be a simple case of this mechanism.

#41

Your idea for “one relationship, one tiddler” adds some new capabilities, like easily filtering and exporting all the flag assignments for either a given flag OR for a given tiddler.

But those new capabilities come at the expense of being able to remove a flag assignment from a tiddler that it had in it’s original component, including the TW core, something that others in this thread considered valuable. (I personally don’t have a use for that, and would vote for your idea over mine.)

Your thought that relationship tiddlers could hold more than just the names of the flag and the assigned tiddler could resolve this “conflict”: one of the additional properties supported could be a “assign/unassign” indicator that could be “flipped” to unassign a flag originally assigned.

I also like the thought that flag assignments are just the start of what such a mechanism could do - it could open the door to graph data structures and subsequent filter support. Think kin-filter, but with the ability to limit relationship types. Another source of inspiration would be Neo4j and its Cypher query language. And given that “flag properties” would just be fields on tiddlers, there’s no reason that new ones couldn’t be added on-the-fly with later plugins or user code.

I feel like we’re falling into quite the rabbit hole here… :slight_smile:

#42

Thanks all for your views and extending the ideas of my vision. Love it. However lets try and mature the first idea, we can then build more new and innovative solutions.

Good Point, I must keep in in mind, Although for now its just a proof of concept.

Another good idea to consider, my only concern is it gets further away from a simple approach.

  • So we may use $:/flags/flagname ?
  • Arguably we could have one tiddler storing the flag-lists for all flags in fields. But then we can just export the list without individual tools or all together.

It would not be a shadow tiddler unless some flags comes in the core or a plugin but this seems to be where you are going, and using it instead of tags. I think there is value to this approach but the idea would need to have considerable support. Its easier to propose additional features and mechanisms than changing existing ones.

I / we can help you with this but like you I favor wiki text solutions. If I implement the flag operators as I propose they would be javascrip based. But if you want to learn more start a thread separately.

True, if I build flag operators it would be nice for the core to support caching flags as it does tags.

Good observation but not as importiant.

The point here it is the “plugins shadow tiddler”, what we are trying to do is makesure flags not need to overwrite others shadows especialy the core. When you delete the plugin the flags disapear, and the overiddent tiddler may also need deleting. A lot opf plugins go out with config tiddlers and others the use quickly modifies.

I see what you are saying, I need to think about this in light of @jpjerkins idea above.

I need to thnk about this is it is adding too much complexitry. But I will think about it.

I agree, but this solution demonstrates in this case using titles listed in another tiddler, to indicate something on the current tiddler. This is in part why I raised this. I did want to show how you can do this to add support for other no touch mechanisiums. I was originaly going to store titles in the text field and use backlinks[].

I have history on this rabbit hole, I cant detail here. The idea is a database where all attributes of all objects (read title) are defined by there relationship to other objects and nothing else.

#43

Yes, or just add a “remove”/“unassign”/“exclude” field when necessary, with the understanding that exclusion always outweighs inclusion. That would require that the core never uses exclusions, but I think that’s ok.

1 Like
#44

I am often a fan of relationship tiddlers!

In this case, let me pry a bit, though:

A genealogy wiki sets up a good rationale for relationship tiddlers: it’s ideal to avoid putting “sister of” or “cousin of” (etc.) at one end or the other of the relationship. This is largely because:

  • not all relations are clearly hierarchical, so it’s especially hard to develop a clear rule-of-thumb for which tiddler is naturally “home” to the relation.
  • we may want to include additional info about the relationship. So “spouse of” — rather than being a field — becomes a “marriage” tiddler that can have a date of marriage, other facts about the marriage, image of marriage certificate, date of dissolution (if needed), etc.

By contrast, TiddlyWiki (off-the-shelf) envisions tags as themselves simply dyadic relations: A has X, B has X, C has X. All stored in A, B, and C tiddlers.

Recently, both @TW_Tones and I have been pressing for “X has A,B,C” (“flags”/“favorites” model), and/or “A claims X but X disclaims A” models. Dyadic but potentially handled from either pole. (And since tag-pole, or flag-pole :upside_down_face: tends to be a non-shadow user-controlled tiddler, it’s ideal to put any further notes or discussion there.)

I think relation-tiddlers are warranted only if we think the relationship might itself be the site of significant further detail. So, if you like to keep notes about why this tiddler has the view template tag, this would be the place. …

But here’s the bit of a gotcha (assuming we’re not designing from scratch but building something backward-compatible): With shadow tiddlers especially, my use-case is often to UNPLUG a relation that the shadow is claiming. I don’t see that a relationship tiddler could easily do that. Or rather, I suppose we could make a tiddler dedicated to stripping the $:/tags/ViewTemplate tag-effect from subtitle template (potentially adding a note-to-self reason for doing so). But would that be the same tiddler that could — with the same fields? — toggle the tag back into effect (not just by deleting that relation tiddler)? I think this would require quite a bit of thinking-through. And what happens if there is both a “this_HAS_that” relationship tiddler and a “this_NOT-HAS_that” relationship tiddler? (I don’t see this as a problem for a marriage-relation tiddler, because time is the factor. But in TW-system-function-land, we’re not tracking a narrative, but distilling into a flatter logical landscape.)

Last thought: Then-again, perhaps the idea of a relationship tiddler CAN do it all, if it can house a condition filter… The relation tiddler is between the template and the tag-like function (say) AND the relation is neither a “yes” nor a “no” (though it might be “yes” if it’s otherwise empty?) but the text field contents can articulate something to the effect of: “This template is to be engaged (as if $:/tags/ViewTemplate) exactly when there’s only one tiddler in the story river AND sidebar is off… (but to be suppressed otherwise)” … and variations on this could be as convoluted as a person could imagine AND — vitally — one could keep breadcrumbs, troubleshooting notes, such as “because this template became redundant when I added XYZ plugin” or whatever.

I worry we’re distracting a bit from the flags model that @TW_Tones is proposing here. But discussing how these relations work is certainly the bigger-picture deliberation we all need to be having…

1 Like
#45

This is because your drop-down menu is in the subtitle section of the ViewTemplate, so it’s inheriting the .tc-subtitle color. You should be able to add your own styles for .tc-subtitle .tc-drop-down to give it a different color for plain text.

The .tc-dropdown-item class also specifies a grey color, so that needs an override too if you use that class.

Here are the most common combinations of HTML elements that compose the drop-down menus. Keeping these sets of CSS class names should keep things consistent.

<!-- Simple drop-down of buttons -->
<span class="tc-popup">
    <div class="tc-drop-down">
        <button class="tc-btn-invisible">button text</button>
        <button class="tc-btn-invisible">button text</button>
        <button class="tc-btn-invisible">button text</button>
    </div>
</span>


<!-- Simple drop-down of links, missing styles kept -->
<span class="tc-popup">
    <div class="tc-drop-down">
        <a class="tc-tiddlylink tc-tiddlylink-missing">text link</a>
        <a class="tc-tiddlylink tc-tiddlylink-resolved">text link</a>
        <a class="tc-tiddlylink tc-tiddlylink-resolved">text link</a>
    </div>
</span>


<!-- Drop-down of links, missing styles kept, possible section labels -->
<div class="tc-block-dropdown">
        <span class="tc-dropdown-item">section label</span>
        <a class="tc-tiddlylink tc-tiddlylink-missing">text link</a>
        <a class="tc-tiddlylink tc-tiddlylink-resolved">text link</a>
        <a class="tc-tiddlylink tc-tiddlylink-resolved">text link</a>
        <span class="tc-dropdown-item">section label</span>
        <a class="tc-tiddlylink tc-tiddlylink-missing">text link</a>
</div>


<!-- Drop-down of links, missing styles ignored, possible section labels -->
<div class="tc-block-dropdown tc-edit-type-dropdown">
        <span class="tc-dropdown-item">section label</span>
        <a class="tc-tiddlylink tc-tiddlylink-missing">text link</a>
        <a class="tc-tiddlylink tc-tiddlylink-resolved">text link</a>
        <a class="tc-tiddlylink tc-tiddlylink-resolved">text link</a>
        <span class="tc-dropdown-item">section label</span>
        <a class="tc-tiddlylink tc-tiddlylink-missing">text link</a>
</div>
2 Likes