Tinderbox User-to-User Forum (for formal tech support please email: info@eastgate.com)
Tinderbox Users >> Tinderbox applications >> Application for keeping track of volunteers

Message started by Fionnbar Lenihan on Oct 5th, 2014, 4:00pm

Title: Application for keeping track of volunteers
Post by Fionnbar Lenihan on Oct 5th, 2014, 4:00pm

Hi - I haven't posted here for years as haven't been using T'box much.  Recently been asked to manage volunteers for a local church.  The key task is to keep and maintain a list of volunteers, their roles and whether or not they have necessary criminal records checks, training courses etc on file.  There will be a need to generate a simple report on an annual basis with Surname, Forename, role and whether training course, CR checks etc done.  The number of volunteers would be around 50. Certainly no more than 100

My first thought was a relational database and I tried to design the tables.  It got complex very quickly as there are many:many relationships everywhere (volunteer:role:role requirements). I'm also not confident that I fully understand the problem domain yet (I strongly suspect nobody in the parish does which is a problem) so I don't want to spend ages designing a database that would have to be scrapped. I still need a workflow to get me started however.  

I then remembered Mark (Bernstein's) point that T'box was a good fit for problems with dozens or hundreds of entities and when your understanding of the problem is evolving as you work on it

I've made a start today with notes for volunteers and adornments for roles.  Once I'm satisfied all the requirements are met I will drag volunteer to adornment. Currently, the volunteers are all sitting on an adornment named "in progress" I plan to use alias's to cope with volunteers having multiple roles.  The volunteer notes have custom attributes (inherited from a prototype) to record the existence and date of mandatory courses etc.  There will also be list attribute to record roles.  I appreciate this is recording the role information twice but the attribute can be searched by agents and the adornment allows a quick visual scan which is nice.

I plan to use agents to generate the necessary reports, maybe exporting to a table with a bit of markdown maybe?

Being very rusty wanted to see if folks here felt that this was  sensible approach or had better ideas or thought that T'box not the tool for the job

With thanks
Fionnbar Lenihan

Title: Re: Application for keeping track of volunteers
Post by Mark Anderson on Oct 5th, 2014, 4:25pm

Hi (I recall meeting at a TB w//e - London 2010?). I think you've two parallel problems. The first is capturing the multiple relationships. The second is visualising/reporting them.

For the first you could have an attribute per relationship type, or a Set-type attribute to capture them all (or several if discrete sets). There's no 'right' way - the choice boils down to your dat and your style.  Generally, if there are a *lot* of relationships having one attribute per relation may not scale well. But the joy of TB's easy incremental formalisation is if you start down a path that's wrong it's not the complete do-over to fix as it would be with a normal database.

A different axis of this is the number of folk involved. Let's say you've 50 people and 10 possible roles (attributes), by the time you've got 30 people added some with up to 9 aliases the map will get very busy.  Thought: if only 4-5 different roles consider map aspects like badge/colour/shape/pattern to capture all roles without the need for aliases.

Title: Re: Application for keeping track of volunteers
Post by Mark Bernstein on Oct 5th, 2014, 6:36pm

Welcome back!

I think this sounds like a natural Tinderbox application.

Title: Re: Application for keeping track of volunteers
Post by Fionnbar Lenihan on Oct 6th, 2014, 10:32am

Thanks Mark/Mark;

I did indeed meet you all but it was in Cambridge, I think around 2006/7?

Thanks for the reminder about set attributes.  It looks like these have been enhanced since I last used T'box to become list attributes? Plan to use these as a flexible way of recording roles.  

After my first post I had a small epiphany (small ones are all I ever get!) about the "dual representation" of roles in list attribute and also by means of positioning on role adornment.  They don't necessarily duplicate if we take one as meaning "qualifys for role" and the latter as meaning "is assigned to role".  It might also be an opportunity to put in place a check so that, for roles that require it, the adornment could check that the necessary CJ check has been done or otherwise it would change the badge to a warning sign

Not sure how I could use badge/colour/shape to capture roles as you suggest Mark (A) however if we are sticking with a simple 1 note = 1 volunteer model.  The cognitive burden on me to remember that "blue border plus red stripes plus stave symbol means choir member, driver and Eucharistic minister" and so on for every role combination would be heavy :)

I see what you mean about multiple roles per volunteer leading to a busy map but I am somewhat drawn to the conceptual directness of plonking a volunteer on one or more jobs.  Makes drag and drop quite concrete! I can already get a real sense for the size and shape of the work from this

I'll play around and see how it goes.  At the very least it will be a useful way of managing the transitional workflow without committing too heavily to a design until we get our backlog cleared and routine operations established.  Then a relational database might work

Kind Regards

Title: Re: Application for keeping track of volunteers
Post by Mark Anderson on Oct 6th, 2014, 11:27am

[Aside: well remembered. Yes it was Cambridge TB w/e in Apr 2007 (the first TB w/e I attended).]

I agree about visual complexity of lots of border/pattern/etc., colouring making for a busy interface but some folk do like it - thus the suggestion. As ever with TB, there's no one right way. I see how dragging a person/note onto an adornment might ($OnAdd) apply a role to that's person's attribute data. However, I don't see how you get round the problem of Person A being in 4 roles (i.e. on 4 adornments at once) without the use of lots of aliases in which case I wonder how well things scale.

Still, with Tinderbox's good support for formalising as you go along you needed be too fearful of following the odd blind ally in finding you own most comfortable/intuitive set-up. The less tidy the problem, the more I think it suits a TB-based solution.

As you do about your map, keep a side thought for how you might stratify that 'flat' structure for exporting data (e.f. reports of whose on which role/stages of qualification/etc. I suspect agents may cope file but it's worth not-entriely ignoring export needs unless you 100% certain all data will only ever live in your TBX (as can be the case).

Title: Re: Application for keeping track of volunteers
Post by Fionnbar Lenihan on Nov 18th, 2014, 4:57pm

Dear Forum members;

Hope it's OK to post follow-up queries here rather than repeat the context elsewhere.

Volunteer application is working nicely in tracking people through the stages of the process and the volunteers are beginning to trickle out the other end. I find I have forgotten stuff I used to be able to do with Tinderbox.

I was hoping to start to develop a simple reporting feature by first collating a list of volunteers in regulated roles.  

An agent with a query


Works OK but trips up by including the prototype I use to record regulated volunteers which obviously has the attribute "IsRegulated" default to "true"

I next tried the following code in a query;


The second constraint doesn't seem to be tested for.  I'm sure it's a syntactical issue rather than a conceptual one.  Should there be some form of AND boolean operator to indicate that I want to see notes that satisfy both requirements? Looked in the cookbook but didn't see any applicable examples and the help file was similarly silent.

I hope to eventually export the report as plain text with a table defined in Emacs org-mode.  I note however that the option to use a plain text export format seems to have disappeared.  Any thoughts?

With thanks

Title: Re: Application for keeping track of volunteers
Post by Alex Boxall on Nov 18th, 2014, 8:13pm

You are almost there, I believe this will work:

$IsRegulated==true & $IsPrototype==false

If your prototypes are not in the same container as the volunteer notes (and the volunteer notes are all under the same container note) you may want to use:

descendedFrom("Name of container Note") & $IsRegulated==true

This would have the additional bonus of limiting the Agent scope, so it may run quicker in large documents.

Title: Re: Application for keeping track of volunteers
Post by Mark Anderson on Nov 19th, 2014, 3:25am

Further to Alex's answer - with which I concur - semi-colons aren't used in queries at all. If your query has more than one test, then each successive test must be 'joined' to the preceding one.

All joins are one of two types: an 'and' where all test must be met, or an 'or' where at least one test must be met. In TB queries, an ampersand '&' signifies an 'and' join and a pipe '|' is used for an 'or'.

Title: Re: Application for keeping track of volunteers
Post by Fionnbar Lenihan on Nov 19th, 2014, 4:39pm

Thank you both, works very nicely now

Just need to crack the export template

Tinderbox has gotten harder or I've stupider over the last few years :(

It may be that I remember being able to do stuff but having forgotten the details it now seems harder


Title: Re: Application for keeping track of volunteers
Post by J Fallows on Nov 19th, 2014, 4:53pm

Just need to crack the export template

I had been mightily buffaloed by exports, but here is what I think is the simplest possible way to get something started:

Step 1: Go to File/Built-in Templates and click HTML. This installs some HTML templates in your file and avoids getting the "No Template Found" error message when you try an export.

Step 2: When you open a note or, better, its prototype, go over to the text pane -- the right-hand window. Click the HTML tab, and where it says "Template / None," then choose from the dropdown list the HTML-item template you installed in step 1.

There are a million refinements you can apply, but this at least gets you past the "why on earth can't I export anything" hurdle.

Thought experiment for Eastgate: by default, install those built-in templates when someone creates a new file, or maybe the first time someone clicks on the HTML tab. That might complicate things for veterans who want control over their templates, but it would avoid the startup barriers to using this feature.

Title: Re: Application for keeping track of volunteers
Post by Simon Smailus on Jan 6th, 2015, 3:55am

@Fionnbar Lenihan

Just wanted to ask how you're getting on? I tried to track volunteers a year ago and it didn't work out to well for me, so would be interested if you've got it working effectively.

Title: Re: Application for keeping track of volunteers
Post by Fionnbar Lenihan on Jan 8th, 2015, 6:35pm

Hi Simon

The application, such as it is, works very well.  Tinderbox is a good tool for looser bodies of information and workflows which are as yet not fully understood and defined.

Still stumped by export but haven't had time to study the information on this topic and in the tinderbox way, in sufficient detail. What I'm struggling with is the recursive nature of template(s) needed to export a container and certain fields from the children of the container. In the interim, in just typing the information from screen. This works OK with the small numbers I have so far but won't scale well

Happy to send you anonymised version of my document if you like though it's so simple it's hardly worth it. Email me on



Title: Re: Application for keeping track of volunteers
Post by Mark Anderson on Jan 9th, 2015, 3:56am

@Fionbarr, you might find this topic I just added to the Export forum to be of use in figuring how to export.

Tinderbox User-to-User Forum (for formal tech support please email: info@eastgate.com) » Powered by YaBB 2.2.1!
YaBB © 2000-2008. All Rights Reserved.