At every level of scale (minutes to months) there’s a continual alternation between two thinking and writing modes:
fluid and unconstrained generation
rigorous and structured organisation
( people vary a bit in which they tend to start with, but we’re all moving back and forth between them all the time )
in the collection/generation/splurge phases of these alternating waves, we really want no technical distraction whatsoever – and your various widget-free text interfaces, from TP onwards, have been exceptionally good for this, and had a kind of magic. Wow … just typing here … but look ! it seems to get my structure …
Meanwhile in the structuring/editing/shaping phases of these waves, we appreciate power and some help with structuring. At this point, things like restructuring a fluidly generated nesting of hashes and bullet points can feel a bit of a mess. More outlining power makes it all simpler and quicker, and easier to understand. (No more fiddly counting of hashes, adjusting their number, and finding that we’ve got it wrong).
So perhaps one way of thinking about a goal might be to:
aim towards completely non-modal (purely text UI) entry for the generation phases of our bursts of thought (leading # to flag a header, leading hyphen to flag a bullet @key(value) to grab a date or tag, > to start a quote etc etc)
and keep the special outlining selections, and all their wonderfully powerful drag-drop, hoisting and folding, and querying power in reserve for when they will most be appreciated - in the structuring, editing, reshaping and searching phases.
It’s a curious thing … the modal route to (for example) setting a paragraph type or tag often involves fewer keystrokes, but it turns out that the simpler model (and smaller burden on memory) of a text interface feels much more fluid and friction-free.
On the other hand, after all that fluid generation, the nesting and counting of hashes and indented bullets, and changing our mind about heading levels can feel like a bit of a mess in pure MD. Its at that point that one wants to have some power-tools on the workbench … Automatic heading levels by indentation, drag and drop restructuring, hoisting and filtering and and reshaping and getting an overview.
in short it would be good to be able to:
stay entirely in text UI as long as one wanted to, with no need to reach for a mode switch at all for typing and entering meta-data, and then
step back and reach for all the modal power-tools when one needs them for overview, focus-shift, and reshaping.
Rob expressed perfectly what I would like to see. UI out of the way while getting text down, then I really appreciate the new additions to FT for Atom during the organization and restructuring phases.
I’m generally happy with the more traditional outlining functionality in FoldingText for Atom. However, there’s one thing in OmniOutliner that I like. The outlining nodes can have an optional note field where you can write text in a more typical text editor manner. I use it when I want to paste some else’s text that is related to the issue, put code snippets there and so on. For instance, if I paste a script to FoldingText for Atom, each line becomes a new outlining node. It’s not very useful in my opinion. With OmniOutliner you can put that code and other related stuff in the note area. The mind map application iThoughts and OmniFocus, etc, have a similar note area where I can paste all kind of stuff and which works like a more traditional editor.’
We can’t do any direct editing outlining or rearranging in the Marked.app view
With Atom already supporting text-editing views, and with FT2’s MD → nodeTree parser code already there, I wonder if there is an evolutionary path from the old pattern:
Static (non-editable) HTML preview, +
fluid text entry
with one-way traffic (text → html only)
to a new one:
Editable [H|FTML] with outlining power, +
fluid text entry,
with two-way traffic:
(F|HTML outline edits update the plain text MD translation, and
edits to the MD text version can also update the HTML outline ?
I have to say that I would quite like to work that way : - )
( if it were remotely possible )
(Like MS Word outline view vs paragraphs view, but a lot more fluid, appealing and innovative, and with tags, dates, filtering and querying)
A minor thing, possibly within reach of CSS and some stylesheet toggling, but I notice that in quick and unconstrained drafting mode (rather than in stepping back and restructuring or planning modes), I like to make even the disclosure triangles and indent lines invisible.
I’m unlikely to add this as implemented by OmniOutliner. At least not util I work more on FoldingText’s basic outline. For me those inline notes that some outliners have always broke the simple outline model for me… then all of the sudden you have text in your outline that you can interact with in the same way that you interact with the rest of your outline…
With that said it would be easy to add a separate notes “pane”. That is a text area off to the side of the outliner where you could view/edit notes attached to the selected outline item.
And maybe longer term I’ll change my mind about notes, but…
My goal is that you’ll be able to edit the normal outline in a more typical text editor manner… want to work towards that first.
@complexpoint Thanks for all the good ideas in this thread. I think they are most all worth exploring.
I’ve spent the last week working on some buggy issues with Windows, but am now getting back into the core outliner code where I’ll begin thinking about these things again.
The thing I’d like to do is to, for instance, quickly copy and paste some text, such as free from text from some comment, some article, code snippet, whatever, under some issue. Later I maybe polish that thing to more proper outline nodes. Now if I paste some random text or code from other person, each linefeed (line) creates a new outliner node. That doesn’t work do well. I usually or often eventually want to create new outliner nodes from that thing I paste, but the things I want to create as new outliner nodes usually are not neatly separated by linefeeds in the original text.
If I see something I know I need to work on later, I like to paste it under the relevant node so that I don’t forget or lose it later on. Then later on I may look at that quickly pasted note and create actual outliner nodes of it, if needed. This process is like extracting, distilling, abstracting or finding the relevant parts in the original writing to outline nodes in my process. I don’t want each line of some random text from other person to be an outline node in my document.
Currently when I paste some random text to FoldingText for Atom, it will make outline nodes of each line. It’s usually not what I wanted to do.
I really like the way this project is going but in writing up my outline which becomes a blog post I had to copy and paste into FT2 as I was really struggling with the formatting and swicthing stuff around. I found it was a lot quicker once in FT2 to be able to go into bits add and move stuff around. I guess I am using it much more like a markdown editor in this mode but I think the ease comes from being abe to type in characters to create lists, blockquotes, footnotes and headings etc. Moving this ease of freeform editing into types into FTA would be really good.
here is a screen shot of the two documents side by side
I would have to video myself working I guess to show workflow but the ease of editing seems to be a little lost in FTA
Yes right now FoldingText for Atom isn’t very good for writing Markdown. I expect this to come in time with a lot more work in the foldingtext-markdown package.
I see FoldingText 2 as part of the distraction-less text (Markdown) editors, in the line of WriteRoom, iA Writer, Byword, and all the others, with a few neat bonuses, which is why I bought it back then, though it appears that’s not what you had in mind when you wrote it (or at least only part of it).
The clean interface is definitely one of the reasons I like it: there aren’t any toolbars or sidebars, the text block is centered in the middle instead of the left and I don’t have to set a soft-wrap to keep the text legible, the hashes are positioned in the margin instead of the text block, things like that. It’s just a very nice environment to write in.
So the text block being aligned to the left in FT3 doesn’t appeal to me at all; it makes it feel like an editor for programming instead of writing, IMHO (of course, that’s what Atom is).
Also, in FT2, you just open the program, and write. In FT3, you have to start Atom, then press command-option-n to open a FoldingText outline. (I guess that’s what the standalone version is for.)
Totally agree about the tags input thing – when you want to tag something in FT2, you just write @. In FT3, you have to press escape, then t, enter some text, then press enter, then press enter again to return to writing.
FT3’s Markdown mode is still at an early stage, and will work very much like FT2, including typing @ for tags etc.
The current work is building a more standards-based platform than FT2 had, using a standard browser DOM rather than a proprietary Javascript model, and, in MD Mode, using CommonMark files and the CommonMark parser rather than a special outline-adapted dialect of MD, and a custom proprietary parser.
FT3 is able to be more standard in its Markdown handling than FT2 because of its deeper (HTML5-based) outlining capacity (no need to fork off to a different handling of tabs vs spaces).
It also allows additional Wiki and cross-file task management uses because:
Unlike FT2, it can provide persistent link targets for particular lines, and
also unlike FT2, it can make use of standard XQuery to define cross-file perspectives.
in FT2, you just open the program, and write
I personally hit just one key and start writing in FT3
(it opens the app, and creates or finds, and opens, today’s note file):
an editor for programming instead of writing, IMHO (of course, that’s what Atom is)
FT3 doesn’t actually use Atom’s editor (which, as you say, is for programming) – it’s a separate editor, which simply shares the (excellent, and well-suppported) underlying platform.
I am enjoying FT3 however I am still finding that it does not feel as flexible as FT2 yet, the outline mode feels a little too controlling and the look of FT2 as discussed with hashs outside the formatting etc. Makes it much nicer. I know the markdown plug in may address some of this and I understand the under lying structure is ten times better however I would not want to see the wonderful flexibility of FT2 lost in FT3. I will try and create a video to express what i mean by flexibility but I am still having to move my FT3 project into FT2 to be able to finish up the outline.
Right. I just meant the user interface – that to me, at the moment, the way I’ve used FT, FT3 feels like a writing app stuck in a programming app (or at least not like a dedicated writing app, but yes, that’s probably because FT3 is not a dedicated writing app) and I personally find that undesirable. The reason I feel this way is of course because I used FT as a writing app (and a Taskpaper editor) instead of as an outliner and why I’ve previously not used e.g. TextWrangler for general writing but things like iA Writer and later FT.
I can see how the text block being left without a soft wrap is useful for outlining because a slim, centered text block centered doesn’t allow for a lot of sub-levels before everything becomes a mess.
I can also imagine there’s a whole lot of things one can do with theming here, maybe it includes moving the text block.
On a side note, you’re not really suggesting people buy a 36$ app just to be able to instantaneously write? (By the way, I totally appreciate what you’ve been and are doing for FT – you sure you don’t work for Hog Bay Software? ;-))
One thing that I personally appreciate about the Atom framework, and which I wasn’t getting in FT2, is using the ⌘\ Tree View with ⌘⇧F project.
( Also useful to have a raw text editing pane (with Markdown preview if you want) a ⌘N away in the same app )
The key advance for me, though is the links. Atom > Edit > Copy Path gives a link to a specific paragraph which I can use from DevonThink or any other app which handles links. The FT2 ftdoc:// url scheme is useful, but its a built-in limitation of Markdown that you can’t have durable link targets. Edit and the link is broken.
The FT3 links are durable as well as powerful. They make the difference between a file list and a wiki, and work very well for cross-file queries and reports.
(By the way, I totally appreciate what you’ve been and are doing for FT – you sure you don’t work for Hog Bay Software? ;-))