News:IMPORTANT MESSAGE! This forum has now been replaced by a new forum at http://forum.eastgate.com and no further posting or member registration is allowed. The forum is still accessible via read-only access for reference purposes. If you wish to discuss content here, please use the new forum. N.B. - posting in the new forum requires a fresh registration in the new forum (sorry - member data can't be ported).

One of the use cases I have in mind for Tinderbox is keeping track of the notes I jot down about students in the classes I teach. I have a list of all students by class (across my five classes) in Excel, ready to paste and explode. I'd like to be able to have it automatically aggregate all the notes about a student (as much as possible — I'll need to disambiguate on some name conflicts, I expect) under that student's name.

I.e., I expect I'll have one container for each class, and within each of those, I need one container (or agent) for each student. I'm thinking I'll want to use some daybook-style organization for the writing of notes — one container per day, or maybe per class per day. I don't mind manually sorting them into a subfolder for each class, since I have three or fewer per day and they're all temporally grouped (as I'm writing notes during or at the end of class). I need the writing of these notes to be fast, however, and sorting manually or clicking into individual-student containers is cumbersome enough that I know I won't do it, realistically.

My first thought was that this would entail mass-creating agents, one for each student, to gather notes containing the student's name. That sounds just sufficiently hacky and complex that I thought I'd check and see if anybody does this sort of organization, whether there's a better way, and how I'd best go about doing it.

Something involving mass creation of agents might be a hard route as you can only create an agent manually. You can however duplicate & modify existing agent or use a prototype** that sets the agent. Either of these would reduce the time amount of effort to set up the agents.

** that doesn't have to be an agent itself (indeed it's better if it isn't). A note prototype can still set $AgentQuery for instance, it just doesn't do anything with it as it won't be an agent.

If nearly everything has an agent, you'll have a lot of them so be open to the fact that at some point you'll need to turn auto-updating of agents off (it's on by default) if things start to run slowly.

As you'll probably have lots of repetitive building out to do, as well as prototypes them selves, don't overlook that prototype can bequeath children, i.e. when you apply the prototype it adds new children/descendants. It's a powerful technique, where pertinent.

It's worth trying to build out, in a separate specimen doc, the structures you think you need. What we imagine and we eventually build often differ and you want your prototype to reflect the latter.

If I understand correctly, it looks like probably the quickest way to do this with the Attribute Browser is to use the student's name as note name so that the Attribute Browser can group by name, and then write whatever comments I need to write in the text of the note.

f I understand correctly, it looks like probably the quickest way to do this with the Attribute Browser is to use the student's name as note name so that the Attribute Browser can group by name, and then write whatever comments I need to write in the text of the note.

For uses like this, I rely on the Attribute Browser all the time. It's much easier than you might think. You can have the $Name of the notes be whatever you want. That is, you don't have to set it to the students' names for the grouping to work.

As long as one of the attributes for each note is something like $StudentName, which will probably work best as a Set-type attribute, then the Attrib Browser can automatically group the notes by each student's name. You can also set the Attrib Browser to display only notes from a certain class, a certain date, or any other conditions you want. (You do this with the non-obvious but very powerful "Query" part of the Attrib Browser.) Then it will auto-group the appropriate notes by the attribute you choose.

OK, I think I have all the pieces put together. I was hung up on thinking I had to do something special to get TB to associate the key attribute with the set of student names I'm working with; it looks like it'll be simpler just to type each name the first time, then let autocomplete handle subsequent entries. I was pleased to see that key attributes support autocompletion.

For the benefit of the next person who's trying to figure out the same procedure: after some digging, I just discovered Opt+Tab (change focus from text pane to key attributes), so the following procedure will let me create a note and populate the attribute I'll sort on ($StudentNames) using only keyboard shortcuts: