stop … (required) tiddler title to stop … Needs to be a tiddler, otherwise there is an error message
start … (optional) tiddler title to start with. defaults to currentTiddler
exclude … (optional) tiddler list of titles to be excluded. eg: title [[title with spaces]]
label … (optional) label to be shown in front of the breadcrumbs nav
sort … (optional) defaults to yes. In TW tags are usually sorted
start … (optional) tiddler title which contains the “list” field. defaults to currentTiddler
exclude … (optional) tiddler list of titles to be excluded. eg: title [[title with spaces]]
label … (optional) label to be shown in front of the breadcrumbs nav
field … (optional) defaults to “list”. Field name that contains a title-list that should be shown as breadcrumbs
The “field” verions can be used to create “out of order” breadcrumbs as shown in Filter Operators
So the railroad-plugin and breadcrumbs macros will need improved palettes to work well with all palettes.
You can use the Palette Manager Edition to globally improve existing palettes. The edition contains the palette-manager-plugin-beta that can be imported into your wiki.
The INTRO for the palette-manager edition can be found at:
We can have 6 different hierarchies. I like to call them: Stories. … I do have a story-editor, which allows to create as many stories as you like. … But the UI is bugged atm.
Just brainstorming
The visual representation of different story branches using breadcrumbs visualisation could look as follows.
The whole “story” would be visible from start to end.
If a branch is possible it will be shown too … from the branch point till the end.
… and so on
________ _____________ __________________ _____________ _____________
\ Start \ \ Main Branch \ \ Decision making \ \ Branch A \ \ End \
/________/ /_____________/ /_________________/ /____________/ /____________/
_____________ _____________________ ___________
\ Branch B *\ \ Branch can be \ \ End \
/____________/ /_independent_from_A_/ /__________/
Where the actual tiddler is marked with a *
The actively viewed tiddler will be visually different. In the ASCII art represented by the * …
Higher level branches can be “collapsed” … to increase readability. eg:
________ _____________ _____________
\ Start \ ... \ Branch A \ \ End \
/_______/ /____________/ /____________/
_____________ _____________________ ___________
\ Branch B *\ \ Branch can be \ \ End \
/____________/ /_independent_from_A_/ /__________/
If Branch B is active and Branch A has the same "level" ... the Main Branch can be collapsed
I’ve called them “pathways” and “tutorials” in my WizardNav Plugin. But I like “stories” a lot.
That is a very useful depiction of parts of a complex wiki. But I think it’s not capturing what people really use breadcrumbs for on the modern web. They do not represent the location on a linear journey through a fixed set of nodes, but rather a hierarchy leading to the current node.
In a sense, they are a simplified, partial table of contents. A TOC shows the hierarchy from the root to every node. Breadcrumbs show the hierarchy from the root to the current node, allowing you to easily jump back to any level above the current node. Links to content below the current node are not shown as breadcrumbs. They are handled in different way internal to the current node.
So, while I think what you’re looking at might well be worth exploring, I don’t think of it as having much to do with how we’d use breadcrumbs.
As to your actual work. How would you expect things to display if nodes are in very different spots in different stories? That is, if one story is A -> B -> C -> D -> E -> F, another is A -> W -> X -> Y -> Z -> B and a third is A -> Y -> F -> B -> C -> W, how do you place the various elements? Sometimes B is ahead of F, sometimes behind it, and sometimes F doesn’t show. It’s easy enough if you display one story at a time, but with multiple ones, it seems to me to become very tricky.
Breadcrumbs will be from a root to a node only in highly structured environments, I have use large mainframe systems that use this. They usually demand you follow the structured path to get the job done, and as a result the path or story is equivalent to breadcrumbs.
TiddlyWiki however allows multiple structures even non linear ones
The metaphor of breadcrumbs does come from Hansel and Gretel and represents a trail you have traveled and allows you to return from where you came.
Although it is commonly misused
I do like the idea of stories represented like @pmario illustrated but I see, in some cases, the potential for too much information to handle easily and by default on tiddlers.
I realised a few months ago that this information, both the existing structure, and where we have traveled, can be represented with traffic signs as a metaphor, especial since most of us understand them. Add to that our increasing familiarity with GPS mapping etc…
There is also an innate human skill I refer to as “Trail memory” I have mentioned before that we can leverage.
I feel confident that we can find a way to represent the relationshipps between tiddlers in all these different ways of organising them such as a heirchy, list, trail/story, breadcrumbs (Or path) and perhaps journeys and itineries (like a traveling holiday plan)
My notes above highlight that the answer to this depends which navigational model you are using, and all are possible in TiddlyWiki.
Off line I have developed a possible solution which endeavours to accommodate all of these, but it may be a while before I publish a full solution if I work on it on my own.
If designed well it will also assist when building such relationships, authoring journeys, etc…
Post script
True breadcrumbs belong outside the story
Hierarchical positions of a tiddler, belong in the tiddlers, in the hierarchy
Stories or journies you are taking can be both directly related to the current tiddlers and to a meta-tiddler
That’s the usecase, that I mainly wanted to discuss with this thread and that I want to try to improve with a work in progress PR at GH.
If users are new to a topic I think it’s important to provide the hierarchical context a tiddler is in. Once users are familiar with the whole system, this information will be less inportant for the understanding, but it can be a “quality of live” improvement, because it provides a nice and fast way for “linked navigation”
That’s also a main goal of the PR mentioned above.
IMO this could be browser history, which can be activated in the TW ControlPanel → Settings tab.
If the Navigation Address Bar is activated as shown in the screenshot … and
Update history is activated …
The browser history 3) could make sense. … but it does not, since the info stored there is not good enough atm.
The browser back and forward buttons work … That’s a good thing. … But IMO most users don’t know about those settings.
IMO these features especially 2) should be improved and more prominently document.
That’s a challenge, which imo would be worth while to experiment with. I do not have a solution, but I’m very interested in presenting information in a context. … Even if the system itself is “non linear” … Or especially if the system is non linear.
I have given this some thought and recall having found a solution. I hope the recollection is correct. I will look for my notes. One memory I have is having an independant position stored for each story and a current story and to navigate away from the current story always returns to your original position in the current story unless you change story.
There are other gaps in the documentation and its searchability as well. I recently developed a keywords solution that enhances searchability by promoting some results ahead of others, search tiddlywiki.com for common terms like " filters" and the expierence is poor and even more so if you want a system tiddler like control panel or tag manager.
the only thing I need to solve is adding keywords without touching shadow tiddlers, although this would be uncommon except for technical self documentation.
although my masquerade solution may be a good solution.
the keywords could promote master tiddlers that expose a story or heirachy you could use to take a curated journey.
Aside: Maybe this belongs on the other thread but that thread is already too lengthy (IMO) to foster clarity for reasoned discussion. So…
To be clear, we are not truly talking about breadcrumbs, but rather something like “predefined pathways through a chosen topic chosen from among many”.
Breadcrumbs, on the other hand, should show the path taken to arrive at a given point (with no preconceived idea as to its logical/hierarchical placement within the forest as whole).
I’d much prefer to not use the term “breadcrumbs” for the “wrong thing” because, should we decide later to offer something truly breadcrumb-like, the term will already have been misapplied leaving us struggling to find another.
Let’s please call them TRACKS (or something).
But that’s just displaying HISTORY, like the browser back-button!
I don’t believe it is to TiddlyWiki’s benefit (philosophically or otherwise) to rest on facilities provided by user agents. TiddlyWiki should (and does) “stand alone” and do its own thing.
Yes, but that would lead to a huge line of links that simply wouldn’t scale!
That’s an implementation detail easily solved when the design is being thrashed out.
But that’s not how breadcrumbs are used on the web. Nobody does it like that!
Typically, TiddlyWiki does not encapsulate a conventional website structure.
But this is only meant for documentation tiddlers.
Good point. But once it’s used there, like everything else in TiddlyWiki, it will be used and incorporated elsewhere. Again, it’s the term I’m proposing to change, not the mechanism.
@pmario Feel free to move this if you feel it necessary.
A breadcrumb or breadcrumb trail is a graphical control element used as a navigational aid in user interfaces and on web pages. It allows users to keep track and maintain awareness of their locations within programs, documents, or websites. The term is a reference to the trail of bread crumbs left by Hansel and Gretel in the German fairy tale of the same name.[1]
All your quotes miss references. So I think they are your interpretation, with which I disagree. …
Hansel and Gretel’s breadcrumbs lead from their home into the forest. … It’s the path they took to go there, that’s a fact.
The same thing is true for the eg: “Filter Step” tiddler. … If we go back the way as it is shown, we will end up at the home of the “Filter Syntax”, which is the “Filter”.
For new users the filter syntax is very complex and hard to understand. The existing documentation does nothing to help users to immediately see the context the different doc tiddlers are related to.
These plugins try to help them with a visual context.
The dynamically created structure may not be the only way to get the big picture. You are right, it is a curated one and I’m sure it is a good one.
I felt like that is what we were discussing here. For instance, in TW-com, we have all sorts of documentation on Filters. A fair chunk of it forms a hierarchy. The clickable railroad diagrams are one beautiful way to express that hierarchy. Breadcrumbs were brought up as a more general way to do the same thing, to express hierarchies that exist among subsets of the tiddlers.
I think of those as a different sort of beast. Those are usually expressed as a fixed set of steps, with the current step highlighted, and the main navigation involves previous / next controls. Breadcrumbs allow direct access to any of the levels above the current one in the hierarchy.
As I said ealier, I think that ship has sailed. “Breadcrumbs”, like “file”, “folder”, and “desktop” are analogies to commonly-recognized concepts, but are never perfectly correlated. “Breadcrumbs”, like their fairy-tale counterparts, help you navigate your way back. But they don’t track the entire path you took, and they also offer jumps higher back that Hansel and Gretel would much have appreciated!
That’s a very serious concern for large wikis or ones with many interconnections. I think @pmario’s story metaphor is great for smaller chunks, without too many overlapping paths. But it breaks down when there are too many links.
Yes. It is significantly enhanced by a visual metaphor, such as a tree navigation, a connections map, or breadcrumbs. And some people have stronger senses of this than others, as we’ve discussed here before.
Note that my question to @pmario was specifically about his proposal, an attempt to show that it’s likely to run into scalability problems. Although I still have some ideas about it, I ran into this wall with my Nearest Neightbors demo. Some day I will try to get back to that, to build a graphical view, but it’s extremely challenging to find a good way to this.
I think there’s some problem with “the hierarchical context a tiddler is in”. When we have a single such context, there seem to be a number of good options. But nothing seems to work well when there are many.
As I realized when writing my WizardNav plugin, tag tiddlers are a pretty powerful way to capture such information.
I’m trying to steer back to “breadcrumbs” as used on many websites. This is what I think would help with documentation on TW-com. They’re not perfect, and if tiddlers really should show in several hierarchies, it can get ugly. But I think overall it would be a big help.
Absolutely.
Yes, or stories, pathways, etc.
But rather than that, let’s go back to discussing more standard breadcrumbs for hierarchies.
But it does borrow a lot from the standard web (think links, tabs, cards, icons, etc.) When we can reuse conventional structures in a familiar way, we make it easier to use.
And I’m suggesting much the opposite: let’s find a mechanism to match the term. We already have opt-in TOC functionality; let’s add opt-in breadcrumb functionality. But here I mean web-standard breadcrumbs, and not a full story/pathway/tracks/trail feature.
It sounds fairly simple to implement, so long as tiddlers live only in one hierarchy. (Just give each tiddler that live in a hierarchy a field that notes its parent, traverse the chain until one doesn’t have a parent, reverse the list and display it as a list of links, in whatever pretty format you like. Or – only a little harder – express it by having tiddlers list their children.) But as soon as any individual tiddler has multiple hierarchies, it gets much uglier.
The breadcumb navigation would be great improvement in documentation.
Some thoughts:
The term “breadcumb” does reference to trail/track/ …/navigation/path. I would also be more inclined to use one of the referenced terms.
I have doubts about: how/where we would want to display it. It shows new questions about how it could be implemented.
Would the use of this navigation be stored in any place? Someone might want to move foward/backward, althought it would be too work to implement it.
There are many points to close before to start.
While I was reading I thought in possible uses of the breadcrumb macro.
The macro to use in the body or outside of body (like the tags wrapper)
Hint about the breadcrumb or not.
Example: Navigation: breadcrumb 1 > breadcrumb 1 If the term for this define the breadcrumb menu is Navigation
Another idea, and more complex, would be a kind of wizzard/navigator (tiddler) for the documentation with its breadcrumb menus and one or more stories to facilitate the navigation.
