Joel,

Yes, I'm doing that now.

I have a TB document called "Environment" and at root level "Work" and "Relationships". I put all my contacts in Relationships and all my notes in Work. Any notes from meetings go into the text part of the person. Any notes on material that was suggested by a person is linked to that person.

So far, I have built a fairly substantial map of all my contacts and can see who the nodes are, who has made referrals that have become clients, at which events I met them and so forth. On all contacts I have two attributes, LastContact and NextContact where NextContact is LastContact plus 3 months. I have an agent that checks for NextContact = today and that's my daily follow-up list. I have another that checks for NextContact < today  and that's my overdue list.

It is evolving but I think that I've found the tool (TB) that I've been looking for since about 1997!

Stephen

I realise how unsettling it can be to ask what one feels is a normal question and get no reply. However, I suspect the reason for a lack of response isn't unwillingness to share but rather the fact that the topic is very broad; indeed the scope of "everything" will doubtless differ in implied meaning from reader to reader. Why not make the question a bit less diffuse? Perhaps that might help engender more discussion. For my part, I don't do the 'everything bucket' approach so can't comment specifically on the original idea.

You are correct in saying that TB doesn't search outside the current file, so the wider you want your search, the fewer documents you'll want to use. In latter context, a tip is put discrete silos of data in separate parts of the documents - i.e. descended from different containers. If you're trying to make an agent to search for 'to do' items it's useful to be able to start by only considering 'to do' items rather than address info or notes on your collection of Mayan artefacts. You can still search more widely but you probably only want to do that on a deliberate basis, so as not to load the agent cycle time.

~~~~~~~~

Whether an app is 'crashy' is in the eye - or rather user experience - of the beholder, but I don't think it is overall a fair description of Tinderbox's stability. Referencing August 2010 implies you were/are likely using an early version of v5 where some Unicode issues related to the new *v5.0) text engine were being flushed out. The app is currently at v5.7.1 - have you tried the recent version. It's hard to guess your 'more reliable' criterion as met, given the cause of the previous errors isn't described. Did you contact support back when you had the original problem?

Sounds as though you did all the right things at the time - sorry it was without resolution. Besides a number of Unicode issues, some glitches caused by importing from other sources have been fixed since early v5.0 so I hope you fare better with the current version and get the stability others are experiencing.

When I discovered TB I realised I could do most things just using TB. I created one tbx with everything in it and that did have some advantages. However, being new I discovered one doc for all is not good.

Why? The simple answer was agents. The bigger to document the more agents and queries you run, the greater the liklihood that something you haven't thought of or forgotten will mess up something else. I ran an agent that replaced all my notes data with something else, but it applied that to the whole document, which I never intended! This was hard to retrieve and I can hear you all screaming backup!

I now use separate tbxs for different things. I may have a number of tbx documents open and using colour makes it easy to differentiate what's what.

I now don't have all my eggs in one basket!

Mark Anderson's tips are of course always wise. But I have evolved toward a modular system like yours, rather than the One Big Unified-File Theory approach, for similar reasons:

>>I now use separate tbxs for different things. I may have a number of tbx documents open and using colour makes it easy to differentiate what's what.<<

It takes practically no time or effort to keep separate files running, and I avoid unforeseen collateral effects of rules, agents, formats, etc leaking from one area to another.  

Hi! It's funny that this topic is one of the more recent ones, since I had exactly the same question myself today: Should I keep everything in a single tbx file or in separate ones?

Actually, I had ordered the tutorials yesterday and only thereby realized that one can also link to tbx files and that it could also be nice to have some smaller files rather than a single big one.

What I have experienced so far is that with a single big file, almost everything somehow ends up by becoming a container. At least for me, that's often the most easiest and fastest way to associate information with each other. However, such containers lead to three problems for me:

1) The hierarchy of containers can easily become very deep, and I'm often getting entirely lost in the outline or also map view.

2) Since it is not possible to change the shape of a container in the current version of Tinderbox, at least as far as I know, I lose a useful way to distinguish between different types of information. For example, in the tutorials, persons are sometimes represented by certain types of shapes and I like that very much. Now if I want to add some further information about that person, I'd usually attach it one level below in the outline view, making the person a container. But then the shape is lost!

3) I often need different and specially arranged views for different types of information. When opening some examples and demos on the tutorials CD, I liked it very much that such views - like, for instance, ReadMe files - are automatically opened together with the file. That's another reason why I'm thinking about separate files.

But of course, the disadvantage of using separate files is the missing search functionality and the ability to use agents across different topics. For example, when I'm at that aforementioned person, an idea for a todo related to that person might occur to me. I'd like to attach it directly to the person and let an agent gather all my todos instead of having to enter the todo manually in a separate tbx file.

However, I don't know any solution for this dilemma, apart from implementing a search engine and agents that can also search across tbx documents.