Understanding how Outlines are displayed

Q & A - getting started with Tinderbox
1

[Split from Obsidian launches "properties" - #47 to avoid topic drift]

I tend to agree that what an outline is or rather, how outline functionality is effected in an app, is very subjective.

In Dave Winer’s old outliners an outline item is a single short piece of plain text. In Tinderbox terms $Name only, short and with no styling. This explains why OPML that Winer (IIRC) also developed had no attribute for text ($Text in Tinderbox). It was Omni’s OmniOutliner that added a non-standard _note attribute. So it is that most OPML I’ve seen is not strictly compliant with the OPML standard.

Those who never saw the pre-v6 UI won’t know that Tinderbox follows the basic outline closely. In the old UI, the current view pane was a view window:


(from Tinderbox v4.5.0)

…whilst the current UI’s text pane was at that time a separate ‘text window’ (closer to a current stand-alone text window):


(from v5.0.0)

Even today, you can use a Tinderbox outline in the basic form as you can edit $Name in the view.

Bottom line, our perspectives on the ‘correct’ interpretation of what an outline is and/or the outline UX experience will differ. I think we tend to use the latter to assert, wrongly, the former. It matters not, given that there is no single truth, nor needs there be.

BTW, for those interested in outlines and outlining, check out @tedgoranson’s wonderful “About This Particular Outliner” (aka ‘APTO’).

The vagaries of outlining given above stand as a good proxy for the wider case when comparing Tinderbox and OtherApp:

  • how do (named) features map, in terminology or function
  • if feature elsewhere why are they useful in Tinderbox (i.e. rather than " Tinderbox must add…"). In addressing such desires the dev has to consider:
    • what might the new feature break or disrupt (satisfying one user might break the app for many long term users)
    • how/where might it be added
    • is it worth the effort (ROI - engineering/maintenance might outweigh keeping up with the fad de jour)
    • is the suggestion sensible (a little thought often means adding a feature in a way that works even if not as described by those requesting it)

Personally, I tend to focus on inter-app process and optimising that. A one-app-does-all desire seems self-defeating.

5 Likes
2

Happy to take this excellent framework to heart and re-examine my Note structure to more closely conform with the truer architecture as you’ve brought up here, and as is provided by Tinderbox. I will also peruse APTO (which seems kind of an amazing effort!).

Currently, my 2 (self-imposed) paradigm limitations are:

  • I am used to Outlining “upwards” if that makes sense. I may start with a long rambling text (or collections of text scraps all lumped in one Text body), and will then promote certain lines to sub-heading status, with the intention of moving/dropping chunks of text in the form of children of these newly-created sub-headings. I’m able to do this in those other-mentioned text/outlining environments (TaskPaper, Obsidian), but have not seen how mirror this process in Tbx without constantly flicking between Text and Preview modes. This workflow also allows me to fold away chunks as needed, and avoid much scrolling. I may be missing something workflow-wise, of course.

  • I have gotten accustomed to the visual affordance of “directory structure on the left pane PLUS foldable text on the right pane”. Combined with the above-described “upward outlining” process, this works very well in structuring my data into meaningful Notes, and promoting chunks into individual files as I work through bundles of text; and THEN importing them into Tinderbox where the $Attribute structuring takes place. Wondering how I can achieve that while editing and assembling text in Tinderbox, WITHOUT having to switch back and forth.

All the above might mean that I need to stick with my current system, which delays “point of importation” into Tbx. The issue is that my structural edits (all my Key Attributes, as well as the niche ones like $Xpos/$Ypos, etc etc) also get delayed, which is a great pity and also time/focus lost.

Thanks to your advice here (as well as that of @satikusala in the predecessor thread to this one), I’m getting the germ of a fresh idea wherein I might concurrently maintain 2 different types of outline structures within Tbx, and visually demarcating these structures by means of $Attributes like Color, Badge, etc. Not sure if I can pull it off, but going to trial something of the sort.

Would be happy for an off-line chat sometime at your convenience about this re-visioning process, @mwra!

Related:

3

There’s a shortcut path from A to B, if I am understand “A” and “B” correctly.

  1. Create a note, and use indentation (tabs) to indicate the desired outline levels.
  2. Copy the text of that note
  3. Go to the Outline pane (left pane) and “Paste” from the contextual menu

You’ll get an outlined hierarchy to work with (the children of “imported outline” in the image). The point is that Tinderbox is helpfully sensitive to what’s on the clipboard and accurately produces hierarchical notes based on what it reads there.

CleanShot 2023-09-12 at 16.01.28@2x
CleanShot 2023-09-12 at 16.01.28@2x1722×830 103 KB

(BTW, it’s ATPO, not APTO)

1 Like
4

Yes. Though the ‘how’ you describe works within an expectation of the way an outline is implemented. No judgement there, but simply a reflection on how fragile a common understanding can be.

Meet up? Absolutely, yours for the asking. Drop me an email.

1 Like
5

EDIT: See below. May have this entire issue licked, by re-scoping my workflow a bit. Roses.

This is good, and I’ve done it in the past.

I’m referring more to the ability to simply fold away portions of my $Text block as I’m working.

For example:

=======
Idea 1: This is Idea 1, it’s about the Moon
This is a block of Text, let’s name it Block 1A
. This is a clause or url or reference that applies to Block 1A, let’s call it Child 1A(i)
This is a block of Text, let’s name it Block 1B
. This is a clause or url or reference that applies to Block 1B, let’s call it Child 1B(i)
. This is a clause or url or reference that applies to Block 1B, let’s call it Child 1B(ii)

Idea 2: This is Idea 2, it’s about the Planets - related to Idea 1, but will eventually be a separate Note
This is a block of Text, let’s name it Block 2A
. This is a clause or url or reference that applies to Block 2A, let’s call it Child 2A(i)
This is a block of Text, let’s name it Block 2B
. This is a clause or url or reference that applies to Block 2B, let’s call it Child 2B(i)
. This is a clause or url or reference that applies to Block 2B, let’s call it Child 2B(ii)

Idea 3: This is Idea 3, it’s about the Galaxy - related to Ideas 1 and 2, but will eventually be a separate Note
This is a block of Text, let’s name it Block 3A
. This is a clause or url or reference that applies to Block 3A, let’s call it Child 3A(i)
This is a block of Text, let’s name it Block 3B
. This is a clause or url or reference that applies to Block 3B, let’s call it Child 3B(i)
. This is a clause or url or reference that applies to Block 3B, let’s call it Child 3B(ii)
This is a block of Text, let’s name it Block 3C
. This is a clause or url or reference that applies to Block 3C, let’s call it Child 3C(i)
This is a block of Text, let’s name it Block 3D

=======

can look like the below, while I’m working within the same note. I like to fold away the portions I don’t need right at the moment, without resorting to (Cmd-Opt-E) cycling between the Text/Preview/Export viewing modes.

=======
Idea 1: This is Idea 1, it’s about the Moon…
Idea 2: This is Idea 2, it’s about the Planets - related to Idea 1, but will eventually be a separate Note…
Idea 3: This is Idea 3, it’s about the Galaxy - related to Ideas 1 and 2, but will eventually be a separate Note…
This is a block of Text, let’s name it Block 3A…
This is a block of Text, let’s name it Block 3B…
This is a block of Text, let’s name it Block 3C
. This is a reference that applies to Block 3C, let’s call it Child 3C(i). It’s the line I’m currently working on, while on this particular Note |
This is a block of Text, let’s name it Block 3D

=======

When I look at how Tinderbox is structured, I accept that I can’t exactly work this way unless I flip between Text and Preview modes. So the option is to either modify my workflow or retain my Notes in one of my “feeder” apps just a little longer until it is ready to export to Tinderbox, and gain structure there.

I think I have a workable solution…! Developing it now, and will report or demonstrate at a subsequent meetup, if anyone is interested.

3 Likes