Tinderbox for a psychotherapy practice?

My life and activities have changed significantly over the past year, and this has accelerated in the last three or four months, and I am now looking at spending the last few years before I become completely senile in working as a counsellor/psychotherapist, both for a charity and in private practice.

It has dawned on me that there is a lot to keep track of: appointments, notes (confidential) regarding sessions, client contact details (also confidential), logs of hours I have worked, records of bills (sent, paid, unpaid, etc.), logs of Continuing Professional Development (CPD), logs of supervision hours (and what was discussed) … etc, etc. (Until now, some of this has been handled by the charity for which I volunteer, but I will have to do it all myself when I start working privately.)

Although there are software packages that will handle all this sort of admin (e.g. https://counsel360.co.uk/, https://www.wearekiku.com/) it seems to me that I could do what I need in Tinderbox.

I may be wrong about that, and I may eventually opt for a ready-made package, but there is something else that inclines me to at least give it a try in Tinderbox. It is this: the main “tool” that one uses in psychotherapy is one’s “self” – one’s physical presence, one’s psychological being, one’s accumulated experience, one’s feelings, thoughts, ideas, and the ability to communicate them. There are powerful reasons why “self-care” constitutes an important aspect of working as a counsellor/psychotherapist. Keeping clear boundaries between work and the rest of life is important in this sort of work, but my own personal view is that some blurring is inevitable. (As an example of this, a friend of mine was recently audited by the British Association for Counselling and Psychotherapy [BACP] and among the things she had to report on was self-care – which for her included gardening and taking walks with the dog. I’m not suggesting ridiculous levels of detail here, just that there might be some point in tracking activities that are not strictly “counselling”.)

In short, the ready-made admin packages are all about admin – just bills and appointments, etc. But Tinderbox would, I think, permit me to keep track of so much more, and also offer the possibility of linking it all together, and analysing it (don’t ask me how, at this point!).

I’m merely thinking out loud at the moment, but I’m interested to know how more experienced Tinderboxers might react to such a task or project. I’m about to find a piece of paper to try to map out what it might look like, or at least what the initial building blocks might be. This is still all very vague at the moment. But I’m wondering if the core of this is going to be some sort of journal recording what was done every day, with links to appointments and various activities. Not sure yet.

Apologies for the wall of text.

One general thought for your sketching: make a note of the outcomes you know you need. From that you can assess what inputs they need. Some will need to be calculated (that bit comes later) but those inputs will help indicate what source info you need to capture. So, some things might absolutely need dates or date/times or time durations (think: Interval tada type). The key point there is not all things (notes) need the same info collected. Even teasing out those strands is massively helpful. Not recording what you know you don’t need is a help to self. Iy’s all too easy to collect everything (implying the effort to do so) because we fell–for reasons never resolved—it is probably useful, and so we clog our process with scrap data.

Also consider what can be automated easily, but be aware of scope.Thus, an OnAdd can set a date/time for a new note, but if that isn’t the real time (or date) you need to record, pre-setting a likely incorrect date might be a reason to not automate in such a method. A stamp, manually applied is still a degree of automation. If you can’t predict when to might want to do a code-automated task, a stamp is actually more appropriate than a rule/edict/OnAdd. Knowing why we’ve automated rather than doing so because we can is a help in the longterm.

Also, keep notes-somewhere—on the design choices you are making and why. If you’re going to invest effort making a highly customised TBX, your future self will thank you for leaving a breadcrumb trail back to why a choice was made (and which in the future who’s outcome seems less good).

@mwra Thank you for those kind words of wisdom. I had not thought of the outcomes, and you are right. I have started making a list. Your observations about keeping a record of design decisions are particularly valuable, and I have also followed up on that by creating a note which links to this thread.

I was quite surprised at the number of outcomes I was able to jot down in a couple of minutes – though it should not really have been a surprise. But actually beginning the list brings home how much work there will be.

Thanks again.

I omitted to mention, re notes-to-self, that the Description box for user attributes is a real boon to ‘future self’. As I’ve recently been reminded in so old docs where I didn’t do this and where the purpose wasn’t obvious from the name.

Aside from a generic like MyDate3, using self-evident names like LastExportDate is again a help to future self. Once set -up you’re not going to type the name a lot, bit if it will be a Displayed Attributes, you will read it a lot so evident meaning is a boon. Note: you can rename user attributes, although Tinderbox can’t update the name if you’ve used it in code—that’s for us as the user to review/fix.

With booleans, I try to catch purpose and state with an Is... or Ha... start to the name. It also help is the name aligns with the state. Where the boolean ticked (true) state is counter to the default, i.e. the true state is a negative (this note doesn’t have this property) consider a name starting NotHas.. or NotIs.... IOW, the name describes the ticked/true state of the boolean attribute. Obvious after the fact of no doing so when naming attributes. :open_mouth:

The point about calculation coming later is you can’t calculate a result if any of the necessary inputs are missing. You can’t tell the duration of a meeting is you don’t know the start and finish times. This is true regardless of how that data is saved in Date, String, whatever attribute type. The latter can be converted, but you can’t (usually) back-fill ad hoc data you never thought to capture at the time. It needn’t be hard-edged stuff like dates, it might just be your state of mind at the time.

Aside from general things like $Tags storing discrete strands of data in discrete attributes is a win. Don’t worry about having more attributes (buy q.v. the point about self-evident names). ‘Saving’ an attribute and putting two stands of info into the same-named attribute—albeit in separate notes—is a false economy. If you’ve egregious numbers of attributes (a subjective call) it might be a hint you’ve over-abstracted your info. But, as said, that’s subjective so it isn’t as trite as “N attributes good, N+1 attributes bad”. also don’t overlook attribute suggested values, especially for attributes you’ll be aiming to update by editing Displayed Attributes. Picking a suggested value lessens the chance of an input error (especially for those of us who aren’t good typists).

There have been a few psychotherapist Tinderboxes, which a variety of approaches to notes. (My dad was an analyst. He stopped keeping notes after the Eagleton mess.)

Remember, there’s nothing wrong with using one of the admin-centered packages for admin, and using Tinderbox alongside. Even if this means adding a little extra data entry for the first few weeks, this would let you decide what works best where — and perhaps set up some automated workflows to save you the extra work.

Pinging @dominiquerenauld .

You said here:

« At the risk of reducing everything to a crude level, it seems that you use DEVONthink to collect things, TheBrain to connect things, and Tinderbox to analyse things. »

In my recent new experiences, it seems that Tinderbox is for me now what it does best in its field, but that I tended to minimize or ignore: analyse things (tags, dates, names, authors, references, keywords…).

When it comes to visualize datas and notes that have to be seen in a contiguity space or for their contiguities, it is incomparable.

If you just need to connect things between them and freely associate one to another, TheBrain is a very good tool and I’ve been using it recently alongside Tinderbox. That said, I think that an analyst, or a psychoanalyst has to be able to write down things as they come: memories, associations, thoughts and so on. In that perspective and in my experience — but if I write in the field of psychoanalytical researches in the sciences of education and training, I am not an analyst —, Tinderbox is really a box that presents some similarities with what analysts call psychism. If I had time, I’d love to write a paper about the way users tend to feel Tinderbox as a “second psychism”.

Curious, what is this reference too?

I am working with quite a few clients and am helping them organize the multi-dimensionality of their professional and personal lives (and companies) in, within, and alongside Tinderbox.

You are not wrong; Tinderbox can be central to your being successful with your efforts. Unlike commercial “admin-centered packages” that are built around a “proven” process or method to achieve a goal, Tinderbox is a toolset that lets you find your own path in your own way to achieve your goal. As Bacon told us, however, with great power comes great responsibility. If you are going to adopt the power of a tool like Tinderbox, you must also accept the responsibility to lead and guide Tinderbox down the path you wish it to take. In other words, you must be accountable for the input, the processing, and the output. Proper use of Tinderbox will pull off your veil; it will help you understand what you know and do not know. I find that it is this later point that stops people in their tracks with Tinderbox. They get frustrated and quit too soon; they fall back to the convenient, comforting, and conforming space of output software like MSFT Office, as this software does not challenge them to face their own knowledge, knowledge about stuff, process, computing, the world, etc.

In 1972, McGovern picked Sen. Thomas Eagleton (D-MO) as his running mate. It was soon revealed that Eagleton had suffered from bouts of depression; he was quickly forced out of the race.

One result was that lots of psychoanalysts got rid of their files, lest they serve as evidence against their clients.

1 Like

The BACP has a brief guide to record-keeping and the law, which is on my reading list: https://www.bacp.co.uk/bacp-journals/private-practice/summer-2017/record-keeping-and-the-law/

There are complications that may well influence how I design my Tinderbox file, if I decide to go that way. Advice we were given during training was to think about what would happen if our notes had to be submitted to a court (for example during an inquest into a death). Simple, factual bullet points are preferred by many for that reason (e.g. “She talked about her father”).

And thank you to everyone who has contributed so far. Plenty of good advice and suggestions. Plenty to think about, too!

I think I intuited that, and it is good to have it confirmed. It had occurred to me that it might be worth having an attribute that was ClientEmailAddress, for example, to keep those separate from colleagues’ email addresses for the purposes of confidentiality. Anything that can contribute to keeping clear boundaries is probably a good thing.

I have a lot more thinking to do.

1 Like

Very useful, as I didn’t know that suggested values existed.

As an observation, it might be useful if the page in aTbRef also said that suggested values should be entered one after another with semi-colons between them. I guessed at commas first, and when that didn’t work I tried semi-colons, which did. But I could have carried on guessing for quite a while if I had not had some acquaintance with the way Tinderbox often does things.

Yes, but aTbRef is written as a hypertext. It is assumed you’ll follow the links. Thus Suggest Attribute value lists points you to either System tab or User tab. Both of the latter pages, when describing suggested values explicitly mention use of a semi-colon delimited list. They both also link to article Pre-populating Displayed Attributes pop-up lists which again mentions the detail.

The above is by way of explanation and not rebuke. It’s also a polite reminder the links are there for a purpose. I deliberately don’t link every instance of use of a word like ‘list’ as otherwise articles get ‘over-link’ and hard to read due to large numbers of link anchors in the text. Not do I explain such concepts in full everywhere they occur, as in the past that proved to be a poor approach: change to a method or definition might easily not get updated(weren’t) updated leading to conflicting descriptions in different places.

I am interested as to what made you think Tinderbox value lists would use a comma delimiter, as in which articles/features?

‘list’ is a slippery term as it has 2, if not 3 meanings here:

  • generic: a collection of items, possibly in a specific order
  • a semi-colon delimited string, telling the Tinderbox parser this string is actually a list of discrete values (used by 3 multi-value data types: List, Set and dictionary)
    • note that a string with no internal semi-colons as also validly a single-item list!
  • a specific data type in Tinderbox: List.
    • note the data type name is not case-sensitive as Tinderbox itself uses uppercase and lower case without any discernible reason. For instance , the User attribute Inspector data-type pop-up lists the data types in lower case. However, aTbRef generally uses uppercase when referring to a specific data type to hint tat the fact. Referring to a ‘List’ vs. a ‘list’, the former is more evidently a reference to the Tinderbox ‘List’ or ‘list’ data type.

Given the unmaintainable weakness of the describe-everything-in-detail-in-every-context model (covered above), I’m open to suggestions. I could write more articles on how to use aTbRef (e.g the links are there to inform) … but would anyone read the article.

I apologise if the length of the reply reads as rebuke: that’s not my intent. I’m just trying to lay bare the problem from the author’s side and look for better (implementable) ways to serve the reader.

I guess an article I could add would be one addressing the bulleted list above, e.g. “What is a ‘list’ in Tinderbox?” If so, where best to put it? Under the section on action code or that on attributes? My hunch is the former is a more sensible place, or possibly under coding conventions. I’, open to ideas. :slight_smile:

†. Before the point is made that action and export code have multiple comma-delimited arguments, I’d note those aren’t lists as such, except in the most generic sense of the word. More pertinently, if you code an operator where the arguments are replaced by a list-type attribute reference (e.g. $MyList), it likely won’t work, i.e. the operator isn’t expecting the argument is Tinderbox list form.

1 Like

The key word here is “assumed”. :slightly_smiling_face:

You assumed I would follow the link (because you knew that the information I needed was there).
I assumed that the link would not lead to the information I wanted (because I assumed that the link dealt with something else).

Assumptions create a lot of problems in every sphere: Napoleon assumed that invading Russia would increase his authority … We know how that went! And having studied aviation accidents (I used to be a gliding instructor) it is noteworthy how often assumptions contribute to them.

Having some familiarity with cognitive psychology, I would say that unless information is right in front of a person’s face, there is a good chance that they will not discover it – out of sight, out of mind. And even if it IS in front of their face, they may well not see it (see inattentional blindness and the invisible gorilla).

This is not very encouraging for the poor author, who is faced with the insurmountable problem of the limitations of human cognition and the operations of the human mind. However, I wonder if there is something to be learned from the way documentation is approached in the field of aviation. They know from experience that if things are overlooked, people may die, and that assuming something is risky.

Anyway, I’m afraid I don’t have any easy solutions. I know what you are trying to do is difficult. But we all have to keep a watch on the assumptions we are making.

It was just a guess – the first thing I tried. I have been using Obsidian a lot over the past few months while I have hardly opened Tinderbox in the past couple of years. I use the application so rarely that I always have to re-learn the basics when I come back to it. And as normal, one uses one’s previous experience of other applications (assumptions again) as the basis for approaching an application with which you are not too familiar. So commas was at least a decent guess, after which I dredged up a vague memory/guess that Tinderbox might prefer semi-colons. But as you know, there are all sorts of possibilities out there, from carriage returns to tabs to … ???

Thanks for all the help. You make a lot of things possible that would not be if you did not put in the time and care.

1 Like

Thanks. Surfacing assumptions, both own and others is hard. I guess my challenge is to communicate that the links in articles aren’t just for decoration but are the very means to explore’s one’s problem. I’ll think on that.

As it happens, I’ve real-world experience writing just such a sort of documentation. I can say the latter approach wouldn’t help here, because the nature of the two tasks are very different. In life-and-death contexts with minimal decision time, effort goes into providing minimum ambiguity/complexity of description. Much effort and consideration also goes into deciding what doesn’t belong. Here, it is is the reverse, extremely open-ended. Still, writing aTbRef is definitely the less less stressful task as Tinderbox users will survive to write in if the description is wrong. :slight_smile:

1 Like

At times I still have the experience of reading a book in which it says: “See also pages 34, 55, and 102” which leads to the classic three fingers inserted in various places in the book while trying to use the other hand for something useful.

Hyperlinks, I find, are the digital equivalent of this, and frequently lead to me losing track of where I started and what I was looking for. For me, at least, they can be part of the problem, not part of the solution. But maybe I’m unusual – my analyst would say so. However, that is one of the reasons why I am reluctant to follow hyperlinks unless I can be fairly sure they will get me what I want. Sadly, I have had too many experiences of following hyperlinks which are no help at all, and present you with the question “Was this helpful?” Once again, one should not necessarily transfer one’s experiences in one domain to another – but they are often there in the background influencing one’s behaviour. As I know from the work I do … :slightly_smiling_face:

Out of curiosity, how do you suggest one addresses this? We live ina. 2d/3d world, not a quantum state. We can’t put all the information in one place all the time?

Opportunity for key learning point. @eastgate does a really good job of adopting common and generally accepted standards and norms in Tinderbox. It is quote common to use a semicolon to separate list items, especially, when considering the context, a common might be present in an individual list item.

Note, in TBX, if ou link one note to another, you can use the link pane to pull up a popup window of a linked note so that you can read the content a linked note without leaving your context. I’ve reviewed this several times in my videos.