Bike: adding Notes capability

[mitchellm]

I am wondering if you’d consider adding a “notes” feature. Several other outliner apps offer this. The main reason I’d want this feature is I typically go through this process:

1. outline
2. mindmap (iThoughts in my case)
3. writing app (iA Writer in my case)

In a mind map notes are, essentially, hidden. There’s typically some icon attached to a node to indicate there’s a note associated with the node. In turn this gets rid of extraneous “noise” when I’m in the process or refining, or reorganizing, my outline within mindmap mode. Also, in iThoughts, those notes get exported to markdown in an elegant way: as text under the header defined by the node name.

I don’t know if anyone else would find this useful, but wanted to at least put the proposal forward. Love Bike so far!

[oddballs]

• 1 for notes feature. Realise it may come after v1 ships.

[jessegrosjean]

I don’t want to add a separate specialized note field for each item, but I would like to allow for similar functionality.

I think the way that I will do this is by adding types (sometime after 1.0 release) to items. For example maybe Bike will support h1, h2, h3 types. Normal items will be p. And maybe “comments” could be aside items.

I expect that’s how I’ll handle “notes” in Bike. Another option that I’m less excited about right now, but maybe will make more sense if I think about it closely is to add an inspector view to Bike. There item attributes will be presented as a table of key values that you can edit, and maybe “notes” is one of the keys.

[mitchellm]

I think your first suggestion should work well. The second suggestion might be fine also but I’d have to see it in action first. Notes, per se, are not important. But creating easy and useful ways to get the info out in a structured manner would help a lot (H1, H2, etc. plus paragraph and aside). Thanks for looking into this!

[carlos]

+1 on adding a “comments” or “notes” feature, and a -1 on adding this as a separate inspector window. I’ve really loved the simplicity/cleanness of Bike compared to the competition (this is true, unsurprisingly, for TaskPaper as well) and I would love to have notes/comments to items visible at a glance.

My use case is outlining documents, and being able to think through what I want there with quick notes would be great.

[Jerzy_Golota]

I am against notes as some separate field or different mode.
The ideal of a simple outliner is the closer to a piece of paper it is. When you plan something on paper you don’t “Switch into a note mode”, you just write. The same is in Bike atm - I put notes about a point just one level deeper.
On paper, however, you can cross out… and this is what I’d love

[Jerzy_Golota]

Can’t you just put notes about a point one level deeper in structure? Like this:

OUTLINE

Point 1
Point 2

Notes about point 2

[mitchellm]

@Jerzy_Golota If you are only concerned with Bike then your suggestion works fine. But in my case I’m typically going from an outliner to something else. Typically that something else is iThoughts (a mind mapping app). Within the realm of mind maps, and OPML, “notes” is a kind of special designation. (Not sure of geek speak for this.)

Put differently, your suggesting results in one more additional node when I go from outline to mind map. Having OPML-compliant notes results in a note embedded within a specific node in the map. It’s an entirely different result. If I did notes as you suggested then I’d end up with a lot of cleaning up to do when transferred to a mind map application (as one example)

[complexpoint]

iThoughts uses the convention (not part of the OPML standard, and introduced, I think, by the writers of OmniOutliner) of a textual _note attribute in addition to the standard text attribute.

The value of _note can be several paras, delimited by 
 (linefeed)

I’m personally not keen on this title + paras structure, which descends, I think from email, and loses some of the power of full and consistent outline structure, but …

a pair of custom import and export scripts for Bike might be able to roundtrip that (OPML -> Bike -> OPML) by:

1. importing any _note attribute paragraph(s) as initial children of the parent node (without any children themselves, and starting + ending with some kind of parenthesis like ( ... note items ... ) or [ ... note items ... ]
2. Exporting any (childless and parenthesised) initial children of a Bike item to OPML as the (
 – delimited) value of a _note attribute.

---

Otherwise, perhaps just use the convention that the first one or more children of any item can be:

1. childless, and
2. parenthesised to mark a special role ?

---

Later, as Bike HTML attributes and format develop, it may be possible for some initial childless children of a note to have a special note format ?
(and make that exportable to an OPML _note attribute ?)

[jessegrosjean]

I agree that a script is the right solution for now, and maybe for always.

[complexpoint]

I agree that a script is the right solution for now, and maybe for always.

I may take a look at sketching out a pair of scripts like that in a day or two.

[jessegrosjean]

How are you thinking of doing it? While I think script is right solution here, I also think such a script might be painful to implement at moment, at least from AppleScript scripting context. You would need parse/write OPML.

If I add read/write access to row attributes then might be easier to write scripts that transform outline representation between iThoughts notes form and standard Bike form… and then use Bike’s built in OPML read/write functionality.

Maybe it’s not as hard as I think, or you have another plan. If not I can try to prioritize scripting access to attributes. Let me know.

[complexpoint]

@jessegrosjean

How are you thinking of doing it?

With NSXMLDocument methods it should be fairly direct – I’ll test that hypothesis to make sure

e.g. for the simpler case:

Expand disclosure triangle to view JS Source

// treesFromOPML :: OPML String -> [Tree Dict]
const treesFromOPML = strOPML => {
    // A Tree of dictionaries with at least a 'text' key,
    // and potentially some other keys too.
    
    const unwrap = ObjC.unwrap;

    // go :: [NSXMLElement] -> [Tree Dict]
    const go = elems =>
        elems.map(element => {
            const children = unwrap(element.children);
            
            return Node(
                Array.from(unwrap(element.attributes))
                .reduce(
                    (a, x) => Object.assign(
                        a, {
                            [unwrap(x.name)]: unwrap(
                                x.stringValue
                            )
                        }
                    ), {}
                )
            )(
                children ? go(children) : []
            );
        });

    return go(ObjC.unwrap(
        $.NSXMLDocument.alloc.initWithXMLStringOptionsError(
            strOPML, 0, null
        ).rootElement.childAtIndex(1).children
    ));
};

but always grateful for more scripting API …

[jessegrosjean]

@complexpoint

With NSXMLDocument methods it should be fairly direct

Ah right. I always forget (and don’t fully understand) how Objective-c stuff is available in that context.

@complexpoint

but always grateful for more scripting API …

I’ll see how easy it is. I wanted to hold off until there was also a way to access row attributes in the GUI, but now I think might be useful in other cases.

[complexpoint]

@mitchellm what is your typical (or ideal) use case ?

• You copy from Bike and paste to iThoughts ?
• Or save the whole file as OPML and import to iThoughts ?
• Something else ?

[mitchellm]

@complexpoint Thanks for looking into developing a script! I’ve done a few experiments and it seems the “smoothest” way to do things is to copy from Bike and paste into iThoughts.

I’m a “script dummy” … just learning about Shortcuts now. So once you have something you are happy with I may need a wee bit of hand-holding regarding how to implement it.

[complexpoint]

@mitchellm

the “smoothest” way to do things is to copy from Bike and paste into iThoughts.

Copying from Bike as OPML is fine, but it turns out that iThoughts doesn’t know how to paste an OPML clipboard – it only knows how to open an OPML file.

Paste to iThoughts is fine for pure outlines (it reads the plain text part of the clipboard) but for outlines with notes, it’ll have to be a:

• Save As OPML with Notes, or
• Save Selection As OPML with Notes

at the Bike end, and a opml file open at the iThoughts end, I’m afraid.

---

FWIW same goes for MindNode – it can read OPML files, but its clipboard handling is limited (like iThoughts) to plain text + a proprietary app-specific data format which is non-textual.

---

iThoughts pasteable clipboard content types:

["com.toketaware.ithoughts.itmz", "public.utf8-plain-text"]

MindNode pasteable clipboard content types:

["com.ideasoncanvas.mindnode.canvasObjects", "public.rtf", "public.utf8-plain-text", "public.utf16-external-plain-text"]

Expand disclosure triangle to view JS test code

// Run after copying from an app:
ObjC.import("AppKit");

ObjC.deepUnwrap(
	$.NSPasteboard.generalPasteboard.pasteboardItems.js[0].types
)

[chris.s]

To add my $0.02 to this – I’m a big fan of notes for outline rows and I use them heavily in my current outliner of choice, Dynalist. I find it really helpful to differentiate between information “about” a row and child rows, and there’s a shortcut (Shift-Enter) to toggle between the row itself and its note, creating it if it doesn’t exist.

One example is when writing up todo lists for projects, where a row representing a task might have both context (why are we doing this, so I don’t forget) and child tasks, and those seem like fundamentally different concepts:

I think an aside element would probably represent that well structurally, but equally adding row styles/tags/you-name-it and just having it as a child row of a certain format (muted, smaller, grey) would probably work okay for my use case – but it wouldn’t feel quite “right” structurally because it’s not really a parent-multiple children relationship. Plus as others have pointed out, having notes as a “first class” concept can also be helpful if you transform the outline into some other kind of document (such as a mindmap).

So a big +1 from me, and I do think it’s the kind of feature that can completely get out of the way of those who don’t want to use it

[complexpoint]

@chris.s

having notes as a “first class” concept can also be helpful if you transform the outline into some other kind of document (such as a mindmap).

Possibly …

tho I notice that in practice, if you copy and paste from annotated OmniOutliner to iThoughts, for example, the annotations just become structural subnodes anyway.

---

Distinguishing architecturally between different node relationships has a cost – the “notes” of a “subject” are no longer outlinable in that model.

If, instead, we just flag some nodes with special type attributes (e.g. note, as in the very successful TaskPaper model), and make those differences visible through a stylesheet, then we don’t have to lose their outlinability, or add code for two types of editor within one application.