Tripping over the line: best practices with Separators

Q & A - getting started with Tinderbox
1

Hi. I’m having a sweet honeymoon with Tinderbox … and each evening I watch the light from the fire flicker across the room while I organize my notes and questions. I am a complete neophyte. I have attempted to look up most of them. I will try to keep my questions precise. I ask a lot of questions. I am greatly looking forward to learning how to best apply Tinderbox to my needs, and then doing it. So onward: (I will repeat this a few more times, that’s all)

  1. Is there an easier way to switch the display of a Note from “regular” to be a Separator Note, and back, than checking/unchecking the box at “Properties Inspector ▹ Prototype”? That’s pretty easy (once you find it) — I had expected there might be a control or key-chord that would make the switch in the Outline pane without having to open the Properties Inspector.

  2. Why are Separator Notes and their children banished from Map View? (Doesn’t this reduce the utility of Separator Notes to only being used to hide Notes from Map View’s display?) A well-made outline has, IME, nested containers that provide taxonomic organization (some carrying commentary about the class represented ) with content held in the deepest descendants. (In other words, all parents are used for grouping, and content is held by outline items {here, “Notes”} with no children.) Starting with that prejudice, I excitedly made Tinderbox outlines of Separator Notes, and was pleased to see how the Titles are displayed in the Outline browser, and that Separator Notes could contain text themselves (in a physical filing system, this would be writing on your manilla folders {or your Pendaflex folders — or even on the file cabinets themselves}). Separator Notes seemed especially useful as containers listing things such as recipes, or books to read, but in fact one could easily conceive of an entire Tinderbox document where every non-bottom-level Note is a Separator Note. All that was overturned when I found out that Separator Notes and their children are not shown in Map View — which constitutes a large part of Tinderbox’s utility. I feel I’m not grokking something here.

  3. Is anything lost when a Note is converted to a Separator Note, or back?

3

Thank you. I don’t see how that applies to my questions. I’m not asking “How can I organize Notes in Map View”, I’m asking “What are Separator Notes used for?” since the — to me — odd function of hiding them and their children in Map View makes them useless for anything except hiding Notes in Map View.

I am curious why Separator Notes are not shown in the Map as “Adornments”, but that is a deeper question than I wish to entertain right now.

6

[ The point above is correct. If you look at adornment documentation you would see they do the same role but in different context. Adornments only show in Maps, Separators aren’t shown in Maps or Charts. Separators (with optional title text) were added to allow outlines to allow sibling notes be delimited into discrete groups. The original intent was that they would not allow nesting within them, but by accident they did and users asked Eastgate to keep the feature and thus the way they operate now. See more on Separators.

I’d suggest reading this article on the Outline vs. Map UI.

I see @PaulWalters has already added some further notes. I don’t think there is a keyboard toggle for setting/unsetting separator status. Tinderbox already uses most available keyboard shortcuts and this toggle isn’t a common function. You can set your own Mac to re-purpose an existing shortcut if necessary.

As Tinderbox is much more than an outliner, it will be hard to understand the app by only looking at the Outline part of the app, even if you don’t intend to use those aspects.

No, but the note and any child/descendant notes, will be hidden when using Map or Chart view. As you’re not using those views I think the short answer is ‘No’.

7

I can try and respond to part of this (health warning: I’m still finding my way in Tinderbox, so do not expect guru-standard content)

A couple fo factors seem to be in operation:

  1. I understand that Tinderbox does not treat Map and Outline view as simply alternative ways of representing an outline, but as alternative ways of representing the information.

Outlines are a way of organising information in particular structured kind of way (caveat: plenty of debate around the internet about what an outline actually is or could be) - hierarchically, with relationships based solely on level within the hierarchy.

Maps (in TB) can support a wider range of relationships - you can relate notes (including containers) by things like position, size, shape, colour (or color if you prefer :slight_smile: ) etc.

Because of that, I might well not want my map to show the same relationships as the outline - I might be using adornments for a completely different purpose from separators. For example, I might use separators to organise meeting notes by meeting name (weekly team meeting, fortnightly Project Board, 3-monthly IT Committee, whatever), whereas I might use the adornments in map view to organise the notes by type (Action, Future Planning, Policy, Issues and Risks).

I don’t have to do it that way (I could use $Tags in outline view and some relevant searches, or aliases, for example. TB doesn’t push me to one method (or a narrow choice of methods).

  1. I can see why it might be useful for separators to appear on maps or adornments in outlines - but TB makes an explicit choice not to make that the norm. You could achieve the effect using agents and/or prototypes - and the point of TB is that you get to choose to do that or not.

There’s a comment in “The Tinderbox Way” to the effect that we’re had several decades of software that, in the interests of ease of use have guided us into relatively narrow ways of recording and presenting information, and that TB is an attempt to provide an unconstrained platform and, in doing so, allow implications and relationships to emerge that would not/could not in software with pre-defined presentation models (apologies to @eastgate if I’ve misrepresented that).

What it means for neophytes like me (and you, maybe) is that our expectations of how TB works are continually being upset.

  1. The final point is one that comes up here often - there isn’t a “best practice” for most of these things - there’s only what works for you - gives you the outcomes you want.

I hope that all makes sense (and helps a bit)

3 Likes
8

I couldn’t agree more. Perhaps Tinderbox is the Lego of notetaking – no rules, just features. Make “anything”.

1 Like
9

Hadn’t thought of this metaphor, but I agree with it 100%. It is a big Lego set. The open-endedness can seem puzzling or frustrating initially. After a while, it has the Lego-set-like utility of conditioning you to think: OK, I know I can build the kind of [space ship / gas station / sail boat] I have in mind, I just have to put the pieces together in the right way.

2 Likes
10

I like using separators for providing informal structure in an outline. I haven’t decided that there’s a formal hierarchy to the information yet, but I do want the notes to have some lightweight grouping.

I admit that I’ve never added a child note to a separator. I can see how that would be confusing when it doesn’t show up in map view. I can also see how that could be useful for showing commentary notes that only appear in outline view.

If you’re using separators as a sort of visual identifier, then perhaps there’s another way to achieve that – maybe by coloring the note or adding a badge. Separators definitely look good in outlines though…

1 Like
11

Thanks to all — this is becoming clearer to me. I believe my initial confounding of Separator Notes with Titled Separator Notes has produced some confusion in this thread. I’m going to try to clarify that, while responding to the several remaining contributions. Thanks to each of you for replying.

First, let me list the answers to the questions I originally posted:
1.] There is not an easier way to toggle the state of a Note to/from being a Separator Note other than via the Inspector. One suggestion is, if this is important, to create my own key-binding. Another suggestion — iirc, this was posted by Paul and subsequently deleted — was to use a Tinderbox Stamp to either change the state of a Note to a Separator Note or the toggle between the two states. I’m sorry he deleted his post.

3.] (listed out of order because #2 is complicated) Nothing is lost, as far as anyone knows, when the state of a Note is changed from “regular” to Separator and/or back. This is good to know.

2.] Here some explanation may be helpful. I’m not experimenting with, nor do I expect to have any use for, Un-Titled Separator Notes. (In an attempt at clarity, I am going to refer to Un-Title Separator Notes as Separator Lines.) Separator Lines show as lines in the Outline Pane of Outline View. Separator Lines may have children. (This complicates things.) Of course, if they have no children, they are not containers, and it makes excellent sense that they don’t show in the Map Pane of Map View. Once they do have children, though, they become containers, in which case it makes conceptual sense for them to be represented as containers in Map View. I am not arguing yet that they should — just that it makes sense for them to.

Marc has provided an illuminating history of the Separator. Does anyone know why Separator lines were considered a better solution to grouping siblings than regular Notes? (The grouping of siblings in an outline is done by adding parents as siblings and thus creating another level.)

Note again that I was not thinking of Separator Lines in my OP. Separator Lines with no children provide no utility I was interested in for the representation of the Outline of my Notes; Separator Lines with children was such an odd conception to me that after testing that one could be created I never made one again.

At the same time, I very much liked the visual representation of parent Notes in my Outline as Titled Separator Notes. There is something useful to me in visually prioritizing parents (they are, after all, containers — a characteristic nicely echoed in the boxed title). So I went about changing the state of each of the parents in my growing Tinderbox test document from a regular Note to a Titled Separator Note. My outline was good-looking, informative, and functional. Until I discovered that all Separator Notes are unavailable for display in Map View. (In primping my Outline I had excised more than half of Tinderbox’s faculties.) I was perplexed, and came here and asked: why is this so? In essence … what was I missing?

I will now present an argument for why Titled Separator Notes with children should show in Map View as regular container Notes with a viewport.

In this context Separator Notes have four states:
. No Title, no children
. No Title, children
. Title, no children
. Title, children.

Taking them in turn.

Separator Notes with no Title and no children appear as lines in Outline view and would be meaningless in Map View. They should not show in Map View.

Separator Notes with no Title and children appear in Outline view as a line with Notes indented below it. This is, to me, analogous to a file folder in a file cabinet that holds papers but is not itself labeled. This construction is generally regarded as undesirable (according the history Mark gave us, it was never the developer’s intent that such a thing exist). Even electronically as outline items, they are a weird entity (imho) that should be dealt with arbitrarily. (Pat, above, mentions using them for commentary that appears only in Outline View, which seems an excellent use of them.) They could appear in Map View.

Titled Separator Notes with no children show in Outline View as a kind of in-line label. Labelling entities that group or separate is good practice. To me they are slightly more useful than Separator Notes with no Title and no children, but they remain — if you’ll allow me — simple Outline View adornments. They should not show in Map View.

Titled Separator Notes with children are a different entity entirely. They are containers. They show in Outline View as containers with a visually prioritized label. The Notes they contain (their children) are as much a part of both the Outline and the Tinderbox document as any other Note. I propose that those Notes, and their children, show in Map View with the same functionality of other container Notes: as a drill-down-able Note with a viewport. That they are Separators in Outline View should not prevent them or their children from showing in Map View. (My suggestion is to have some small visual indication in Map View that these container Notes are Separator Notes. That they are titled, and that they have children, is already immediately apparent in Map View.)

The problem we are looking at here arose (afaict) when Separators were accidentally allowed to have children. If they don’t have children, they should not show in Map View. A childless Separator is never a container — it is just a visual indicator. Interestingly, this is very much like Adornments in Map View (NB: afaik), which, it is carefully pointed out, are not containers and never show in Outline View. But since Separators can have children, they become containers. It makes sense to me that all containers should show as containers in Map View. The solution is to either not allow Separators to be containers (make them like Adornments), or to show Titled Separators with children as containers in Map View.

1 Like
13

As I thought I’d explained, originally separators were intended to be just that - lines with or without an optional title as a way to divide groups of siblings [sic] in an outline. However, it transpired that the feature inadvertently let people nest notes in separators. Users liked this and convinced the app’s creator leave this unplanned functionality in place. It really as simple as that. I’d encourage not over-thinking this feature, rather than try and justify each features role, use what you need and ignore the rest.

Outlines have lots of ways to visually differentiate them (too many to list now - but think colour, background, font , font size, etc.). Breaking the concept of the separator just for decoration purposes strikes me as retrograde. I’d encourage delving deeper into the app before investing too much in a change that breaks functionality for decorative effects that can be achieved by other means.

14

You explained that much. My question is a follow up. To restate: what need was met by the original Separator Line that was not better met by using Notes as containers. Outline items (Notes) are exactly intended to create sibling groups. Outline items (Notes) already existing in Tinderbox, and the function that was supplied with the introduction of Separators was already exemplarily met by them.

(Added:)

I don’t see it as breaking or “just for decoration” — the opposite, in fact. I am asking that the function of Titled Separator Notes be extended beyond their current limitation of being almost useless except as decoration. Therefore it seems it would be a welcome step forward.

15

I fear we’re going in circles. Separators are notes (as indeed are adornments). The $Separator or $IsAdornment boolean simply tells Tinderbox this note is to be drawn/used in a different way. I think not understanding this connection is the cause of your confusion.

Actually, No. More accurately: Outline items (Notes) are exactly intended to create siblings.

Only nesting gives groups. but what if you don’t want nesting? (e.g for export reasons - remember this app’s blogging heritage).

Separators—with or without title—separate groups of sibling notes. Separators are still valid notes. A deliberate design feature was that separators aren’t visible in Out;lines in the same way adornments aren’t visible in Outline.

The ability to nest notes inside a separator wasn’t an original design intent but was retain because users ask for it. One use was to be able to hide containers in maps. Your proposal breaks that and the existing documents built on that premise.

Tinderbox is a long lived app by software standards. With longevity comes complexity and it’s important new ideas don’t break existing and long-lived document just for the thrill of the new.

I’m not suggesting the UI change proposed doesn’t have merit or forethought, I’m simply saying the proposal is unintentionally disrespectful of existing use - as it would completely break it. Ergo, if this feature is needed it should perhaps be implemented a different way.

16

Separators grow from adornments, and adornments in turn emerge from a feature of a nearly-forgotten Web editor Trellix (not to be be confused with the classic hypertext system Trellis), in which Dan Bricklen, Julianne Chatelaine et al. introduced adornments as an approach to informal, ad hoc grouping. This fit nicely into the agenda for discovery of emergent structure of Cathy Marshall’s VIKI, which was Tinderbox’s most immediate inspiration. Adornments only appear in map view; their appearance in outlines would be confusing and would discourage their use.

Now, idiomatic Storyspace use in this era was focused on map view, and the Storyspace outline view of those days had tended to be an afterthought. One of the earliest goals of Tinderbox was to redress this or, if this could not be redressed, to eliminate outlines entirely. Hence, the success of adornments in map view called for some equivalent construct in outlines.

Now, outline view really has two facets. First, it exposes the entire hierarchy of the document; for documents where the hierarchy is meaningful and important, that’s obviously very useful. But, second, even where the document hierarchy is not particularly salient, an outline view of a specific container is an efficient way to view a list. Many projects require lists — lists of tasks, lists of references, lists of options. The tools we use for outline manipulation also let us manipulate lists…

Just as adornments break the plane of the map into bounded neighborhoods, separators let us break a list into segments. Untitled separators give us a visual representation of partial ordering. We can say, “The Eagles, Patriots, and Steelers are good; the Browns, 49ers, and Jets are bad" without having any particular idea whether the Eagles are better than the Patriots. Untitled separators provide a visual language for expressing this sort of ad hoc relationship.

A further difficulty in the relationship between outline and map views is creation of notes in outline view. The Tinderbox map view works as it does because, when you create a note in map view, you don’t have to stop and specify its map position; most of the time, you create a note by double-clicking there and that’s where the note goes. (The crucial lesson from the all-important NoteCards project was that metadata like map position needs to be added implicitly or it will not be added at all.)

But separators, being meant primarily to be used in outline view, are typically created in outline view. Now, sometimes we create notes in outline view, too, and reposition them later in the map, but that’s a natural and intuitive chore: you haven’t told Tinderbox where this note goes, so if it’s in the wrong place, just put it where it belongs. In the case of separators, though, people said: “This separator is cluttering up my map. And it’s got no function in the map: the outline shows the partial ordering, but I’m expressing different things in map space. So, you’re showing me something irrelevant, and you’ve stuck it on top of something I wanted to see."

So, that’s this history, and a few of the footnotes.

3 Likes