Can tagpill drag-and-drop work with the tag children’s list-before / list-after fields?

#1

This may not be the best place to make this comment but:

I wish there were a way — FROM the tagpill — to work with the list-before and list-after fields of the tag children.

So, for example, dragging something to the very top (or bottom) would add a blank list-before (or list-after) field to the dragged tiddler. Dragging on top of another item but pulling to left would add a list-before to the dragged tiddler (or pulling to right adds list-after) … with contents according to whatever tag-child was at that position.

Rarely do I want a blunt and hard-coded list field in my tag!

Almost always there’s a logic to the ordering, and especially for something like a view template or cascade condition, I want that logic to follow the template when I drag it to another wiki.

And it always makes me cringe when I casually indulge in the convenient the tag-reordering GUI and then realize I’ve now zapped all my previous list-before and list-after work invested into the items so tagged. :grimacing:

Any other folks avoiding the tag-pill reorder for this reason?

1 Like
Reorder List (without having to drag and drop)
#2

Oh, yes! But even when I avoid it, unless I’m careful, there can still be problems when I drag to another wiki. I with list-before and list-after took a list of values: I want this template before each of these, or after each of those, where somewhere in that list is something like $:/core/ui/ViewTemplate/body or $:/config/ViewTemplateBodyFilters/default.

I want to say, Template C comes after Template B, which comes after Template A, which itself comes after $:/core/ui/ViewTemplate/body, but still be able to drag Template C to a new wiki without dragging the others. If I had a list for list-after, and it contains $:/core/ui/ViewTemplate/body, it will appear in the right place even though A and B weren’t themselves ported.

#3

Certainly, there can be such complications! If the list-before and list-after were parsed as a list field (a cascade within the cascade, as it were) it would be more powerful, but surely at the cost of considerable processing overhead, yes?

In the majority of my cases, though, a cascade condition would just fail whenever it’s after the default (which is — alas! — where it ends up if I drag it and it carries no list-before field), and it often succeeds (more or less, even if there are visual glitches) if it’s before the default.

And for a typical cascade-condition tiddler, if I give it a blank list-before, that’s because it already effectively has a “pass-through” condition of some kind (or the special template includes a benign transclusion) that makes it unlikely to interfere with other blank list-before tiddlers under the same tag.

So I try to maintain a personal “best-practices” policy of considering whether I can work with a blank list-before … and if not, I aim to limit the contents of any list-before or list-after field to standard items that are either off-the-shelf core tiddlers, or analogously central shadows for a plugin (such as refnotes) that my template/cascade condition already interacts with.

Of course, dragging system-sensitive tiddlers between wikis will always have some risk of leaving important relations behind. But the closer I get to clean list-before and list-after practices, the more often it happens that I drag something from project 1 to project 2 and… :nerd_face: It just works.

#4

I love that idea. And I think we could have a reasonable UI affordance: instead of an empty drop-box between rows, when we hover, we add small boxes in margins to the left and right of the target. As we move to the left third (say) of the row, we highlight the before box and on the right third we highlight the after box. We could even stagger the heights, so that before is higher than the target tag, which itself is slightly higher than after. There might even be some sort of locking mechanism so that we don’t move shadow templates by accident, only moving our own amidst them unless we explicitly unlock them.

1 Like
#5

There would be some overhead, but I don’t think it would be substantial. Although this would be a list, I think of it as an unordered set: This template appears before all of these ones. If they aren’t there, no harm, no foul.

Yes, the same for me. I worry much more about templates than cascades, since usually in the cascades, for me, they simply have to appear before the default one, and that’s all I need to worry about. Obviously there could be exceptions, but I haven’t seen them all that often.

1 Like
#6

One more desideratum — and this should be “easy” (famous last words?):

In the tagpill drop-down, make it visually salient WHICH tiddlers are where they are because of the tag-tiddler’s list field, WHICH child-tiddlers are at top or bottom because of their own blank list-before or list-after fields, and WHICH tiddlers have gotten where they are by successfully employing a list-before or list-after value to hook into another tiddler’s place in the order. (Maybe unsuccessful hooks should also be recognizably flagged — these would be useful for troubleshooting).

None of this needs to be loud or distracting — maybe simple horizontal offsets to left and right would play a role for blank list-before and list-after… plus some kind of subtle hook-like pointer to prior/next value in the case of successful list-before or list-after values. And some visual separator between any explicitly ordered values (in tag-parent tiddler or from tag-child end) and those tag-children that are just dangling-at-bottom via default alpha order.

If I saw that kind of visual clarity when I dropped into a tagpill, it would help me decide whether to do an old-fashioned drag-to-reorder (thereby zapping all that per-tiddler complexity and potentially creating a rather overwhelming list field), or whether to step back and consider the more specific list-before or list-after method.

(I’m suddenly experiencing some deja-vu… I think some of this may have been explored in a prior thread? Not the novel drag solution part, but the visual clarity part…)

2 Likes
#7

OK, proof-of-concept here: QUICK DEMO* — showcasing…

The tag drop-down shows:

:arrow_up_small: next to tag-children that are at top because of their own blank list-before field
:arrow_left: next to tag-children that have a value in their own list-before field (not yet checking whether that value is doing work, though)
• next to tag-children listed in (tag-parent’s) list field.
:arrow_right: next to tag-children that have a value in their own list-before field
:arrow_down_small: next to tag-children that are at bottom because of their own blank list-after field

#8

If this discussion helps you conceive another way to do this if we were starting again with tiddlywiki, please let me know.

I am slowly evolving a tiddler cards solution as an alternative to relying on viewTemplate tags, when a tiddler can have more than one card, per tiddler role. Already each listed item “a card” has a display-filter within its own definition that determines if it is to be displayed, and each card may have its own tag for its elements. It seems to me a more powerful ordering mechanism may be useful.

  • So please let me know if you think you have come up with a new algorithium.
#9

It’s intriguing and a bit disorienting to imagine how things might be if we were starting from scratch! I admire that kind of vision.

AS it is, I find that the ordering of tag-children is quite nuanced for a whole host of reasons, and those ordering details have more important roles over time… View templates are just one place where that order matters. For cascade conditions tag-order matters a great deal (not just for view templates, but anything that cascades, including stylesheet tiddlers but also maybe field-editor GUI and related attributes, as we’ve been discussing…).

Dragging-and-dropping to reorder things with $:/tags/Stylesheet tag can create a list field that is dizzying and impossible to make visual sense of, for example…

So my sense is that even if there’s an innovative and different way of thinking about view templates, we’ll still have the question whether we can empower people to use “smart” approaches to tag-ordering, permitting more nuanced and modular control.

In making my proof-of-concept, I realized that another reason (beyond inter-wiki migration) to let list-before and list-after function as list fields (or filters even??) is that the same tiddler may carry multiple tags, such that… this tiddler might want to be at the TOP of one cascade, but ordered much further down for a tutorial about how a certain plugin works (or something like that).

#10

It seems to me when a list needs to be more structured, using tags is problematic, as the tag pill does permit drag and drop reordering, Perhaps a flag to inhibit the drag and drop reordering on tags may help. But it seems to me tiddlywiki is a master of list management and includes features like sortby, so we have a broad pallet from which to draw.

  • Setting a drag and drop inhibit on the tag tiddlers may follow a similar pattern to the delist idea
  • Using my filter pill solution may be another, on an alt-tag field.

Perhaps in cases like this, and my own cards solution using an alt-tag field or flag list to manage the iteration of a list makes more sense, so I am not forced to live with the inherited behaviour of tags and tag pills.

#11

When doing some behind the scenes research (for delisting) I realised a pattern we have not used yet, is adding fieldnames that are also tag names eg: the field named “$:/tags/ViewTemplate” is certainly a way to provide a value to the itteration of the tag $:/tags/ViewTemplate. An example may be a filter -[[tiddlername]] to delist tiddlername, or one or more of the order operators such as;

So replacing the list-before and list-after with fields named with the tagname containing order filters.

#12

Well… the thing is, the tag-based ordering is the way in which cascades are integrated into the core. So, barring a reworking of the guts of the cascade, I think I’m interested in adding a layer of “smart-order” interface aids for how tag-children are ordered…

#13

Yes, understood, but in part why I am building another way to deliver content to tiddlers via an independent card solution.

Although back to your target, the tag driven core cascades, the tags field is just a list field. And one can attack it as a list field independent of its use as a tag.

#14

So, circling back to the impetus for this thead’s speculation: the tags field is a list field (albeit one that anomalously shakes off attempts at custom ordering!)… and the tag tiddler HAS a list field…

But the list-before and list-after fields on a tag’s tag-children are often doing “smarter” work (and more portable across wikis) than the list-field that lives in the tag-parent tiddler.

So, my line of thought in this thread is to help people see when they want to avoid messing with the list-field in the tag-parent, if/when what we really want to do (especially for custom cascade conditions and such) is make sure that the priority-juxtapositions travel with the custom content, not the tag-parent.

#15

Understood,

Perhaps when the tags are ordered as desired, capturing that order in another field (not list) on the tags tiddler, or somewhere else?. Then using that to sortby the tags on the destination. In both cases saving, and resorting could be facilitated by tag pill dropdown items. Although it will still need an intervention.

  • Using sortby the saved ordered list, is once removed from an exact list of tags, so additional tagged items, can be incorporated.
#16

That looks like a very useful start.

I would love to reimagine our drag-and-drop to support the more explicit list-before/after fields rather than a list on the tag tiddler. But I don’t even have a good design in my head, never mind an initial implementation.

#17

I am trying to wrap my head around this too. Is drag and drop not by design a bespoke order and explicit lists the opposite?

#18

That’s an exercise I do all the time for any complex project, especially ones that have been around for a long time.

Without considering how I could get there, I imagine what the system would be like if I were building it from scratch with all the information gathered since it started. TiddlyWiki has developed a lot of cruft in the name of backward compatibility. That backward compatibility is essential for long-lived projects, but but it does lead to systems with a dozen ways to do one basic thing, and no ways to do one obvious things because doing so would break one popular plugin written a dozen years ago and not updated for nine years.

I have many things that I would do differently if starting from scratch, from extremely serious to trivial. I’m guessing that anyone who has worked with it long has such a list. @jeremyruston’s list must be gigantic!

Just a few:

  • There are inconsistent naming schemes everywhere: title, _canonical_uri, currentTiddler, tm-edit-tiddler, $field. Or think of how to reserve certain names for use in the core, we use a $ prefix, but to reserve certain other names for use outside the core we use a . character.
  • We use of one field (title) for both the unique id for the tiddler and its default display name.
  • We can write tiddlers to shadow entire other tiddlers, but we can’t so this at the field level.
  • We have functions and procedures… but still have their macro predecessors.
#19

I’m a little confused by the question, since drag-and-drop is one chief way we maintain the explicit lists in a bespoke order.

I would prefer that we could use drag-and-drop or something similar to @vilc’s new offering to allow us to maintain list-before / list-after on the individual tags rather than list fields on the tag tiddler.

#20

Actually, I was hoping you would do it for this tags issue, how do you logically combine drag and drop with set orders in list-before and list-after. In some ways they seem contradictory.

  • I genuinely want to understand this.

Start opinion!

I don’t actually see the problems you do with tiddlywiki. I feel the focus on backwards compatibility has informed the design of solutions that don’t compromise the past or the future as much as many people seem to think. Sure it may increase the complexity sometimes when trying to change the underlying behaviour, filling gaps we find as our use gets more sophisticated, or when learning how it works, but it actually is this “priority” that allows most users to “not know how it works, under the hood”, but to rely on the published practices.

If backwards compatibility was not assured you would always be having to know how it works under the hood, to avoid unexpected consequences.

I have always being interested in IT because it has sat at the forefront, bleeding edge, of human understanding, and I always push the limits of a system I get to know. Sure I am always pushing the limits, but that does not change how few limits are imposed on us by what we have today in tiddlywiki.

A new wiki, one that you don’t plan to distribute, can break every rule in the TiddlyVerse if it wants, so if it means enough to you, you need not design for the future, but fork it into a bespoke solution. It seems to me with tiddlywiki, the question is “are you going to generate technical debt for the future”, not how much technical debt tiddlywiki already has.

/end opinion