I have long sought to find easy to use ways to handle tiddlers having many roles, types and uses.
Here I outline a design approach / code pattern, I am working on, at the end I seek ideas and input.
I will publish a demo shortly.
I have designed a card system where multiple cards are displayed on tiddlers if they meet various criteria, using a display-filter, and these cards provide information pertaining to that criteria. A simple example may be on a tiddler that is also a tag, where the card provides a tag pill and optionally lists all tiddlers with that tag. For now my cards include;
Field Tiddler
Flag Tiddler
JSON-data tiddler
System tiddler
Tag Tiddler
Tiddler card
Configuration Tiddler
has-non-standard-fields card
May apply a form here
Missing Tiddler
Shadow tiddler
Tags as fields
You can see how these are tiddlywiki and system oriented.
Well in recent discussions about allowing tiddlers to have one or more roles, a list as opposed to a single role, it seems a similar mechanism or included in the above would be ideal for roles as well. Simple examples include some of the above;
A contact tiddler
A country or city tiddler
A webpage tiddler
A report tiddler
A to do item
A Project or project item
A question tiddler with an answer card
and many many more.
For any tiddler, most likely only one or a few of these roles will apply, but along with the cards above you can see that the number of items (Cards and Roles) to display on any given tiddler can quickly grow.
Questions then arise;
What order should they appear in, across different combinations of roles/cards
When and how do we show/hide some cards/roles via local or global settings
How to we show there are hidden roles or cards the user can select to view
When and how do we switch to cards/roles with less whitespace, ie make the display more compact.
One reason this cards and roles idea has credence is as a designer I control the way this works without needing to use the standard cascades, I can embed all the logic I want without needing to leverage the view cascade beyond including the roles or cards handling.
I do hope one day to share these methods with the community.
I want to use it to support some of the solutions I have being discussing lately
No touch flags
No touch Notes
Field and field-type handling
etc…
Please tell me what you think about this approach
Please tell me if you have any strategies for handling multiple blocks of content on a single tiddler
Not sure I appreciate what you are trying to do, @TW_Tones . Can you provide some examples?
From what I think I understand, you’re working with the context(s) in which a card can exist and are developing a contextual process for handling any context for multiple cards. yes or have I got it all wrong?
Lets say I have a tiddler containing contact info, and I set the tiddler “roles” field to “contact” I can display a “contact card” on that tiddler (show name and phone number etc…) Now lets say this contact tiddler is also an organisation, I may also give the tiddler a role of “organisation” and display a card for the organisation. The roles field now contains “contact organisation” (show help number, office address etc…). Then I decide to tag other tiddlers with this “contact/organisation” tiddler, so now it is also a tag and I display a “Tag Card” which lists all with this tag.
In this example I have three cards with two roles and one as it is a tag. But now imagine other tiddlers with more simultaneous roles or cards displayed.
I haven’t dug around too deeply in your demo site yet, but some first impressions…
It looks like you’re aiming for a unified format where a number of diverse types of information will be presented in more or less the same fashion. But personally, I’m not sure all these features require or even benefit from being handled this way. And as you point out, it eats up a lot of on-screen real estate.
A few elements (like the code-body/hide-body toggles) are things you’d probably only set once per tiddler. I’d be inclined to make these buttons in the View Toolbar instead — possibly in the “More” dropdown, depending how often you use them.
Other cards (like your “Tiddler card”) seem to duplicate or expand on information already presented in the Tiddler Info section — which is probably a good place to put most of the other config/developer-oriented options.
IMO, most of the other cards — that is, the ones you might actually want to see every time you view a tiddler, like tags/flags and your tiddler “roles” — would make more sense as individual sections with the $:/tags/ViewTemplate tag. This would answer the question…
… by allowing you (or other potential users) to rearrange the cards’ positions relative to each other and to the tiddler body — even on a wiki-by-wiki basis, if desired.
However, if you do really prefer the everything-is-a-card approach…
I’d consider folding all your cards into a tabset a la @Mohammad’s Mehregan edition — see the options at the bottom of each tiddler. These tabs could be dynamically generated as you’re currently doing with the individual cards… but even if they weren’t, they’d take up less space and could be hidden when not in use.
This sounds like what I’d call role-specific view templates, along with an attempt to systematize what kinds of roles a tiddler might have. (For me following this idea is a bit complicated by how much I — a child of the Hypercard era — like to think that “card” is analogous to tiddler, rather than to aspects or facets of a tiddler/node.)
EDIT TO ADD: I currently use various filter criteria to determine which roles a node (real tiddler or “missing”-tiddler node) might have, given the data structure of my project. Especially because templates (like your cards) apply to virtual nodes, I’d be wary of needing to “set” the roles. (Then again, I could imagine something like a set of tabs that shows up for these role-cards, so that “choosing” a role is just bringing visual focus to that tab…?)
I suppose I’m not sure that I would see a comprehensive overview of possible roles as possible…
For example, in a bibliographic wiki there are author templates (for nodes corresponding to the value in bibtex-author field of another tiddler), bibtex-entry-type templates, etc. These are like your “cards” but more specialized to that kind of wiki. (And like your cards, there could be a node that has multiple roles: a person might be the author of some works, an editor of another, and the subject-matter of yet others.)
In a classroom-oriented wiki, a similar thing would apply to values that are determined to be student names (or assignment types or assigned-text titles or session dates etc.). There are so many ways in which the nature of the project suggests certain “shapes” or “slices” that should come into view based on … “intertwingularity”.
But I like the idea of brainstorming a wide variety of roles for which “cards” (helpful view templates) would make sense.
I also LOVE the idea … though it would be quite complex … of having a “wizard” for intertwingularity. There could be a process that analyzes a wiki and recognizes where the power-nodes MIGHT be — nodes that “want” a card.
For example, when the number of values in a field (or strings in a list field) is much smaller than the number of tiddlers that have that field, that is a mild reason to think that values in that field may want a “there there” that could be a window into where that value appears (since the commonality/overlap may matter). Meanwhile, when a field’s values don’t have much overlap, treating its values as nodes is not likely to be promising. (Unless (!) the granularity of a timestamp, say, is distracting us from the usefulness of highlighting a day as a node worthy of a template/card for getting a view of things that have that day in common… this is why such a wizard would have to be savvy.)
Yes but this is simply an example so far, the solution need not be universal and need only be used when relevant. It seems to be raising the right questions.
Agreed, these were simple examples, items can also be suitable in the Info dropdown, tabs.
Thought what you highlight is it may be worth sketching out some prose that helps one determine when and where it may be best to place such content. The code-body for example is intended only to appear on tiddlers (not shadows) because otherwise it will edit the tiddler. Another method should be used.
Agreed, I just rushed out these as examples and many system and design oriented info may be handled differently.
Just imagine other cards, the ones you would want to appear on the tiddler, This cards solution may as well be tagged $:/tags/ViewTemplate however because they have there own tag and are iterated within the card handling tiddler, I have created, I have the ability to add more features than exist in the current view template cascades. Including;
List or delist additional items for a given tiddler
Set a display filter
Reorder on the current tiddler
Choose from different display methods eg tab or card
As yet unimagined ways to present
Good idea, but I am tempted to make this selectable, imagine if one could switch between a tabbed view and card view, or both, even other as yet not imagined ways to represent such “roles”, have an automatic order, but then allow a local override or delisting, of that order, or select to add a role from existing roles/tabs.
Be aware the current tabs macro has some limitations so I would use my own construction allowing more controls.
There may be a case for deciding which tabs/cards are for the interactive user, and which are for including when printing, exporting etc… Tabs by definition are really only for the interactive user.
Thanks Springer for you considered response.
I think we need not get too caught up on what we call these things yet, more how given these things how do they work.
I think of a card as simply providing an organised collection of data in a tiddler that has a particular use. Yes, like an aspect of a tiddler and that this can be for a role.
Lets say all I have for now is a persons name, if I create a tiddler with their name and nothing else for now, it makes sense to set a role such as contact. This then automatically provides the other fields I want a contact to have, and can even tell me the contact number is missing, this could give it a new role a todo, ie a contact who’s details are missing that needs attention.
I would consider a Role more as an aspect of a tiddler, at most a subtiddler but more like a form or subform that collates aspects of the tiddler into logical groups such as our discussions on field definitions, imagine a field definition that is also a field-type, a tag and a flag.
For example it may become a contact tiddler simply by a firstname/lastname and phone number present. But sometimes we want this to be more deliberate.
Some roles may make use of separate subtiddlers, datatiddlers, flags and more.
I think of this more as detecting or assigning a role a tiddler has. My example wiki was just to demonstrate cards as a whole, and the existing cards are more “system roles” and in fact I expect many of these will be visible to the designer but not the user. The other roles are more likely to be displayed on a tiddler for users, and often limited in number.
The mechanism that determines what cards in what modes is part of this exploration.
To me this is even finer detail than a role. I imagine the existence of editor, author, reviewer etc… as suggesting this is say a “book content tiddler” and this role would exist for a tiddler if any of these were present.
Agreed, this is interesting, I think it may be easier to analyse each tiddler for this. I like brainstorming this as well, but then I find that when building and using a TiddlyWiki many of these just come into existence as the wiki and tiddler evolve. I will post something soon that is great fodder for brainstorming, adding common English prefixes and suffixes to tiddler and wiki.
I want a solution that exists and can be leveraged as the the content demands as it emerges.
Later when I implement my tiddler relationships I dea I think you idea to analyse the whole wiki and;
I love your speculation on this savvy wizard idea.
Given the responses so far it seem clear to me that the card idea is more about what appears in your face on a tiddler, and although you could display more when a designer is working and they are intentionally developing a solution ultimately what a user sees “in their face” will be somewhat limited.
But of course many of us are designer and user and this becomes how can we easily control the display of content on a tiddler beyond just the text field.
What I find key with tiddlywiki is we can make it easy for ourselves, even as the complexity increases, by leveraging code and design patterns and modularising them for easy reuse.
Sorry, I may have been unclear. I meant that if I were using a cards-like system, I would want each individual “card” (i.e. template) to be independently tagged $:/tags/ViewTemplate, not sequenced and rendered by a single card-handling template segment. This would allow you to rearrange cards with respect to the tiddler body rather than merely with respect to each other — as my intuition is that some card types would be more useful before the body text, and some after.
Other than the “reorder on the current tiddler” point, I don’t see any items in your list that couldn’t also be accomplished with traditional ViewTemplate segments (i.e. not cascades).
In any case, I understand that your demo is still in the very preliminary stages. From what you’ve said thus far, the solution you’re designing here doesn’t sound like something that would be very useful to me; my wikis are already designed to do the sorts of role-handling I need. But I’m interested to see where you take this, and perhaps I can draw some inspiration from you in the future.
Well, in a bibliographic wiki, ALL the basic substantive tiddlers — thousands of them! — are about aspects of books. (Or maybe we do add some real tiddlers for various field-value content, as when we have biographical data or website url for a particular author, etc… but the core content is lots of these biblio records.)
And the template appropriate to an author node (a overview or cross-section of works authored by this person, intended to bring salient aspects of that info into view) is a very differently-structured template from a subject-matter template (where “John Dewey” appears in a subject-matter list field alongside “pragmatism” and “democracy”). I imagine a template for subject-matter, for authors/editors, and maybe for citation connections (both ingoing and outgoing). Although these might sound to you like “well it’s all book-related” to me they clearly call for rather different templated “angles”. … Something very much like your “cards” would apply, within a bibliographic wiki, to multiple and importantly different “slices” of what matters about a book.
I don’t want to belabor the biblio use-case in particular too much, but I do think that as soon as you become intimately invested in a wiki that’s really crafted for a purpose (genealogy, bible passages, atomic elements, business transactions, recipes), there will be ways in which data structure emerges around thematic shapes (templates / cards) that you wouldn’t have any glimpse of while thinking generically.
And that is all fine!
So long as any initial list is both provisional and easy to expand.
Thanks again for your perspectives @etardiff and @Springer, I always get excited when I see either of you have replied.
You were clear, I understand.
Lets rephrase that what if I want my card above the body vs below the body or at the bottom?
Ok let us see how we can implement this.
Because the card system is our own we can extend it easily. Like each card could have a position
above body
below body
a line
above line
below line
Here I consider a line being used to separate content into a below body and either above or below a line to indicate footer types of card.
However Now I want a way to move cards into tabs as well.
There may be other alternatives to in body, in Tabs, in Info, in list/details, in view template
Perhaps a card can be just placed in the standard view template with a click
For each of the above positions there would be a card handling component with the $:/tags/ViewTemplate tag.
If we wanted to enable it you could just tag it differently $:/tags/ViewTemplate and have it iterated. You would need to wrap it in the conditional filter if needed.
True but the examples are poor. They are system roles.
Yes, that would be the idea, however by becoming a card it gets access to any features we develop for cards, such as a local delist - where a tiddler can state give me all the cards except these.
Just because it can be done another way does not mean there is not a better way.
Yes, Preliminary.
I doubt its useful to you because you have done the hard slog, as I have to implement this in our wikis. I have the habit of looking ahead and considering more naĂŻve users including myself after being away from tiddlywiki for a while.
Great, but be aware that one reason for bifurcating this from the $:/tags/ViewTemplate process is because of inspiration from yourself and others which can be more readily adopted within this model. It is taking inspiration from your words as well.
Agreed, and perhaps the purpose of such a wiki does not need access to a “content display system”, just don’t use it. But if you need it use it.
I think of this solution being used in two ways
As a wiki gets more complex and needs to handle multiple roles (perhaps in the past we called this tiddler-type or object-type), your tiddlers may only have one role at a time, or they may have many. If your viewTemplate starts to get complex you may consider introducing cards to handle multiple roles.
You are developing a wiki where you expect to have different tiddler roles, or multiple roles on your tiddler so you install the cards system to help you mange, organise, debug and customise roles. All of which can be transferred into another part of the cascades.
That is one of its key functions.
To put it very simply, this would allow management of what appears on tiddlers, especially when a tiddler has a particular role, or more than one role. If you don’t tag it with its tag $:/tags/viewCard or set its display-filter to blank it is not in the picture.
There will be a set of cards out of the box you can use temporarily or permanently relating to tiddler roles from a core tiddlywiki perspective. Eg “tag tiddlers” or perhaps a “field tiddlers” card for field tiddlers.
Just catching up here, and reading a little too quickly, but this strikes me as where such an approach might really shine: perhaps not so much as an end-product, but as a sort of scaffolding when you’re building out a more complex approach to a wiki.
I’m pretty sure that many others will do what I do: write <<list-links [my[filter]]>> for a quick view of something I’d want to eventually invest with a full $list widget and maybe a large complex template, but which is good enough for now. Such scaffolding may last a long time as I work on more important matter, but I usually come back and replace it with bespoke handling.
These cards sound to me like they’d be perfect for doing such scaffolding at a higher level.
Yes, that is very much like I am thinking. a card would allow you to write something to be displayed on all or a subset of tiddlers, but in such tiddlers rearrange as needed into tabs or even into the view or edit template with a click or two. we could provide a card toolbar that can be hidden for cards until needed to enable this.
remember if independently managed seperatly from the view template cascade it’s simpler to add features, but keep them reusable.
I am interested in solutions that help us go from thought to implementation immediately.
eg: excise to card, excise to global pragma/macros
