So is there any way – a la, say, Omni Outliner or others – to have columns that are simply spatial and not defined by attributes? Basically, in order to reduce scrolling and/or expanding and be able to get as complete a single, synoptic view as I can, I’d like to divide the outline into two halves and “continue” it at the top of the screen, a “snaking” outline, if you will…
I’m guessing the answer is no, but thought I’d check. Even in Omni Outliner the expand, collapse points will always be defined by the left most column, but that can usually be worked with… Plainly, I’m trying to keep as much of the project in Tinderbox as possible. I don’t know much about OPML – if I tried to import from Omni Outliner a column based outline, what would happen?
I was thinking of ECCO Pro – which I believe allowed expand/collapse points to vary across columns – and see that this type of thing has been brought up here before. There’s also been talk lately on the Omni Outliner forum about the wish for less dependency between columns and more autonomy among them…
please attach a picture of what you are talking about
In short no. I don’t think this idea has been proposed before. In a more complex app like Tinderbox I suspect it’s more complex then in an outline-only tool.
What happens when you expand the outline branches, does the sub-column scroll horizontally. ISTM this is quite a narrow use case for shallow outlines (as in few levels of content) as in simple lists.
It works, I’ve helped users import large amounts of OmniOutliner data via OPML. Depending on imagined outcomes you may need to do a little bit of set-up at each end and I’m less sure about going the other way (limitations at the OmniOutliner end)
To confirm, ‘No’ at present. But someone who wanted that could always make a feature request to Support.
It’s probably complex even in an outline-only tool, and the Tinderbox version of columns obviously has great – perhaps even greater – advantages, but autonomous outline columns would enable more than bigger, more inclusive helicopter views. The use case most often discussed is having check boxes function independently among columns, but being able to have different expand, collapse points across columns is a bit of a grail for some, and would, I think, come to be widely utilized/appreciated if available. So it may not just be the narrow use case of shallow outlines. But yes, horizontal scrolling would become much more frequent with this kind of column mode.
Even as a non-programmer, I can imagine some of the complexities involved in making it work, however.
This is interesting, in that I wondered if the attribute centric mode of Tinderbox columns wouldn’t allow for importing plain vanilla columns. (Perhaps this means that, structurally, it wouldn’t be too much of a programming stretch.) I’ll see if it makes sense to switch to OO with the thought of import to TB. Onwards — JM
Tinderbox outline, with columns enabled, shows attributes as what else is there to show? Actually, OmniOutliner is just the same - add an extra column and the column name is essentially the equivalent of a Tinderbox attribute. I don’t think OmniOutliner limits the number of columns it allows. Of course if you’ve never added coluimns in OmniOutliner this may be a surprise.
OmniOutliner doesn’t have a notion of note title and text. It appears to treat the first paragraph of the default column as the title as rest os further text (which may be hidden by default). IIRC it wasn’t too well documented. (Omni apps—I’ve used Graffle more than Outliner—tend towards minimalist Help. We worked around the problem by splitting (via AppleScript) the ‘title’ column of OmniOutliner data after the first sentence and putting the rest in a separate column which was exported as what became the $Text in Tinderbox.
I’m afraid I can’t figure out what this means. The checkbox belongs to the note (i.e. row in OmniOutliner terms)
The seems more like a spreadsheet where some cells are merged across columns than anything like a outliner. As every note/row has all attributes there is nothing to expand, other than to expose child notes in the traditional outline behaviour.
Mark, would not separators be useful for this? Notes can be nested in a separator which would allow for expanding and collapsing, no? Also, if you wanted more check boxes these could be created as new attributes.
I don’t think so. It’s moot anyway as it is part of an overall view that doesn’t make sense in Tinderbox. But without a proper description of the layout, it is hard to tell. Presumably it is taken from the UI of some other (name?) app. Seeing that might make it easier to interpret likely feasibility.