Tinderbox User-to-User Forum (for formal tech support please email: info@eastgate.com)
Tinderbox Users >> Documentation and Tutorials >> So, umm..., what is this app actually for?

Message started by Richard Pfeiffer on Jun 22nd, 2011, 8:28pm

Title: So, umm..., what is this app actually for?
Post by Richard Pfeiffer on Jun 22nd, 2011, 8:28pm

I took the plunge a few weeks ago.

I had first heard about Tinderbox through a special offer for Scrivener users last year. When the offer was repeated last month, I immediately bought Tinderbox, Twig, and the hardcover edition of The Tinderbox Way.

After downloading the software, I jumped into the forums and stumbled upon the thread titled "How do I get started with this app?" in the Questions and Answers forum. That was my question, too! And I applaud the earnestness with which the Marks (B. and A.) and others were answering the question, but now that I have been using Tinderbox for a few weeks, I wanted to take a stab at some of the communication problems I have noticed when people who are experienced with the app try to explain it to those who haven't used it.

You all are very good at telling people how to perform specific functions. Of that there is little doubt! But I feel that your efforts to explain the big picture often wind up leaving it cloudy.

I make my living as a technical writer for a software company. I am also a philosophy student. I would like to bring to bear my experience in both fields to discuss the most basic question of all about this application: What is it for?

One distinction that I would like to bring into this comes from the software marketing lore of at least a couple of decades ago: Explain your software based on its benefits—not its features. You say that:

"Tinderbox is a personal content management assistant."

That is a feature. I would suggest focusing on the benefits, which for me are something more like this:

"Tinderbox is a personal thinking and planning tool that helps you develop, discover, and remember relationships among complex arrays of information."

Another way of looking at this is to say that you are not necessarily speaking at the right level of abstraction in your efforts to answer the general questions about what Tinderbox is and what it does. This is harder to pin down, but on some level, I believe that you have created an application that can handle radical complexity in an unprecedented way. Unfortunately, in order to explain that clearly to people, your knowledge of the app now has to be integrated, taking a leap into radical simplicity. You need to reconceptualize your understanding of the app—which, on some level, may actually be harder than it was to write the app.

As a way to promote some discussion of this issue, I would like to make an analogy to the object-oriented software principle of coding to an interface as opposed to coding to an implementation. For example, if I have a Door interface that has an Open method, I will try to use that method whenever I try to Open the GarageDoor or the BackDoor, rather than using the native Open methods of these specific implementations of Door. That gives me a lot more flexibility.

Similarly, when describing what Tinderbox offers, and how it works, if you can try to create higher-level abstractions, it will allow you to answer people's questions in a way that has so far often eluded you.

Tinderbox is big (huge!!!) on implementation! I have never seen software that has such great potential to fulfill my dreams! But I hope you will reach even higher towards the sky as you continue to bring new users into your community!

Title: Re: So, umm..., what is this app actually for?
Post by Martin Boycott-Brown on Jun 23rd, 2011, 6:04am

I agree -- I said something like some of this on an earlier thread


though what you say here goes deeper and further. I'm a psychologist, and I've also noted the difficulty of bridging the gap between the experts and the novices -- a fairly common problem. In my view, the statement "Tinderbox is a personal content management assistant" actually obscures what the product does (or can do). It is a statement of technical capability which might mean something to a programmer, but it has no meaning at all -- or rather, it means too many things -- to a potential user. My psychoanalyst might also be described as a "personal content management assistant" because he helps me understand my thoughts and emotions. I would make any "first statement" about the program even more bald -- Tinderbox helps you to see links between bits of information. I feel that that is the basic idea that one needs to have when starting out with the program. Everything else can come later.

I look forward to howls of protest, and rebuttals saying that I have sold the program short! I know I have, but the novice needs a simple place to start, a basic idea from which they can build their relationship with the program.

Best wishes, Martin.

Title: Re: So, umm..., what is this app actually for?
Post by Lucas D on Jun 23rd, 2011, 10:24am

Tinderbox helps you to see links between bits of information. I feel that that is the basic idea that one needs to have when starting out with the program. Everything else can come later.

I guess it all depends on the individual. For me, as a grad student in anthropology, "Tinderbox: The Tool for Notes" was the operative phrase---that is, the first stage for me is simply writing notes without any particular thought to seeing links between bits of information. I write all my notes in Tinderbox, whether ideas, reading notes, field notes, tasks, or whatever. At this stage, I make ample use of agents for organizing  and searching my notes (in a practical sense), but most of the analytics and relationship stuff can come later.

Title: Re: So, umm..., what is this app actually for?
Post by Martin Boycott-Brown on Jun 23rd, 2011, 11:21am

I would certainly agree that a lot depends on the individual, but I'd be very surprised if "Tinderbox, the tool for notes" attracted many people to the program. In my lifetime, for taking notes, I have used MS Word, Stickies, XPad, TextEdit, SimpleText, Notational Velocity, Evernote, Scrivener, Nisus Writer Pro, Circus Ponies NoteBook, EagleFiler, Devonthink Pro, OmniOutliner, MyMind, MindNode and probably several others that I can't remember at this moment. If anyone had ever suggested to me that I should buy a program costing $250 for the purpose of taking notes, I would have thought they were barking! In fact, I suspect that the phrase "the tool for notes" is actually another reason why a lot of novice users don't really understand Tinderbox. Looked at from the novice's point of view, what is so special about a program for taking notes? There are hundreds of them, and some of them are free, and do a very good job, too. What distinguishes Tinderbox, and makes it worth investigating, in my view, is not the fact that it takes notes, but that it has special tools for showing relationships between the bits of information. Otherwise, why would we use it instead of TextEdit?

Cheers, Martin.

PS: I hope that doesn't come across as a rant: re-reading it, it seems a bit forthright! I hate it when there are no visual cues in communication. Imagine the above as being written wearing a red plastic nose.

Title: Re: So, umm..., what is this app actually for?
Post by Lucas D on Jun 23rd, 2011, 11:39am

Yes, from a marketing perspective you're probably right. As for me, I've tried all those apps as well (except XPad) and scores of others, and what I wanted was something that allowed outlining (hierarchical organization of my notes) as well as unlimited metadata for individual notes and options for organizing according to metadata. Nothing else comes close (with the possible exception of InfoQube on Windows). I also agree that visualizing relationships is a key/core feature. All I meant to say is that from a "getting started" perspective (as opposed to a marketing perspective) it may not be necessary to get into "relationships/links mode" right away --- TB can also start out as simply a writing tool---albeit an unusually powerful one.

Title: Re: So, umm..., what is this app actually for?
Post by russ lipton on Jun 23rd, 2011, 11:43am

@Richard:  I have never seen software that has such great potential to fulfill my dreams!


Your answer might (or might not) lead to surprising insights relative to the challenge you have posed, but even your own proposed TbX description seems dry as dust relative to this enthusiastic declaration ...

Title: Re: So, umm..., what is this app actually for?
Post by Martin Boycott-Brown on Jun 23rd, 2011, 12:20pm


Yes, I absolutely agree -- but I think the important point that Richard was trying to make in the first post was that a significant number of novice users don't "get" Tinderbox, and end up floundering, and the expert users have trouble helping them. I am one of those (there seem to be a few of us) who have been "lured" to Tinderbox by enthusiastic users on the Scrivener forums, and then found ourselves rather at sea. The title of Richard's post is "what is this app actually for?" There is evidently a gap in understanding between the expert and the novice user -- not merely regarding technical details, but also "philosophy" or intention behind the app, and also its potentialities --  and I'm sure it would be beneficial to Tinderbox if something could be done to close the gap.

Yours, Martin.

Title: Re: So, umm..., what is this app actually for?
Post by Lucas D on Jun 23rd, 2011, 12:58pm

Martin, I think you (and Richard) summarize the situation well. Off the top of my head: Perhaps the solution is to emphasize, say, three main use categories that correspond, in Richard's terms, to three main benefits. A compromise between the overly abstract "it does everything", on the one hand, and the possibly too narrow boiled-down-to-one-core-function approach, on the other. But I probably haven't given this as much thought as many others here.

Title: Re: So, umm..., what is this app actually for?
Post by Stacey Mason on Jun 23rd, 2011, 3:49pm

This is actually a difficult question, and marketing is not as obvious at it might seem. We've given this a lot of thought.

The problems that people sometimes have when getting "lost" in Tinderbox seems to come from the fact that Tinderbox is an open-ended tool; everyone's uses and needs are different.  This, more than anything else, is in my opinion Tinderbox's greatest strength, but it is also the most difficult thing to explain to people.  This is also why the easiest way to "teach" Tinderbox to people is to get an idea of the specific work they want to do with the program, and work on solutions from there.

I don't think it's fair to say that the expert users have difficulty helping the novice users "get" the program. Tinderbox Weekend events have been very successful on this front, as is email and phone support.  It is, however, difficult to explain to someone (particularly someone unfamiliar with the program's features) what they "should" use the program for, especially with no context of what kinds of work they're doing and what they're hoping to get out of the program.  

Speaking only for myself, there are so many ways to use Tinderbox, that even the "experts" are regularly surprised by clever applications or uses that we've never seen.  Yes, you can do more than just "take notes" in Tinderbox.  You can analyze, develop, discover, remember, and manage relationships.  But this doesn't take into account the people that use Tinderbox for tracking, updating, generating, planning, or reminding and who don't take notes or analyze relationships at all.  Now we find ourselves with so many verbs that marketing copy would be awkward to say the least! By the time you step back to verbs that incorporate all the things Tinderbox CAN do, you find that you're at a level of abstraction that's not helpful to anyone.

There really is a delicate balance, and we will never be able to capture what everyone is doing with the program in our marketing.  We are, however, aware that there is a perceived gap in understanding between "experts" and "novices," and are working on different approaches and tutorial methods to help with that.  Unlike other programs there is no "right" way to use Tinderbox, so prescribing one "right" marketing approach is difficult.

Title: Re: So, umm..., what is this app actually for?
Post by Pierre von Kaenel on Jun 23rd, 2011, 8:18pm

Stacey,  your response is no different than others from The Company. Not much help to novices, and that is the issue brought up by the OP.

I teach program design, as well as most levels of our CS curriculum, and a programming language is not introduced as a program that can be used for processing data and asking students how they would like to use it. In parallel, we introduce the features and commands of the language while exploring case studies (micro and macro) of applications of the "program" to specific problems.

Maybe comparing TB to a programming language is not comparable, so how about a spreadsheet?  Shortly after buying an IBM PC-1, I was informed of a new app named Lotus 123 that was about to come out. I was not too knowledgeable of spreadsheets and couldn't see the connection to graphics (charts, etc.) and a database. Years later, when spreadsheets were the fashion in intro college CS courses, we introduced them much like programming languages. We studied modules of features and applications. We could have described them as rows and columns of numbers and labels with summation and average cells thrown in, but the with calculation cells that included logical and other advanced functions, we truly needed to introduce case studies in order for our students to understand what spreadsheets could do.  Sample applications did not limit them; they could extend these case studies to new problem domains - that's really what our goal is.

Eastgate seems to think that when a demo application of the program is revealed, users will think that's what TB is designed for. This is where I disagree.  

Title: Re: So, umm..., what is this app actually for?
Post by Ben Worthington on Jun 24th, 2011, 6:23am

This is an interesting discussion.  

My sympthies are very much with Eastgate on this one.   Time and again on software sites you come across individuals (and I certainly don't mean to sugest the OP falls into this category) who are compulsive buyers of software but appear to have no real use case; they just like to play with stuff.  Then, when they buy the software and it doesn't work exactly like omni outliner does they complain that it's not user friendly or is missing features or whatever.  But often the problem seems to me that that they didn't think about whether or not they actually needed the software in the first place. Every single app on my Mac is there because I have some real need for it.  Nothing is there because 'it might be useful but I havent figured out what I want to do with it".    

Certainly I agree that the onus is on the software developer to explain how the software works, and there is a stack of this kind of information available for Tinderbox and an extremely responsive developer.  But it's surely for the user to define what they want to do with the software?  Take my use of Tindebox.  I am a construction lawyer. I have particular (idiosyncratic) needs related to the management of legal know-how that are shaped by my interests, my practice, my clients, my ways of working.  It's quite possible (likely, in fact) that nobody else has these exact needs, not even another construction lawyer! Is it reasonable for me to expect Eastgate to know what these needs are and to explain them to me?  I dont think so, and I don't expect to find that kind of information at Eastgate or anywhere else because no one can understand my needs better than I can (although I bet Mark and Stacey would have some good ideas if I were to drop them an email).

I'll go a bit further and say that whenever developers do try and tell me what I might use their software for, I find it unhelpful.  Check out the videos for omni focus.  Is there really anybody out there using omni focus to organise how they tidy their garage?  Take a look at some examples on Screen Casts Online - the usage examples are just silly, trivial.    

I also think the learning curve issue with Tinderbox is somewhat overplayed.  Yes, there are aspects of Tinderbox that are complicated but do you really need to understand them all?  At its heart, its acually pretty basic;  if you can hit enter, you can make a note in Tinderbox.  If you can click and drag, you can make a link.  If you are familiar with databases or columns in a spreadsheet, attributes shouldnt vex you too much.  

The OP asks "what is this software for?"  In my view, the real question is "what do you need the software for"?  If you can answer that, you are over half way there.  


Title: Re: So, umm..., what is this app actually for?
Post by Stacey Mason on Jun 24th, 2011, 3:38pm

Eastgate seems to think that when a demo application of the program is revealed, users will think that's what TB is designed for. This is where I disagree.

Actually, we agree that offering demo applications is very helpful! This is usually the approach we take with our Tinderbox Weekend events. We frequently present case studies and explain how and why the example uses certain features to achieve specific goals. We take a similar approach for the tutorial CDs. In fact, we have a new tutorial volume currently in pre-release that will be available as soon as we get some Web site issues smoothed (probably early next week).

Here are some additional resources on this front in the meantime:
  • Tinderbox at work series
  • Many of the screencasts are use cases in disguise
  • Mark Bernstein's blog is very good about linking to real people sharing details of how they use Tinderbox on their own weblogs
  • At the bottom of the Tinderbox home page, there is a category of case studies called "Using Tinderbox"
  • And I'll update this with a link to the new tutorial series as soon as it's up and running

Title: Re: So, umm..., what is this app actually for?
Post by Mark Anderson on Jun 24th, 2011, 5:30pm

...when a demo application of the program is revealed, users will think that's what TB is designed for.

Well, experience shows the above assertion is actually - if inconveniently - all too true. Many, though certainly not all, users unfortunately do measure a demo topic very precisely against it's relevance to their intended use. Why? Either (a) because we expect to be told how to use the app or (b) because we simply assume the app is always used for our [insert topic] purpose. If TB did just one thing, e.g. like Scrivener is for writing, then it's far more understandable to assume that all demos to be 'relevant' to (most) users of the app. The reality is otherwise. Some Scrivener users might use TB, but not all TB users are Scriveners, and so on for other apps and areas of interest.

Another factor that, I think, underlies angst over demos is some of us like to feel we totally understand our tools before we use them. Indeed, I'd admit to the latter, but for all I've learnt about TB's mechanics I'm aware I'm still scratching the surface of what TB can do. I've learned that sometimes it helps to not try to understand everything before you begin. It's an ironic to see folk using an app that - atypically - doesn't ask us to understand everything before we begin and then ask exactly how to use it despite our not yet understanding our own problem's requirements. When suggesting people 'just dive in', it's well meant - not just an excuse. Experience here in the forum shows all too often people's initial analytical process isn't best structured in the way they initially assumed, but happily resources like the forum can help with that. Bottom line: don't feel embarrassed to ask questions - those who aren't seem to get most traction.

Separately, patient assistance of users here (and previously in the wiki) has taught me that many of those using TB don't understand software/coding - nor desire to - so models of abstraction or object orientation only add to their sense of confusion. Abstraction is great for the Computer Science grads but tends to be lost on on the rest of us.

Eastgate are a small company. Time spent arguing this sort of angels/pinheads topic simply steals from real development work providing the enhancements we all write in about. So, if you're poised, pitchfork in hand, why not put it down and think how you might help, by perhaps looking at your own research and offering up some data that might offer the bones of a demo? I stand by my offer that if a user is willing to offer up a body of real world info as the basis of a demo, I'm happy to help obfuscate data (if/as necessary) to form the basis of worked scenarios and to work on demos based on it. So, who's first up?  :)

Title: Re: So, umm..., what is this app actually for?
Post by russ lipton on Jun 24th, 2011, 8:59pm

I think this thread is not exhausted quite, at least for me. Warning: Friday afternoon verbiage lies ahead ...

First, not a few folks who have invested in the software clearly experience a need and need 'support', if only to to be encouraged not to 'worry'. Kudos to staff for being patient.

Second, though a long-time user, I have gained a small, but vital point of clarification myself, namely, that there is a difference between the 'what is it used for?' question and the 'how do I climb the learning curve?' question - admitting some overlap.

As was pointed out, Eastgate is aware of the apparent leap required to move from novice to intermediate and working on it. Neat.

On the former point, I see TbX as a toolbox for exploratory problem solving in situations where a formal application/solution is not available or, perhaps, suitable. In other words, if it can be solved in another piece of software designed specifically for that domain, go for it elsewhere. Alternatively, use TbX to get far enough to use the 'other' app effectively and/or as data input to that application. Use TbX when you can't avoid it is my point - and no shame in that.

Not everything requires or benefits from out-of-the-box exploration (thank goodness, or we would never get anything done). OTOH, some of the most rewarding study, learning, discovery and subsequent formalization demands exploratory work. MB emphasizes in his book that TbX rewards the deferral of formalizing 'x' method or approach until it is truly needed. Quite so.  Our culture is biased against admitting the necessity (read: the joy) of learning tools which don't treat us as children or slaves and we are suffering greatly as a result.

TbX demos are useful precisely because they cover such a ridiculously broad set of domains. Sensible users 'get it' that TbX isn't for just 'this' or 'that' - so I don't worry about this leading to misharacterization of the toolbox.

To me, a thread like this is (or could be) most useful if we pushed the discussion itself outside-of-the-box a bit. To wit:

.....why did the original poster say that TbX looked like it could meet his wildest dreams? We don't usually speak this way about software (or I hope we don't)! So, please, what dream are you talking about that, remarkably, this product might allow you to achieve? I argue that the answer to your own question might be found by pursuing that line of thought ...

... and Mark A (of all people) claims that even he hasn't 'scratched the surface' of TbX. I'm not sure if that is depressing or exhilerating. What the heck does that mean (serious question)? We don't usually say this about Word or PHP or even reasonably cool software products. Mark, what do you see 'below the surface' at your level of expertise that remains to be mastered or that could be put to use for you to do ....what?

Bottom line, "the application that can be described is not the application". I think that is a Zen thing? Seriously, that TbX can't be put neatly into a box doesn't mean nothing can be said about its target usage, but emphasizes rather that its architecture matches (as it should) its core use case: exploratory problem-solving for out-of-the-box requirements across a wide set of end-point domains (education, law, business, writing/publishing, religion, daybooks, cooking, movies, fantasy baseball, etc).

Other applications should be so lucky as to have an issue like that ....  :)

Title: Re: So, umm..., what is this app actually for?
Post by Matt Cawood on Jun 25th, 2011, 1:44am

Separately, patient assistance of users here (and previously in the wiki) has taught me that many of those using TB don't understand software/coding - nor desire to - so models of abstraction or object orientation only add to their sense of confusion. Abstraction is great for the Computer Science grads but tends to be lost on on the rest of us.

That would be me.

I get the open-endedness of Tinderbox. Where I hit the wall is on the amount of friction I encounter when I go beyond basic queries or exports. The little learning I do to get through that resistance is often lost by the time, weeks or months later, I attempt to do the same thing again.

Ben Worthington may have got me en passant: my need of Tinderbox may not be imperative enough to force me to do the necessary learning. I love building a system of notes tailor-made for my needs, but I want to understand the tools I use to do that right out of the box.

Why shouldn't I sit down and really learn how to drive Tinderbox? I think part of the reason is that abstraction that Mark A. mentioned. I'm not good with abstraction. Perversely, I partly engage with Tinderbox because I want to minimise my time in front of the computer and get out into the physical world of our garden or farm, or my workshop, where there are a great variety of physical tools that I have no trouble understanding.

My turbulent relationship with Tinderbox doesn't need more demos or explanations. It needs less of the abstract, more of the visual, perhaps in the form of a more visual query builder or export template builder. Maybe it needs skeumorphic design elements, like a notebook metaphor ...

I jest - I see Mark B. shuddering at the thought. But unlike Mark B., I have no history in computer languages or hypertext. I'm firmly aligned with the physical world of objects, and I suspect a lot of those who try and fail with Tinderbox are too.

- Matt

Title: Re: So, umm..., what is this app actually for?
Post by Richard Pfeiffer on Jun 25th, 2011, 2:40am

Here's what I like about Tinderbox: It helps me think. And plan. And remember.

Because it lets me see how things fit together.

Spread the word.

Title: Re: So, umm..., what is this app actually for?
Post by Mark Anderson on Jun 26th, 2011, 3:25pm

Lest my last sounded glass-half-empty, not long after I posted an email arrived from a forum member with some of his own data. I'm now figuring how to make worked example - or rather what example to work from it, but the key thing is it's real data and I'm truly appreciative of the gift.

Title: Re: So, umm..., what is this app actually for?
Post by Roger C. Eddy on Jun 27th, 2011, 1:13pm

Sample “Project” - “A Remedy for Errors”

I am cautiously volunteering the examples here as Mark A. seems frustrated in that it is tough to get real life samples to work with. Please do NOT distribute these beyond the Tinderbox community and treat them with respect as you would wish to be treated if you were the doctor, nurse or patient described. I have included a sample from retail business as well. Any comments about tinderbox in action or the project itself are welcome, if you want to send a private message <nitelogger@me.com>t

The sample files can be downloaded from my Dropbox account public folder:      <
The outline from CT lab summarizes data about medical error.

There are two tinderbox files:


A .jpeg of a tinderbox map of “user experience”:
User experience v2 part1.jpg 783×650 pixels

A keynote presentation used with medical residents that shows how the material is introduced to health care professionals.


A Field Guide to Human Error with light hearted tone to soften up resistance to thinking about human error.


About myself - I am a 76 year old psychiatrist/psychoanalyst/medical educator retiring this year after about fifty years of practice including government and community consultation. Over the past ten years I have been part of a four person group working as a scientific hobby on the problem of medical error and patient safety. This has been a part time, uncompensated (to say the least) effort and independent of our professional and academic positions and obligations.

About the problem -

The problems are complex, overdetermined, interdisciplinary and extremely resistant to change and correction due to many deeply embedded “resistances” at all levels of activity, politics, professional egos, disagreements within and between professional and other groups and on and on.

The medical error situation  briefly summarized would be a death rate equal to two jet crashes per day, or a 6% probability of a problem causing significant disability per day of hospitalization. Over the past ten years millions of dollars in studies and grants have been spent on research and attempted correction. Improvements have been moderate at best. Studies have been replicated in other countries and using both retrospective and prospective studies. However the results are only reluctantly accepted and progress is slow.


In working in this area we found there were two main questions that came up repeatedly.

Why do people keep repeating actions that do not achieve the desired result and resist suggestions for change?

Why do organizations hire consultants and engage in extensive efforts at self-observation only to ignore or defeat the recommendations they obtain?

Then there is the problem of how do we put what we learn into our knowledge base(TBX helpful here) and into useful, practical action items for the user or the organization seeking consultation.


Our group has developed three “tools” that have been used in training and teaching various groups. I am the only physician the other colleagues having backgrounds in political science, administration and writing. We have been effective in working with small groups of colleagues or students. Difficulties almost immediately arise about trust, confidentiality and legal and malpractice issues. These are not easily addressed. Our deliberate focus has been on what could the individual, patient, practitioner, do to reduce the probability of being a victim of a medical error. What can be done practically “in the trenches” to improve quality of care or practice? (There are many other very well funded efforts at the organizational, systemic level, some of which work.)

Our tools have been designed to be used at different levels of cooperation and sophistication, from the novice to the expert:

OOOPSADAISY - write a brief description on a file card, like “Hipster” and reflect on it.

Narrative reports - select significant incidents and append a discussion. At a more advanced level be prepared to share the incident with a buddy.

Complex Context Critical Incident Report (CCCIR) a narrative, a discussion, some key words, three points of view, organizational, interpersonal-communicative, and individual, a report of feelings, action items, references to “the literature” or any other media that help understand the experience.

Users who have applied the tools have generally found them useful.

Description of TBX documents continued in following post due to character limit.

Title: Re: So, umm..., what is this app actually for?
Post by Roger C. Eddy on Jun 27th, 2011, 1:16pm

The  TBX documents/maps are:

Uses of narrative. This map is an attempt to show new users that the tools are derived from a background of humanities, the clinical world, and science (on the right of the map) and from examples in the day to day work world (on the left of the map). Many other inputs on the right could be added these are just samples. Many more incident narratives and CCCIR’s could be added on the left. THEN searches with agents, and development of categories could be derived as emerging data. In other words this is preliminary definitely not final.

Question One
Could something like this serve as a framework for a naive internet user who downloads a trial version of Tinderbox and uses this as a suggestive outline for their own personal data base of clinical practice. E.g. who would they put on the right as their intellectual sample inputs? What would they develop as their own narratives of experience, excellence, mistakes, exemplars?

Question Two
Suggestions of other ways of organizing or explaining would be welcome either here or e-mail me at nitelogger@me.com with ARFE in the subject line.

User Experience This is a .jpeg from Skitch as a copy of a TBX map. It is an attempt to get my mind around a “user experience” with these tools, what they could or would be used for. Again the attempt is to develop something that can be localized rather than one size fits all. (Conceptually this seems parallel to the approach of Eastgate, there is exactly the same problem that if you say exactly how to use it you are probably overlooking local conditions in application). The results will be better if the user is stimulated to reflectively think about what they are trying to accomplish, our tools can only facilitate but not direct the solutions.

Novice to expert theory. This is just an attempt to outline the points of the theory for users who have never heard of it. This theory has been widely applied in nursing in the pioneering work of Patricia Benner.

My apologies for the length of introduction but this is a complex, multidisciplinary, subject explain.

Title: Re: So, umm..., what is this app actually for?
Post by russ lipton on Jun 27th, 2011, 1:54pm

@Roger Eddy: so generous; thank you from this user.

At the risk of seeming obvious (trivial), TbX could be described with a high degree of precision as a single-user content management system (CMS). It misses some check-off boxes (primarily greater hospitality towards data types like image, video, etc), but fills some boxes not even envisioned yet by other CMS tools (views).

For starters, TbX does a near-ideal job of providing an agnostic storage system (XML) and clean separation between content (notes) and presentation (templates). This is the architectural base for any CMS, yet many are surprisingly proprietary in actual implementation. I could go on ... and on.

Eastgate might do worse than complement their current product presentation with a flat-out CMS story. Not only would this tend to further justify the price tag, but it offers an authentic point-of-contact for many prospective users to 'get their mind' around TbX.

Bonus: CMS tools want to enable cross-domain applications, so no need to explain TbX on that score ... the image below is supplied strictly for fun.

Title: Re: So, umm..., what is this app actually for?
Post by Mark Anderson on Jun 27th, 2011, 2:24pm

Thanks everyone. Roger, I tried fixing the above links for you but most don't work. Based in the one that did (the Keynote), I as able to retrieve all bar the last PDf you mention via these URLs:


I figured this should work but it doesn't seem to:

Requests re circumspection re further circulation noted. I appreciate all this. No, really!

Title: Re: So, umm..., what is this app actually for?
Post by Roger C. Eddy on Jun 27th, 2011, 2:51pm

doe frustration.
I first tried to use my iDisk for file transfer but it seems to have been diddled in advance of the CLOUD.
tI then thought I folllowed the sharing instructions on Dropbox but it does not seem to have worked.

I tried to look up Mark A.'s e-mail but don't find it.  If Mark A. will send me a message at nitelogger@me.com I will mail him the attachments and let him put them up on the board. Sorry folks this makes it look like an extended tease or over concealment on my part but it is just unfamiliarity with how to hook up attachments on the BB and brain spasms.

Coming soon. The real stuff.


Title: Re: So, umm..., what is this app actually for?
Post by Mark Anderson on Jun 27th, 2011, 3:00pm

Roger, email sent.

Title: Re: So, umm..., what is this app actually for?
Post by Lew Friedland on Jul 23rd, 2011, 12:36pm

Can't help jumping in here, a bit late.
I've used TBX since version 1.0 (actually used both StorySpace and the Squirrel before that).  I'm one of those people who almost instantly recognized the potential of TBX in my work, but, even though I am not a newbie, I still occupy that liminal category between newbie and intermediate user.  Actually, that's a long time to have been sitting in that space.

Like others, I want to make clear from the start that I've never used any program (or much else for that matter) that has as responsive a developer as Mark B, and as helpful community leader as Mark A. Have never, that I remember, waited a single day for help with an issue. So the question for me, like most, is not getting help with technical specifics.

I am a professor, writer of books and articles. Just in the interest of building real life cases, I am in sociology and communication. I work on a number of topics, probably 7 at any give time. Some of these become articles, others parts of books (or both) and others simply fade over time.  Partly as a result of this method, I have (just counted) 71 separate TBX files. Probably 15-20 have started with an idea that then faded (maybe 50 notes).  Some of those overlap with other later ideas (so I have multiple files related to "civic" something (communication, life, etc.).  In retrospect, I wish I had started with one big substantive file (i.e. all stuff about civic life, democracy, public sphere, etc.)  and just dropped notes into them. Others are from conferences, but the notes (not surprisingly) belong in a larger topical file.  Still others are on specific workflow issues (e.g. an early GTD file, too unwieldy for me; workflow mapping). So, having used TBX since the beginning I have a proliferation problem.

I think this problem relates to that of the thread. I keep coming back to the "what am I using this for?" question.  Clearly for notes, but not only.  This thread helped clarify that my various TBX files are themselves emergent: a reflection of topics pursued over at least 10 years now (how old is it anyway?) that are similar and changing. So, really, it might be time to go through all of the related substantive files and consolidate them into one larger working file, as I get ready for one or two larger books before I head for retirement.

One problem is consistency (others may have it too). I start a file, start taking notes, use it for one or two pieces, then move on to something else.  This is, of course, my problem, not Tinderbox's. But I think there is an elective affinity between Tinderbox and two types of people (at least) that are somewhat bifurcated.  People like myself who are not programmers (wish I was, but just can't get very competent; have tried over the years just to learn more about TBX functionality), don't really want to be programmers, but also don't want to just put lots of notes in a giant container and drag them around.  We are a bit ADD, maybe, and are attracted to the almost-infinite open endedness of the program. For those of us who are writers, this is one of those blessings that is actually a curse (look I can mess around in TBX for hours! take more notes, but never quite get to the level of organization that redeems all this note taking. So the notetaking ends up becoming lost and randomized, I drift away from the program, start working in a more traditional mode.  Then always drift back into it.  The point here is that there is an inflection point between random note taking and organized complexity.  It's hard to find. There are a set of procedures (organizing notes, using agents etc.) that can help you move up the curve from random note taking to organization, but they really aren't all that obvious from either following the functional/technical threads, or the intro use cases.  Many of us are stuck at this point, I bet: I have lots of notes, they are semi-organized, in groups within files or across different files: now what?

The power users have moved way beyond this point (they are the other group).  They fall into two groups. Those who are either programmers or have medium-high levels of programing skills but who are writers and creators of some sort (I think of Johnny Squid here, but there are many others).  And those technical folks who care about various levels of automation.  The questions and threads of both groups are often beyond me.

I want to start a thread for those of use who are writers, primarily nonfiction and academic, who have lots of notes, but are stuck at this next stage: how to realize the higher level of organization that would make this pay off. This is not a matter of any kind of technical capacities, but of thinking of best forms of organizing complex projects (e.g. the one big file vs. smaller files question that is often revisited).  How to take notes on books most efficiently when most of us (academics anyway) are also using  Bookends or Zotero, Scrivener (another of the great programs) and need a bibliographic database but don't want to duplicate our work. How to take notes on PDFs most efficiently using TBX.  Etc. Lots of small-medium sized questions that revolve more around working methods than TBX technique.

Sorry for this long post. Guess it touched a nerve.  If anyone wants to start a thread for working non-fiction/academic writers (including dissertators, etc.) let me know (Mark or Mark, if that's ok, let me know the best place to start it).

Title: Re: So, umm..., what is this app actually for?
Post by Mark Bernstein on Jul 23rd, 2011, 5:52pm

Why not start it in "Tinderbox applications"?

Title: Re: So, umm..., what is this app actually for?
Post by linn on Jul 24th, 2011, 11:14am

As a novice (as of last December), I really appreciated your post, but it did send a cold chill up my spine: I am at about the same "stuck place" that you describe (and equivalent academic background). I have been starting to wonder when and how people move on (up to the point of finding an online tutorial for regex and wondering if that would help!).  

I have been attributing my being stuck to still having a lot to learn. It's a substantial challenge just pulling TBX resources together, trying to figure out the language usage (see the Scrivener discussion on the word "deprecate"), and connect the outlines and maps to the sequence and production of prototypes, agents, rules, and actions. I do have the Tutorial CD and share some of the frustration with it that others have expressed.

It's also occurred to me to just "be happy"--moving those little boxes around in map view helps to think about relationships and missing parts of arguments in a mind-map way, but allowing more in the way of bits of wording and making notes on notes that mind map apps don't offer.  This is the emergent property that you mention.

Also, finally! Thanks so much for sharing your "retrospective wish" about starting one big substantive file. This question has haunted me from the start. So I'm up to following a thread on nonfiction/academic writing. It's a super idea, and there are likely to be others who would like it, too.

Title: Re: So, umm..., what is this app actually for?
Post by Mark Anderson on Jul 24th, 2011, 12:39pm

@Lew, a good thing for you thread might be to post a TBX with a some sample data that contributors can use as a frame of reference. Regular readers here will have seen that where people can post examples of their problem/solutions insights tens to come faster. I just figure that with a common reference TBX, it might give users an easier way to explain their  frustrations/triumphs. "I can't make container X show Y denials..." or "Here's how I mapped the Z relationships"....etc.

Title: Re: So, umm..., what is this app actually for?
Post by Jean Goodwin on Jul 24th, 2011, 3:12pm

Hi, Lew!  I'd read that thread--it's often very enlightening how other people solve problems, plus it's fun occasionally to feel competent enough to give advice.

I'm wondering though whether the specific problem you identify is a problem any software (even Tinderbox) can solve.  You're talking (it seems to me) about the point where a large amount of more or less undigested evidence (things in the world plus initial reactions to them) is on the verge of becoming an argument for a thesis that someone else might be interested in.  Outside of disciplines where methodologies are pretty much given, this is precisely the point where personal expertise/perspective comes into play.  Five different experts might legitimately proceed in five different ways.

Once we decide which way to proceed the problem becomes well-formed and software can help. Of course,  it can take some jimmying and good advice from the forum to get Tinderbox to do what's wanted.  But Tinderbox's sometimes frustrating excellence is that it doesn't make us decide.

Title: Re: So, umm..., what is this app actually for?
Post by Mark Bernstein on Jul 25th, 2011, 1:52pm

By the way: I'm not sure that the equation of "power Tinderbox user" with a strong computer science or software engineering background is justified by experience.

Title: Re: So, umm..., what is this app actually for?
Post by russ lipton on Jul 25th, 2011, 2:49pm

@Jean: spot-on.

Carrying on, I feel we must master the action syntax/semantics enough that TbX-powered solution pathways present themselves at that conceptual point where we would organize our improvisational research towards more systematic insights that may yield useful conclusions.

To wit, from aTbRef: "An action is an automatic way of setting a certain attribute to a certain value."

This is a masterfully concise window into the main game. The domain-unique knowledge we seek by our note-taking is set-or-computed (actions!) in TbX from the contents contained in attributes - since, ahem, everything becomes, ontologically, an evaluated attribute in TbX-world. This might be today's date, the coordinates of a note in a map or the brainstorm we dropped into one of our own user-created attributes from a hastily scribbled conference observation.

Thus, we will use actions constantly for proactive search-and-destroy-retrieve when we know what must be filtered, or to query-scan our existing content to elicit unexpected insights. Not coincidentally, these suggest coherent reasons for adding fresh notes/content, enriching our TbX landscape. Of course, since notes are 'just' more assemblages of evaluated attributes, we must repeat/evolve our action cycle, no? So it goes ...

Absent the mastery of action codes, our TbX world cannot but remain static. Forgive the analogy, but this would be a bit like building a Sims-world where its characters couldn't do anything, but just stood around in the midst of our artfully constructed Sims-landscape. Where is the fun in that?

The rhythm between learning syntax abstractly and pushing for mastery by the pressures/motivation of 'real' problems remains constant. But I must do enough of the former so wrestling with a TbX feature at the desperate point-of-desire, if time-consuming, doesn't derail me fatally from my own project. Too many derailments make us all (I suspect) shrink from advancing our mastery of TbX just when we most need its aid.

As a point-of-contrast with other dimensions of TbX, though I use export codes intensively, I gather many of us may never need them at all. And I still cannot understand why Nakokojisushibooshi views might help me, though I will surely use them when light dawns.

Similarly, I may distract myself by rudimentary TbX mapping without advancing the idea of need-and-interest which lead me to the map view. Here, though, may lie a converging observation to this post: mastering action codes gives me the cross-over point for mapping productively.

If some of us can identify, despite domain variances, the specific action codes/skills/lore where mastery affords the greatest return, would this not itself be a help to inquirers and point to cases to explore for the proposed discussion thread?

(A digressive point of encouragement to conclude: I think Mark B. has noted how TbX leads non-programmers into programming, for instance, managing objects elegantly, without realizing, thankfully, they have fallen into geek-ness. I agree. Therefore, let the non-programmers among us refuse to feel intimidated by queries, actions, rules, regexes and the like. Personally, I am intimidated by subjects like sociology ....).

Title: Re: So, umm..., what is this app actually for?
Post by Jean Goodwin on Jul 26th, 2011, 10:02pm

Hi, Russ.  You said:  

"everything becomes, ontologically, an evaluated attribute in TbX-world."

In slightly different words, that was THE key insight that gave me the sense of mastery, as opposed to victimhood, with respect to Tinderbox complexities.  Or maybe better:  How I learned to stop worrying and love the technology.

When I started, I thought of Tinderbox as a tool for notes.  A note was a long or short text I wrote.  And then I would attach some pointers or "metadata" as attributes, mostly to classify the note so I could find it again or sort it somehow.  Text = important;  attributes = stuck on.  Plus attributes = a source of worry, since I had to get them right or else the note (text) would get lost!!!

Nope.  A "note" is nothing more than a bundle of attributes.  One of the attributes happens to be the text.  But every other attribute is of equal status.  Within any individual attribute-bundle, the attributes can be shuffled and dealt out in a variety of ways like a deck of cards, and they can each be changed, with the changes flowing out automatically in ways governed by, you guessed it, attributes.

Once I "got" this, then I became confident that I could figure out how to do anything, especially with the help of the forum on the finicky grammatical bits.  The really hard part is figuring out what I want to do, and in the last year or so I haven't had any time to do that.  

P.s. Naka...you know view is text export for people like me too lazy to learn exporting.

Title: Re: So, umm..., what is this app actually for?
Post by russ lipton on Jul 26th, 2011, 11:14pm

@Jean ... exactly. You captured my learning process to a 't', which again suggests the possibility of useful generalization re: something common to the TbX learning curve challenge beyond all the domain variances.

Now, I want to recall (if possible) what I most needed to learn about actions so that it became positively fun to watch queries-actions-rules richochet across my TbX document, rather than terrifying. At first, I thought I would probably break my document's content beyond recovery (again, a common fear, I suspect).

Making zillions of backups solved that mainly, though not entirely, irrational fear.

Then, I realized my main problem was that I had become overly anal about the (conceptual) prettiness of my documents, and I am not an anal person psychologically. I am now convinced that my taking advantage of TbX's emergent properties requires doing personal violence to all such anality. 'Emergence' is (or, at least, looks) messy and can't be helped.

I have evolved an informal rhythm of 'messing' with my content, which begins by using actions-rules to help the document (e.g., a project) reach its next level of usefulness. At some hard-to-articulate point, but mainly when I am afraid I may soon fail to understand the effects of my own experiments, I stop, retain (refine) the actions-rules that helped, drop the stuff that led to dead ends and then work hard to prune, clean up and make the document elegant again.

In that phase, elegance is not anal prettifying, but the means for self-documenting (informally) the dynamism of the document's infrastructure. Once this is complete and the document seems 'simple' to me again, I can mess with it all again if-when the project demands it.

I hope these meditations prove modestly useful to others. In turn, I look forward to learning more about the 'internals' of other users, not to be a TbX voyeur, eh, but to keep growing myself.

(BTW, though I was being silly, I was also serious aboout Nakakoji. Probably, I have assumed there was something mystical about it and so avoided it. You are saying it is 'merely' a convenient way to export notes as text without having to bother with export codes. On that basis, I'll spend an hour or two exploring its usage. Who doesn't need to export notes-as-text for various purposes?)

Title: Re: So, umm..., what is this app actually for?
Post by Mark Anderson on Jul 27th, 2011, 6:18am

If it helps, TB is like a large card index.  Every note (or note-based object) has every attribute, even if not currently used or not usable because inappropriate for that object (e.g. $AgentQuery for an ordinary note). All cards (notes) come with some attributes pre-defined; these are the system attributes. You can also add your own 'user' attributes, in which case they get added to all existing and new notes, using the default value specified. Once added these attributes function akin to those pre-efined - they are all part of the TBX document and every note. To repeat, all notes get all attributes - even those created after the note was made. A number of attributes are calculated for you depending on current dynamic criteria and thus these tend to be read-only (r/o examples). Generally, however, all attributes can be edited by the user. A common false assumption by new users is that if they can't see an attribute (as a note's key attribute) then it doesn't exist or "..has been lost". It may not be visible but it's still there.  Learning how to display/ent info is the one area of TB one does need to learn but that's true of any app. for example, typing in the OS' Spotlight input doesn't create new docs, it just searches for existing ones).

We don't generally refer here to TB as a database - it scares less tech users - but in effect it's a flat-file database with data stored in XML. However, it's unlike many databases as it doesn't punish you for not knowing at outset all the fields (attributes) you need. Need an $IsComplete attribute? Just add it. As per the paragraph above, TB will seamlessly add it in to all notes without forcing you to redesign reports, etc. This is one aspect of its good support for incremental formalisation - you don't have to add stuff until you know you need it. A good example is capturing things in $Text into attributes. Instead of always searching the text of every note for "left-handed or "left handed", you might add an $IsLeftHanded. You can then use an agent to search existing notes' $Text for pertinent matches and set the attribute. Isn't this just extra work? That's in the eye of the beholder but whilst the agent's query might be quite complex, its result captured into a simple yes/no attribute is simple - and much easier to re-query.

Going back to 'lost' things, if the problem is you have attribute values but can't 'see' them, then you can set key attributes, display expressions, table expressions or use outline view columns (like a spreadsheet table).

Master Yoda might have said of TB: 'Do' there is not, only 'may'. So, think you must about your goal. TB is no more or less a magic box than any other app but unlike many it has no single or primary goal so it can't lead (force!) you down a certain path to a pre-assumed goal. In TB, person A might want to lay out a book, person B do timelines, person C create HTML documentation, etc. As it says often on a toy box - some assembly required.

Ask yourself what you're trying to achieve with your TB data and consider what things you need to add beyond the raw data to hand. At simplest it might just be arranging the notes differently in outline or map view. Beyond that it might be creating attributes to store metadata either in the basic $Text of notes or observations/deductions about the same. If you need to trawl the data and don't understand queries, try writing them as plain language questions and then check that the building blocks of the question exist. Sometime you may need to use attributes and/or supplementary agents to give you the building blocks for your master question. You might also want data reflected in attributes simply for display purposes. And so on...

As a new user don't try to achieve a whole big workflow in one go; that way tends to lie overload and thus frustration. Your end goal may be to export a synopsis of your novel, but if you don't yet have a handle on the main characters and where they interact, resolve those starting issues before worrying about the later stages. TB's support for incremental formalisation means such an approach is not penalised. Much of the angst I see from new users is through over-reaching at outset and getting lost by attempting too many unknown (undefined) things at once.

[edit: clarification]

Title: Re: So, umm..., what is this app actually for?
Post by Paul Walters on Jul 27th, 2011, 7:14am

Good points, Jean, Russ and Mark A.

Title: Re: So, umm..., what is this app actually for?
Post by Mark Anderson on Jul 27th, 2011, 7:41am

I'm beginning to see that some new users can be bit too literal in their understanding of the UI in terms of linking what they see vs. what's available; it's generally more than what you see. These images are all of the same note but with different view settings applied, as configured via ... attributes!

1. Default - with sidebar:

2. With sidebar and with key attributes:

3. With key attributes and without sidebar:

4. Without sidebar and without key attributes:

5. Customised $Text pane:

...and that's not all, e.g. we've not used $ShowTitle, but I hope people get the idea that not everything is always on display. Image#4 is the sort I envisage might trigger a comment like "...then the NeedGrab box disappeared!". The point of the latter observation is definitely not to mock but rather to try any show how such a conclusion, based on the immediate view alone, is simply mistaken. This info is still there, just not currently displayed.

If in doubt, some attributes for the given note are shown in the tabs of the Inspector ([Cmd]+[1]), whilst all can be viewed in the Info view ([Cmd]+[Opt][i]); note that with Info view you'll need to use the pop-up to move from attribute group to group to refresh the attribute listing with each group's attributes (just experiment - it's easier than this description may imply). The images are from aTbRef - worth taking a wander around the site - especially the sections on views, dialogs and menus.

Next step for the learner? Try out the customising view. Then, start experimenting with prototypes as a way of saving/applying customised note views. Prototypes work just as well for this as for setting rules, etc.  That should begin not to come as a surprise the data's all just attributes!

Title: Re: So, umm..., what is this app actually for?
Post by Mark Anderson on Oct 18th, 2012, 1:15pm

Some users' thoughts on their use of Tinderbox.

[admin is dusting off a few old threads as I understand we're expecting some new blood here]

Title: Re: So, umm..., what is this app actually for?
Post by Martin Boycott-Brown on Oct 19th, 2012, 2:59am

I think I might actually have found a use for Tinderbox. This has been puzzling me for a long time. I have had a licence for almost two years, and for the life of me I couldn't work out what to use it for. As I wrote to someone a few months ago, I have always had the impression that Tinderbox was powerful and interesting, but I have felt like the the owner of a Ferrari who lives in a place where there are no roads.

Now I am beginning to look at a new project that will be examining how the British army adapted to the challenges posed by the revolution in warfare that occurred between 1914 and 1918. I realised that I could set up a Tinderbox file that has a "note" (read "entry") for each relevant event. I could make battles one colour (blood red?) diplomatic initiatives another, training manuals could be "paper colour", tactical innovations something like sky blue -- you get the picture. These entries could then be displayed on a map so that (for example) one can see that training manuals tend to be published in clusters at certain times of the year, or at a certain time after a major offensive. And of course, one can link events in various ways.

There are still lots of kinks to be ironed out -- apart from anything else, I'm still a complete novice in using Tinderbox. But I'm rather pleased that I finally seem to have discovered something I can use it for. It has only taken eighteen months to a couple of years ...

I may be coming back to ask for help. I've only got a hazy idea of how to work this thing.

Best, Martin.

Title: Re: So, umm..., what is this app actually for?
Post by Mark Anderson on Oct 19th, 2012, 4:03am

Your ideas all sound good. something else, new during the time since you first got Tinderbox is Timeline view. So, just by giving something such a note on a pamphlet a $StartDate (e.g. date of first publication) it will show up on a Timeline view. Colours and badges work well in all views, whilst the map additionally offers shapes, borders, shadows and more.

It's easy to dismiss these visual annotations as eye candy but, used with thought, they can be very useful in finding emergent structure and show associations hitherto unseen.

If planning categories of 'event' in advance, don't overlook use of prototypes as they will be big time savers, even if only for data entry/note configuration. Thus the e 'battle' prototype can set a colour, badge, shape, key attributes, etc. Add a new note about a battle, apply the desired prototype and the customisation of a number of attributes is immediate - each of which you'd otherwise need to do by hand for each battle note. Plus, to find all battles you then simply need an agent to look for all notes whose prototype is 'battle'.

You can lay out your map on a time basis. some people use agents or rules to set $Xpos to a figure based on $StartDate (or some other date attribute), but don't overlook Timeline view. The latter can show the time progression of your events and, via timeline bands, show the data in different thematic layers. The latter is possible without affecting the layout of the map allowing you to use position for other associative methods.

Title: Re: So, umm..., what is this app actually for?
Post by Martin Boycott-Brown on Oct 19th, 2012, 4:32am

Thanks for those ideas -- particularly the prototype idea for different kinds of event. I hadn't thought of that.

I'm not sure if I will use Timeline, though it seems an obvious thing to do. The way I have things set up is that the title of each "note" begins with the date in YYYY/MM/DD format, then comes the name of the "event". So a typical entry is "1916/07/01 - Battle of the Somme begins". That means that I have all the information available right in front of me in any view, and it will sort alphabetically. (In fact, there is no "content" for any of the notes, though I might add explanatory text if it is needed.) In part, I have done this because I may want to use the same data in other programs (specifically Devonthink Pro Office, as in this example -- http://tinyurl.com/9n6akrm ).

As usual with historical data, some of it has no precise date -- the month and year is the closest you can get -- so one is reduced to putting in a "false" day (typically 00). Obviously that doesn't help with stuff like "mid January". You can't put in 15 January because that gives the impression that you have the precise date (I know from experience that it is easy to forget that you have "forged" the date and it creates all kinds of trouble). So the date field is of limited use -- one has to think of ways around it.

On a technical note: is there a way of extracting a date in YYYY/MM/DD format, and turning it into a format that Tinderbox will accept in the date field? I'm thinking that I might in some cases need to extract the first part of the title of my notes and place it in the date field. Or even do things the other way round! (date field to title)

Thanks for all your help,

Title: Re: So, umm..., what is this app actually for?
Post by Mark Anderson on Oct 19th, 2012, 6:49am

Off-Topic replies have been moved to this Topic.

No censure implied by 'off topic'. It's just to stop thread drift and let individual topics get more focused discussion.  :)

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.