Some thoughts on Bike Outliner.

[SomeoneOnWorld]

It’s been about a year since I tried to integrate this application into my workflow, but without much success. Before writing my account, I would like to emphasize that I am a fervent believer that productivity is maximized with software that operates with and on plain text. Applications like iA Writer, Ulysses, TaskPaper, and similar ones are appreciated for their simplicity and also for the unequivocal way they operate on simple text files. These are files that can be easily exported and manipulated for any other purpose.

Most Outliners are extremely focused on structured to-do lists and project management, an extremely limited view of the possibilities of an Outliner. In my use, I understand an Outliner as a space where I will grow and develop manuscripts. From initial ideas to a final version (I already write more about the final version).

I was happy to discover Bike Outliner because, a priori, it didn’t have a strict emphasis on project and task management. It seemed like an ideal place to develop a written text. However, as I used the application, its enormous limitations made its use pointless for this task.

Review of the current state of Bike Outliner

To make it easier, I will break it down into topics reviewing my view of the application’s functions.

Outline manipulation environment

This is the application’s highlight, as manipulating rows and columns is extremely easy. This helps with rearranging and composing texts. In my view, the possibilities offered by Bike 1 meet all the requirements. Perhaps the only thing missing is, in fact, column filtering when searching, something already implemented in Bike 2. On this point, therefore, Bike Outliner is impeccable. Furthermore, the option for internal links is of enormous help.

Writing environment.

If the Outliner manipulation is impeccable, the writing environment is paltry. The application offers the most rudimentary text editing: italics, bold, and highlights. Any type of minimally more demanding writing cannot be developed within the application.

This fact surprises me because Bike Outline operates on an .html file and there are extensive .html libraries to render, for example: mathematics, footnotes, citations. In fact, markdown itself is just a simplified markup for .html, which is why I don’t effectively understand the reason why Bike Outliner does not natively operate with markdown blocks.

On this point, it is worth noting that the features I highlight (citation, footnotes, mathematics) are useful for various writing professionals (journalists, academics, writers). People who are really very interested in this type of product (like me). The absence of these resources makes any use of Bike Outliner in these workflows unviable. It hinders more than it helps.

Formats and export

This is another bottleneck of Bike Outliner. The .opml format is extremely limited because, in fact, the text of a column is stored as an attribute of a tag in an .xml, something like <row text="row text"/>. In this aspect, all formatting in the text is lost. Obviously, to circumvent these problems, Bike Outliner developed its own .bike format, which is nothing more than an html file, where the text is properly encoded within a tag, not as an attribute.

Exporting to plain text is useless for future applications and the bike format also doesn’t help with integrations. Thus, I consider this aspect extremely limiting, which makes any workflow that aims to integrate Bike Outliner with other applications unviable.

Suggestions for future development

I would like to address future suggestions for the application. In the Outliner manipulation part, as I said, the work is impeccable and I have no recommendations. Therefore, I will focus on the other points.

I believe that the Writing Environment and Formats and Export parts, discussed in the previous item, should be thought of as a whole. At this point, I ask: what is the goal of Bike Outliner? To be an application in itself or to provide future integration?

Defending the viewpoint that Bike Outliner should be part of a larger workflow, I would like to recommend, as soon as possible, that means be developed for the writing environment to integrate more advanced resources, for example: mathematical equations via MathJax; footnotes; subscript and superscript; citations in the pandoc style (i.e., it could just be a highlight in the text, like a different color for the form [@citekey] or even a “box” around the text citekey.) All these topics are not difficult to integrate into an html file, natively used by Bike Outliner.

Assuming that Bike Outliner has this capability, it is natural to export the file to a plain text format .md or .txt with markdown markup. For example, in the case of markdown, export the first six levels of the outline as (h1 ~ h6) and the subsequent rest as simple paragraphs, with the possibility of implementing a marker so that a line is exported as a paragraph, for example:

- H1
- - H2
- - - [x] Paragraph
- - - H3
- - - - [x] Paragraph
- - - - H4
- H1
- - [x] Paragraph
- - H2 
...

In this case, the lines marked with [x] would be exported as paragraphs.

The goal would be for Bike Outliner to be the ideal place for texts and manuscripts to be initially developed and grown, to the point that when exported, they could be later manipulated for any purpose via pandoc.

Obviously, I do not expect, nor do I believe it is important, for Bike Outliner to be a complete application, from the starting point to publication, far from it. Therefore, I do not expect Bike Outliner to prepare an entire manuscript, up to the final version for publication. I only suggest that, if the plain text principle is used, the possibilities of Bike Outliner’s applications in the most diverse workflows will be dramatically expanded for many, many writing professionals (and other related ones), while still preserving the simplicity and focus of the application on the conception of written text in a structured way.

Final Considerations

Seeing the current developments of the application, as I said at the beginning, it raised some concern in me, mainly due to a lack of focus or a more opinionated form in the software’s development. I’ll give an example: I constantly have to prepare slides for presentations, whether in seminars, lectures, and the like. I tried various ways, from the native Mac application (slow, annoying); workflows with reveal.js (unnecessarily complicated and with more focus on ornaments than text); even with the breamer class of LaTeX (more focused than the other two, but the portability of the text (markup in TeX) weighs a bit against its use).

In the meantime, the iA Writer team launched iA Presenter and I confess that I tested the application for two days and already bought it. The workflow is opinionated, the themes are limited, but none of this matters, since it has the basic functions provided by Markdown and the export formats are excellent. In short, it’s an application that I open and start working on, without any distraction or headache. They deliver a ready-made workflow to me, extremely well-organized and well-done. I can develop my work and make other integrations without many problems. The virtual limitations of customization (image placement, text size, etc.) have no impact on the final work.

Basically, this is what I miss in Bike Outliner; it’s not clear what the application’s objective is, what problem it tackles. Would it be a new project manager? A place for structured writing? Structured writing, but of what type? Is there any direction that the implemented resources point to?

Another point that brings me some concern is the API system.
Although it is interesting to develop an API for plugins and other customizations, the vast majority (of users) are not interested in this type of thing. The fact that I pay for software is so that it facilitates my work and doesn’t give me more headaches. Obviously, I have no (and many others don’t) desire to write a plugin in .js, much less “waste time” reading yet another software documentation. My goal is simple: open Bike Outliner and write, nothing more than that. After that, export my result and handle the final part of the work appropriately. This API part can even be a shot in the foot for niche applications like Bike Outliner, as it allocates a lot of effort to sustain an architecture that will be used by a small part of the users. Time that could be allocated to the development of features in a more opinionated way.

To conclude, unfortunately, despite trying in various ways, I couldn’t fit Bike Outliner into my workflow and, seeing the recent developments, in the near future I can’t see how Bike Outliner could be used as a text development resource through structured writing.

Finally, I don’t want this text to be read as an attack, but just a reflection. Obviously, the developer’s opinionated is different from the user’s opinionated. However, the true strength of opinionated resources lies in the cohesive and solid way they integrate features, without depending on external items, and also in the clear direction with which they develop the features, delivering a work environment conducive to the user.

[jessegrosjean]

@SomeoneOnWorld

Finally, I don’t want this text to be read as an attack, but just a reflection.

It’s not! Thanks for all the thoughtful feedback. I will respond in more detail after a bit of thought.

[complexpoint]

@SomeoneOnWorld

I couldn’t fit Bike Outliner into my workflow

The centrality of outlining makes Bike central to my workflow.

It’s nested structure is close to that of thought.

There is an inescapable tension between plain text and outlining, which Jesse’s FoldingText application explored quite vigorously.

What emerged, for me at least, is that if you want deep outlining, and you want to do it properly, building around the relationships between key points and supporting points (rather than topics and sub-topics) then plain text (essentially a serialisation) simply lacks – and, I think, will always lack – both the requisite structure, and the requisite separation of structure from formatting.

[SomeoneOnWorld]

The centrality of outlining makes Bike central to my workflow.

Outlining is also central for me too.

What emerged, for me at least, is that if you want deep outlining, and you want to do it properly, building around the relationships between key points and supporting points (rather than topics and sub-topics) then plain text (essentially a serialisation) simply lacks – and, I think, will always lack – both the requisite structure, and the requisite separation of structure from formatting.

I think there is a misunderstanding here, when I spoke about plain text I mean an .md, .txt format with some markdown markup, not just an plain text without any formating. This Bike Outliner already does, when it exports the outline as plain text with tabs.

What I would really appreacite is that Bike Outliner improves que capacites of text editing inside Bike Outline, because this could fit much more workflows. (For example, the addition of math, citation, subscripts, etc.)

Today, the unique way for me to use Bike is to basically use it as a kind of task manager, when I put, for example:

- Chapter
- - Idea 1 
- - Idea 2
- Chapter

After, I need to open a new text editor to format my files. This kind of workflow is far from any good, because I need constantly to change aplications. For example, any good text editor: BBedit, Sublime Text has the ability to folder text, so I could simply write markdown, fold the text and keep my production. This is much more fluid than Bike, because I am in the same environment.

With ‘good alternatives’, why my complain? My desire for use Bike is simple. The app does a suberb job in manipulating rows and internal link, this are huge advantages for outlining. For manipulating the outline (as blocks of texts), I never saw anything better.

Now, if Bike support the features that I suggested, I would do the following:

- Chapter 1
- - Citation 1
- - Comment Citation 1
- - Idea 1
- - Citation 2 
- - - Sub-Topic

Then, I would develop Comment Citation 1 and Idea 1 in a fully paragraphy. Maybe merge some of them, and so on. In other words, the Outline would really become a information aggregator where I could, starting from small pieces of information (citations, ideais, links), writing until get the whole thing. Bike already has a wonderfull link system, so this would be a very good match.

Now you may say that in Bike you already can do this. The answer is no. Because, imagime that I did all this in Bike and want to export my outline (now a full piece of text). With the plain text option, I will lost all my formating and need to correct it by hand in a lot of spots (also, there are levels that would be paragraphs and not headers). So, the post-process of Bike is extremely mess (I really tried it one time) and this make the initial benefits vanish. (Even parse the .html was not good).

In conclusion, maybe we are talking about the same thing, but the actual editorial capabilities of Bike (italics, bold, etc.) fulfill your needs. My complain is that this editorial capabilities are too narrow and rudimentary, what make very difficult to truly use Bike in process of outlining, i.e., starting from small pieces and develop the whole thing inside the app.

[complexpoint]

Not sure that there’s a misunderstanding

FoldingText explored exactly that space – Markdown as a medium for outlining.

Markdown struggles, in practice, for outlining, over some ambiguities about what is structure and what is decoration in the markup.

The formal properties of XML / HTML documents lend themselves much more directly to the consistent representation of structure, and harvest the support of a whole infrastructure of standard tools.

[SomeoneOnWorld]

The formal properties of XML / HTML documents lend themselves much more directly to the consistent representation of structure and harvest the support of a whole infrastructure of standard tools.

Surely, I did not ask for Bike to work upon an .md file; maybe this was the misunderstanding. For sure, .md is not good for an outline. What I asked is the ability to export in .md.

Since the internal format of Bike is an html, I think (well, I cannot see the source code, so now I can just guess) that adding better edition support for the blocks of texts is not that hard (because most of them already have libraries for html render). Maybe some concerns about performance (i.e. MathJax), but this is not that serious in front of the improvement.

The internal format of bike can be anyone, and there is doubt that the Bike own .html is very well made. The point is that the export options are very poor, as I wrote in my first comment. The .md file is not intended to be the native format for Bike, far from it. The point is the ability to export the whole outline in the .md format for further processing.

My desired workflow:

1. Bike Outliner:

• Starting list of sources and ideas
• Writing around these topics and manipulating them
• Finishing the writing from the sources
• First version finished
• Export to .md

2. Markdown Editor + Pandoc:

• From the exported .md, some more polish and final adjustments.
• Use pandoc in the .md to generate the appropriate final format and further items.
• Final version of the text

[complexpoint]

Bike -> Pandoc doesn’t, of course, need to pass through the structurally reductive bottle-neck of Markdown.

See, for example:

Blog post: Scientific refereeing using Bike Outliner

Hi there, I have recently published a blog post on how I use Bike as a scientist to streamline my participation the peer review process: Scientific refereeing using Bike Outliner. Potentially of interest is that I have created an XSLT stylesheet to more reliably convert Bike outlines to idiomatic HTML, which can then be processed by Pandoc into reasonable Markdown. This is important because of the plain text and Markdown format requirements of most scientific conference peer review systems. You…

For moments when an export serialisation to Markdown might be useful, I did write and use this for a while:

BIKE Outliner :: Save As Markdown

but I may not rewrite that now – I expect that better alternatives will emerge.

[SomeoneOnWorld]

I asked for .md, mostly because it is the more readable format supported by pandoc. Although my main typing system is still TeX, I am forced to collaborate with people that use the disgraceful Word and from all my extensive testing, I found the combo pandoc + markdown the most reliable for this user case. (The unique features of pandoc that are really useful are the citation processor and tex -> mathml for Word. If you try to convert from docx, tex or other format rather than the plain text .md, the results are very messy).

When I started using xml I spent some time with xslt, but the problem is that there is just one good processor for xslt (that covers the last specification: if I am not wrong, the xslt 3.0). That is the saxon, written in java. This library is not open source and is pretty priced. Also, the older specification for xslt lacks a lot in power.

In my opinion, in light of the good libraries to deal with xml (e.g., lxml in C with python bindings), the use of xslt is just justifiable just in very specific user cases.

My approach was like yours, but instead of js I used python. I also added some custom marks, like /x/ in the beginning of the line to say that this is a header, so the row with /x/ is converted to the appropriate header # and all other to paragraphs.’ But this was a poor workaround, the experience of writing non-supported syntax in Bike was terrible.

Maybe I can come back to this script, but this pseudo-solution is trickly, I would prefer a hardcoded solution for better seeing my outline and ideas. For the writing process, I found that Bike is not suitable, but as a link and information aggregator it was wonderfully good. I could do much more in Bike than some collegues in bahemots like Scrivener (where you need to take a course even to open the software).

Bike simplicity and power is unmatched, but I still hope to see it as a competent writing environment to be a complete outline solution. Again, what was not so good in the experience with Bike was the need to change apps constantily, one to write and other to see outline, this lack of integration of the outline information and the text development was a big loss for the workflow.

[jessegrosjean]

Thanks again for all the thoughts.

@SomeoneOnWorld

Basically, this is what I miss in Bike Outliner; it’s not clear what the application’s objective is

First goal: Bike is an improved TextEdit style text editor.

Like TextEdit, I want Bike to feel lightweight and be quick to create a new document and start typing. Outline structure, folding, focusing (+search in 2.0) are the core improvements. This is the first use case–A nice place to think, write*, and organize text.

I think Bike hits this target well.

*write - I think I mean a less demanding type of writing then what you are trying to use Bike for. I think Bike is great at writing, but I would agree it needs work when it comes to more formal document creation.

---

Second goal: Allow Bike’s light weight editor to be used for more specific purposes.

Bike 1.x has a rich data model, it’s not just indented text. Rows have type and identity. Rows and text runs both allow arbitrary attributes. In Bike 1.x these features are used to implement internal links and rich text formatting, but there are many more possibilities.

Bike 2.0’s extensions allow me and others to build off this model to provide solutions/features that don’t make sense to build directly into the core.

I don’t expect this extension system to turn into something huge like VS Code or Obsidian. Instead I expect to (over time) ship a core set of official extensions with each Bike release. For example a calendar system, writing tools, maybe document publishing? Enable, use as you like.

That will be the experience of most users, they won’t even really need to know that the features are provided by extensions. Of course for users who like to tinker and customize they will have many more options.

@SomeoneOnWorld

I ask: what is the goal of Bike Outliner? To be an application in itself or to provide future integration?

The goal is a flexible core that can be used in many ways. I definitely aspire that Bike can be made to work in multi-app workflows.

Bike’s html based format is intended to facilitate this. It’s a well known format that’s easy to parse and view. It’s extensible in various ways. I don’t see any better options for representing Bike’s full set of features.

With that said, I agree it’s not an easy fit for a non-programmer to get that data into a markdown driven publishing process.

@SomeoneOnWorld

… Bike Outline operates on an .html file and there are extensive .html libraries to render, for example: mathematics, footnotes, citations …

HTML is just the storage format, not a runtime technology for Bike. At runtime Bike is performing its own layout and drawing, it can’t take advantage of HTML libraries for this. I would like to support mathematics rendering, but it will require a chunk of work on my part to make it work.

@SomeoneOnWorld

requests: markdown export, footnotes, citations, mathematics

I would like to get Bike working well for your writing use case and these are all reasonable features that I think would fit well into Bike. Currently I’m busy just trying to get Bike 2.0 done. I’m late and later at the moment, but it will get done someday.

Once Bike 2.0 is out then I’ll have time to start working on these sorts of features. I’ll have lots of mid leave features to think about, bump this thread after 2.0 to get my attention earlier

[Gorgonzola]

I think, in a nutshell, OP is looking for a one-stop solution to Write → Publish.

That’s usually the goal dedicated writing applications pursue. But Write → Publish means many different things to many different people, and it’s hard to imagine that a minimalist app like Bike would include all the features on par with word processors that let you design a page down to the last millimetre. There are simply too many variables, and the apps that cover every possible use case tend to look and feel like bloated, legacy software (which they are).

When dealing with open formats like markdown, how do you handle representation of rich formatting that isn’t unified under a single specification? Highlights, superscript, subscript, underscore, even the CommonMark spec which includes none of those things is a f**king 113-page document if you try to print it on A4.

The other question is, how do you represent a tree-structured document in a linear format in a way that makes sense for everyone?

Simplicity means following simple rules. And unfortunately, the same rules don’t work for every writer out there.

I think an extensible core with community-driven extensions is great because it allows for more granular customisation in possibly quicker turnover compared to waiting on endless feature requests. It also allows for much more flexible workflows where users can decide what their goal is instead of trying to shoehorn a workflow into an app that wasn’t designed for it. But it requires an additional bit of work, just like everything else.

Yes, I would like Bike to transform row types into their markdown equivalents. Yes, I would like it to be able to flatten the outline and make an .md file with basic formatting translated into markdown. Yes, all those things are possible already in Bike 1.0 with automation that takes additional effort and isn’t easy to implement.

I can’t speak for citations and mathematics and other advanced text formatting features because those are features I don’t use. But is it impossible to imagine a GUI compiler extension in Bike 2.0 that would allow for user/community based presets, and transform .bike files into whatever format they want?

[jessegrosjean]

@Gorgonzola

I think, in a nutshell, OP is looking for a one-stop solution to Write → Publish.

I’m not sure, I read it as they want to start editing in Bike using features:

• Rich text
• Outline structure
• (in future citations, footnotes, math)

And then be able to export that start into a Markdown based publishing system.

That goal makes sense to me and I think aligns with Bike. To me it sounded like the big problem was how to get the document started in Bike into Markdown system, without losing information. For example, I’m not sure if any of the existing export scripts handle inline text formatting to markdown.

It’s true, you can accomplish some of this in Bike 1.x with AppleScripts, but it’s also true that it’s not a particularly easy job. Writing the scripts is hard, using them also requires some knowledge and fiddling. Maybe hardest is just knowing what’s possible. For example, I should know, but I’m not sure if any existing scripts will export bold, italic, and links as markdown.

I think extensions can help with this, and especially built in extensions.

They will add a layer of features that aren’t built in to the core, but are shipped with Bike and don’t need any extra effort (other than discovering or enabling) to use. The extension code will also be open source, so possible to improve or modify without requiring me to make a Bike release.

@Gorgonzola

But is it impossible to imagine a GUI compiler extension in Bike 2.0 that would allow for user/community based presets, and transform .bike files into whatever format they want?

I’m not sure I follow exactly, but I hope someday to make a “publish” extension, that will take your outline and bundle it up in various ways to create a PDF, or set of HTML, etc. And I’m sure it would have many configuration options.

That’s a goal, before focusing on that I do think that Bike needs to fill in some missing pieces such as image attachments, footnotes, etc. Then work in publish.

[Gorgonzola]

@jessegrosjean

For example, I should know, but I’m not sure if any existing scripts will export bold, italic, and links as markdown.

Actually, Apple Shortcuts will do this quite nicely, especially as of this fix:

Then, if you take something like this shortcut (warning: this will break your outline), you can convert an outline like this:

into markdown that looks like this:

# A heading
Some **rich** _italic_ text with a [link](https://www.example.com)

# Another heading
Some more **rich** text with highlight (won’t translate to markdown)

And strikethru (also won’t translate to markdown)

> A quote

*A note*

## Second level heading
- [ ] A task
- [x] A done task

Some more stuff here

### More headings
* Lorem ipsum dolor sit amet.

#### Even
Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. 

##### More
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.

###### Headings
Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

# Yet another heading
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et **dolore** _magna_ aliqua.

[jessegrosjean]

@Gorgonzola

Actually, Apple Shortcuts will do this quite nicely,

Wow, that’s awesome!

Unfortunately, it’s also illustrating the problem with external automations… I can’t seem to make it work! It’s working for row types, but not for inline attributes?

[Gorgonzola]

Inline attributes (bold, italic, links) should be picked up by the last step of the automation that prints the entire outline to markdown and copies to clipboard. I’m sure there’s a way to make it replace text in the rows too, but I didn’t want to have it completely obliterate the outline

[jessegrosjean]

Here’s a quick bit of coding inspired by this thread:

It’s showing new extension API to initialize a row from markdown and then to serialize it back into markdown. I’ve long delayed any official markdown support because it seemed to mean I would have to decide what is the standard way for Bike to represent an entire outline in Markdown.

But I now think it will be useful to support inline text and row level read/write in a standard way at the extension level. And I can continue to postpone structure serialization decisions until I have time to think more. Won’t post this release right away, but will be in next release.

[SomeoneOnWorld]

Thanks @jessegrosjean for the explanation. Now it is clear that the extesion are meant to keep the core tiny and add functionality in demand for some user cases. I was afraid of an Obsidan nightmare scenario, but this is not the case.

Also, you absolutely correct about my points: the biggest problem is how to get the text out of Bike as you said:

I’m not sure, I read it as they want to start editing in Bike using features:
Rich text
Outline structure
(in future citations, footnotes, math)
And then be able to export that start into a Markdown based publishing system.

This is exactly what I want! As your advice:

Once Bike 2.0 is out then I’ll have time to start working on these sorts of features. I’ll have lots of mid leave features to think about, bump this thread after 2.0 to get my attention earlier

I will remember you when Bike 2.0 be out!

[jessegrosjean]

Some markdown format work in this release, try it out:

Bike 2.0 (Preview 246)

Added Bike Markdown format (.bikemd) Added Edit > Copy > Copy as Bike Markdown Added to/from Markdown API Improved pasting links Download: Downloads Extensions API Known Bugs