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

Developers
, , ,
#20

Relating to Tags removal from shadows

Something that would help this would be perhaps a tab in the info drop down that indicated which fields if anything, on an overridden tiddler, differ from the shadow. Or in this case when only the tags are different compared to the shadow tiddler. noteThis is available in the editor preview excluding the fields

  • I or someone could make an option on the tag dropdown, such as in my reimagine tags solution, that could present an option when this is the case, “remove tag and reset to show tiddler”.
    • Similarly a filter pill version
  • Lets make a simple to use function that returns the tag name when and if this is the case.
    • It need only appear on the last nonstandard tag on the tiddler.
    • What about when the only difference is a tag was removed?

In many ways an easy way to get easy to determine differences between shadows and the modified non-shadow, that can be part of the view mode interactive UI would be very helpful

On the idea of no touch flags

I think to start I will create a demo, as mentioned earlier. For now I may restrain flags to being displayed in the subtitle with an optional colored flag, optional short name (caption or title), and a description on mouse over to start.

  • :triangular_flag_on_post: Triangular Flag on Post — U+1F6A9
  • :checkered_flag: Chequered Flag — U+1F3C1
  • :white_flag: White Flag — U+1F3F3
  • :black_flag: Black Flag — U+1F3F4

Although I would love to have a text field full of readable titles, one for each line, I will start by adding titles to the list field of the flag tiddler.

[Update] I have completed 80% of a demo, but I think I need to;

  • not use the list field in flag tiddlers, because if they are also tag tiddlers the list field will be compromised. As a result I plan to change all my code so far (very little needed) to use the flagged-list fieldname instead.
    • The same could be said for other flag fields like color or do we just use the single color field and deal with the compromise?
  • should I assist users by providing a two click method to make the current tiddler a flag as well? this could cause flags to proliferate.
#21

OK, I have made a demo of my idea. It is implemented through the submenu on tiddlers and allows any tiddler defined as a flag by tagging it as a flag.

The features will still need to be extended, but is a sufficent demo of the key concept.

https://flags.tiddlyhost.com

have we solved this oembed tags issue (above)?

Planned Improvements;

  • List all tiddlers with a given flag when clicking on a flag like a tag tiddler
  • Add the ability to add items to the flag dropdown
  • Generate operators for flags just as we have for tags.
#23

It will take me a while to wrap my head around this approach.

I was trying for a while to figure out where the todo flag “lives” or how to apply it … (but eventually realized those mini-tagpills are not related to the flag solution!).

Currently it seems there’s no easy affordance for removing a flag, besides editing the list (in the flag tiddler) and removing that tiddler from the list?

(+Minor note: there’s a letter missing from “ViewTempate” and “EditTempate” which want to be “ViewTemplate” and “EditTemplate”)

#24

glad I wasn’t the only one who found that a distraction.

@TW_Tones maybe this would be better demonstrated on top of an empty.html to ensure we’ve got a common baseline of behaviour to then consider what this changes.

#25

What is the Edit Buttons Plugin used for?

#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.