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

Developers
, , ,
#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
#46

I did have a closer look at the code. There are several internal functions, that do cache tags and field values, where the value of a field is maximum 128 characters.

But as far as I know, they are not universally used by our TW filters at the moment. So it would be needed to have a closer look here.

2 Likes
#47

Yes, that’s a useful example, but it may make the notion sound slightly more restrictive than it truly is because “Relationship” here is almost a pun. A few other cases: as I mentioned above, a LineItem on an order is a relationship between a product and an order, carrying additional details about quantities and prices. I have wikis related to local politics, including both Person tiddlers and Office (Board/Commission/Elected Position, etc. ones) and rather than either listing the other, I have Position and Candidacy tiddlers to say who’s serving in which role (Scott is a member of the Board of Education, Jayne is a candidate for Town Clerk, etc.) Similarly, Enrollment tiddlers might serve to bridge between Student tiddlers and Course tiddlers.

These may carry additional information. An Enrollment might also have “semester” and “section” fields. Flags are a simple version of this. Perhaps we have a TagRemoval flag, like

title: 12345
tag: TagRemoval
tiddler: $:/core/ui/ViewTemplate/subtitle
removed-tag: $:/tags/ViewTemplate

We could easily enough define operators which work like tag or tagging but take these relationship tiddlers into account. Retrofitting them into the core would be simple work, although there might be a lot of it.

This would require that we assume tag removal takes precedent over normal tag inclusion. And if we want to offer a tag reassignment, then we’d need to start adding some sort of level mechanism. (The core includes a Tag, a plugin removes it, and I want to re-add it in my own wiki.) This is a little ugly but doable.

My thought is that flags are really only a simple case of relationships, and this mechanism could be used similarly to how @Springer and @TW_Tones are suggesting. But it can offer much more. But I may be missing something. I haven’t followed either thread as closely as I would like.

2 Likes
#48

Me too, I think there is a gap here in the code patterns available.

It should be simple to make a json structure that can contain record information like create and modified, then say start of marrige, end of marrige and the two related tiddlers. Effectivly an index. In this case it would be the marriges tiddler, containing a list of all marages. Then like listed and backlinks provide an method for all person tiddlers to find if there is one or more mnarrage records they are in.

  • Like flags if such a solution is no touch then we have a very powerful solution.

Thanks @Brian_Radspinner I will look at this today.

What I hoped for was a way to define my drop down independant of where it is used. So a drop down accessed from the subtitle may behave as it would if in the view toolbar, or editor toolbar.

  • this may be possible with the info you gave me.

You are correct here, but to me I want to implement a mature flags solution so we can all make use of it, asap and then start to leverage this approach for further magic :nerd_face: after that. In part because the usage with help inform future designs.

  • I see here how people who understand my flag proposal are excited and want to innovate further.

It is importiant to note we as a community are great at open discussion but not so good at agreeing a uninified approach and implementing it, in collaboration. It is just something we need to learn.

#49

Back to flags.

As you may know all you need to create a tag, is to name it in a tag field. ie add it to a tiddler which updates a tag field.

  • At this point that title exists as a tag but need not have a tag tiddler
  • It becomes available in the edit tags drop down.

I understand tiddlywiki could do this for flags as well, however on first or subsequent use when adding a flag we need to create the flag tiddler, and typicaly then add the title to its flag-list, not touching the current tiddler.

  • Currently flag tiddlers are defined by the flag tag
  • The flag tiddler will be created on first reference to its flag-list field
    • all I need to do is add the current tiddler to the field tiddler titles field-list field and the first time it will be created
  • As a result I plan to remove the “flag tag” as a method of indicating flag tiddlers, the method to identify flag tiddlers will only be tiddlers that contain the flag-list field.
    • This also makes any tiddler able to be a flag itself and also be other things like a tag, simple tiddler etc…

I will be updating https://flags.tiddlyhost.com/ now

[Edited] Now updated to use above method, will be live soon after a little debugging (maybe tomorrow)

Of note however if we try and distill what this solution consists of is it is all about a list field on a tiddler. The remainder is the display add/remove of a given title on that list field, Not really much else. As a result I beleave we may be able to generalise this solution, so all we provide is a list fieldname, and all else follows from that.

  • Although it also makes sense in this case not to use a flag-list field but simply the field “flags” which makes the same sense as “tags”. The simply nominate flags as a field of the type flag (for want of a better term) to indicate no-touch.
  • Users could then make as many of these as they wish but with different names, just as they can now using an alternate tag field.
#50

I don’t think you want the plural “flags” — because this is not a list of multiple flags, but a list of things “flagged” by this one flag (unlike “tags” which is a plural list of tags). So flag-list or flagging would work better.

Otherwise I’m mostly following and looking forward to exploring your model once I have a bit more time.

1 Like