Thanks so much for your helpful feedback. Quickly…
I think I’m doing this. For the “People” agent / folder, I’m using the following query code: $Prototype=="pNotes" & $OfficialsPlayers – but I realize I need to do more than use that code and go into the the Appearance Inspector and select a “person” badge (which just affects the folder, and not the notes underneath it).
As to your second point… At this stage, I was just thinking about using just two badges – for people, and timelines – and maybe including some other colors, patterns, or flags. But I’ve been hesitant to do this because I understand that Tinderbox notes don’t do well when their being assigned to multiple graphic designators. And again, I don’t know in advance when a note will have competing badges, etc.
Is there a general approach for managing multiple graphic designators? Thanks!
I don’t really understand your point. Tinderbox has only one badge designator. You can’t use two badges. You either create a custom badge that shows you two things (i.e. one badge with two visual elements), or have a badge and 2nd visual (e.g. color, border, shap, flag).
Also, I highly recommend you place state value in attributes and not fully rely on prototypes. Why, because if you ever move the note form one file to another, accidentally delete your prototype, you can use the value in the attribute to quickly assign/reassign it back to the state you want to use.
Right. Ok, so I was just hoping to use two badges for my notes in my Tbx database (for People and Timelines), and then use other visual elements for other Attributes. I understand that I don’t want to have a note with more than one badges. So, I was wondering if I should forgo with using more than one badge, to avoid instances in which a note would have badges for People and Timelines. Or if there’s a way to resolve this that wouldn’t be too onerous.
Gotcha. So, does that mean changing query codes like query code: $Prototype=="pNotes" & $OfficialsPlayers so that they omit the prototype but include the attribute? If that’s right, how would reconfigure query code accordingly? Thanks!
I would to call Tinderbox a Database. Tinderbox is NOT a database, but rather a structured XML file with a killer application layer on top that lets you do all sorts of fun stuff. In Tinderbox lingo Timline is a view. There is no secut thing a “People”, there are notes that you can represent as people by changing the visual look and feel and the value of attributes.
I don’t understand your use of the word Timeline. Are you referring to the Timeliene View, or something different?
I don’t understand the question. A prototype is an attribute. You use queries to interrogate the value of attributes to return the notes that meet your request. So, I don’t understand what you man by omit prototype an include attribute.
Remember, Tinderbox is a collection of notes. Every note is structurally the same. They can be individually visually different, or their visual representation and the values of their attributes can be inherited from prototypes.
Sorry, I should’ve clarified that… I’ve created an user attribute named $Timeline to label notes that have important dates.
Right. I thought you were suggesting that I rewrite code that would omit prototypes, based on the concerns that you expressed in your previous posts (re: "not fully rely on prototypes…because if you ever move the note form one file to another, accidentally delete your prototype).
I see. Is $Timeline a string? list? set? boolean? As noted, you could set a badge an use the value of Timeline to set a Flag. Only issue with this is flags are not visible in outline and other views. So, so, for ease, for notes with an important timeline you might consider changing their color.
No, I was not suggesting this at all. I was suggesting you create an Attribute call $Type, for example. Any attribute you’ve assigned to the person prototype you’d have a corresponding value in $Type, e.g. “Person”. That way, if the prototype is ever deleted or note moved you could use the value of $Type to reassign the prototype. This is a failsafe not strategy and management approach I’ve found to be VERY beneficial.
$Timeline is a date; $OfficialsPlayers (people) is a set.
Ok, so as I said above, the $OfficialsPlayers (people) attribute is a set, and this is the code I’m using for that agent…
$Prototype=="pNotes" & $OfficialsPlayers
I just affixed a badge to the folder, but obviously that doesn’t affect the notes that are captured by the agent. Could I simply do that within the agent itself or would you suggest creating and applying prototypes for $OfficialsPlayers and $Timeline, so for their respective badges?
Thanks. I understand that one cannot have two pages assigned to notes. I suppose I’m trying to determine how best to assign visual representations to notes. It seems that you’re saying that’s best accomplished through creating and applying prototypes, correct?
As with many factors with Tinderbox, if there is one way to do something, there are 10. I’ll put more thought to this, but here is a list.
First off, yes, if you want to manage multiple notes at a time from a central point, you’d do this via a prototype. Remember, however, that you can change the prototype of notes without destroying a note’s local values, this is especially useful when you are performing different analysis and note curation activities.
Common visuals and techniques to support semantic meaning
Element/Method
Map View
Outline View
$Color
Yes
Yes
$Badge
Yes
Yes
$DisplayExpression
Yes
Yes
Links
Yes
Yes–a little bit
$Flag
Yes
No
$Border (color, width, and style)
Yes
No
$Shadow
Yes
No
$Title size and position
Yes
No
$Subtitle
Yes
No
$Pattern and $Accent
Yes
No
$Shape
Yes
No
$Fill (aka texture)
Yes
No
$Accent color (aka $Texture)
Yes
No
$Plot overlay
Yes
No
$Summary table
Yes
No
$BackgroundColor (aka outline)
No
Yes
I’m sure I’ve neglected a few nuances, will check the table.
The key point is that you can use the value of attributes, manage through prototypes and action code, to create visual semantic meaning with your notes.
The key will be for you to figure out what will work best for you to help you create meaning and insight.
I’ve been creating some discrete agents queries, and kept them under the the subject-based contains (e.g., all notes with Timeline values fall under my Timelines container – now including specific agents queries for key events).
I’m wondering: how can I exclude these discrete agents, and the notes they contain, from being counted in the parent container’s Display Expression?
To give you a specific answer I’d need to look at the exact structure of your file and your current display expression edict. Generally speaking, however, I think you’ll need to is to tell the display expression Edict to ignore aliases and agents within the container. You’d do this by only looking at notes that are NOT agents and are NOT aliases. So, you could add to your Edict something like $IsAlais==false&$AgentQuery!=="", i.e. count all the notes that are NOT aliases and whose AgentQuery is empty. Again, the specifics you’d implement this exactly will depend on a what you’ve already got set up.
I’d be happy to share something with you to give you a clearer sense of what it includes. Just to be clear, there are both aliases and agents under the containers. I do want to keep the count for the main agent (which contains alias notes) but exclude the others. Does that sound possible? Thanks.
Sure, share an example. Should be possible. I am curious, however, as to why you’re integrating notes and agents into the same container. This seems to be creating unnecessary complexity in your analytics and notes management.
I often have notes and agents in the same container! But I don’t often need this sort of count in a display expression: I typically do that in a separate dashboard container.
We’ll, I guess I do do. What I was referring to is that I don’t include the agent in the same folder that I’m conducting analytics or if I do I’ll modify the display expression code to exclude the aliases and agents in the count.
