Open and save Bike .bike and .opml files (with minor caveats)
It’s an import/export flow mapping/preserving as much as possible
It is not a native Bike-style outlining experience
this is a work in progress and specs may change without notice
Structure & types
Headings → TaskPaper projects
Tasks → tasks
Nesting is preserved
Other Bike row types (body, note, blockquote, code, ordered/unordered lists, horizontal rule) come in as plain lines
Attributes
Any row attribute (data-*) becomes a TaskPaper tag
e.g. a custom data-foo=“bar” → @foo(bar)
A completed task’s data-done is kept as @done(date)
Bike stores a full timestamp; I keep the date and optionally drop the time-of-day
Inline formatting (bold/italic/highlight/strikethrough/code) imported as Markdown
Links are imported as Markdown
Bike’s internal row IDs
bike:// URL scheme is supported so .bike files import directly from anywhere
What’s dropped
Probably something I’m unaware of
It’s a one-way import: PaperTrail saves as .taskpaper, and when you export .opml your tags are mapped back to Bike attributes (so a @done task re-opens in Bike with its checkmark).
Note: this will be a separate new TestFlight for PaperTrail users who are also active Bike users (that’s not me!) so please state your interest below.
TestFlight
PaperTrail 1.3 (376)
Add:
Import .bike files (Bike 1.x and 2.0), keeping links, row ids and inline formatting
Export your document as an OPML outline
Export button now lets you choose between an HTML presentation and an OPML outline
Exports now confirm what the chosen format can’t include before sharing
OPML import now warns when attributes, metadata, or embedded HTML can’t be carried into TaskPaper
Inline @tag suggestions as you type
On iPad, the Style and Settings panels open as full-height drawers docked to the side
New iPad “Toggle Panel Side” command to flip the panels to the other edge
Keyboard shortcuts to fold or unfold the outline one level at a time (Ctrl+Cmd+9/0 or Shift+Cmd+9/0)
Built-in tag colours, plus colour-coding for @high and @low priority
Customise the Tool Belt: drag to reorder, add or remove dividers, and hide any tool (including Export and Style)
Duplicate and section-move tools in the Tool Belt
Long-press Add Task for a New Project or Note; long-press Duplicate to include an item’s children
New Settings panel grouping Help & About, the Tool Belt, Editing (Auto-Correction, Auto-Capitalisation, Tag Suggestions), and Advanced
Open the Welcome and Guide documents, or What’s New, from Settings ▸ Help & About
Shortcuts support: find items and projects, append a task, mark an item done, set a tag, and open a search
New “Support: Changelog” command
Change:
Tool Belt customisation now lives in Settings ▸ Tool Belt (the toolbar’s help button has been removed)
The Settings tool can be reordered in the Tool Belt but no longer hidden, so Settings is always reachable
Long-press the Settings tool to share a debug file (previously on the help button)
Improved parity of the search query language
Further speed-ups for editing, toolbar actions, and searches on large and folded documents
Command and Go To palettes now open as a full-height card on iPad
What’s New only shows major changes, not bug fixes
Updated the in-app Support link to the website
Auto-Correction and Auto-Capitalisation are now on by default
“Next Actions” searches now return the first task of each project
Large documents now fold on open for a faster load
@alarm reminders are cleaned up when you delete the tag
Fix:
The dismiss-keyboard button in the Tool Belt no longer flashes on screen when using an external keyboard on iPad
Focusing out of a project no longer leaves extra blank lines piling up between your projects
The date picker now shows every week of the month, including the final days, at larger text sizes
The date picker no longer cuts off the last week of the month on iPad in landscape, including with the Standard Display Zoom setting
Tool Belt icons no longer grow too large and overflow the bar at large accessibility text sizes
Adding a new task or note at the end of a collapsed item now places it after the collapsed items, not inside them
Searches that scope to a project with a leading slash now return matching items
Search paths that combine a slash with a named axis now resolve correctly
Items added while a search filter is active now stay visible until you change the filter
Tapping an alarm date-and-time tag in the filter bar now shows the matching items
Holding Up/Down across collapsed sections now moves the cursor smoothly on a hardware keyboard
Tool Belt keeps its horizontal scroll position when you change button visibility or order
The Tool Belt now stays clear of the home indicator with a hardware keyboard, including after rotating
The Tool Belt no longer grows too tall on iPad with a hardware keyboard
Sidebar focus and hardware-keyboard fixes
What’s New no longer stretches edge-to-edge on iPad
I’d be interested to know what features you use, and how, as I think about how I might be able to make them persist (in a future version that might have a hidden attribute layer, not in 1.3)
Hey! Sorry I haven’t been tracking the details of this feature/thread, but I see you are targeting .bike files? I think it would be much easier if you targeted Bike Markdown format?
Bike Markdown should be feature identical (can fully represent all Bike outlines) with .bike. And it would allow you to more easily round trip Bike inline formatting, since it’s just markdown.
Anyway, do as you see fit, just through I would throw that out there.
I’m targeting all the formats .opml was already partially done for plain import, .bike is well-formed code so only required a little more work
Edit: have looked at .md and .json and will keep my support to .bike/.html and .opml
…at least for now. Simply because I’ve already finished the feature LOL. Thanks though!
Edit edit: I might do something similar to your markdown approach to persist row ids and text formatting.
With five minutes just now of testing the four options above, I do not see the bugs that were reported earlier, where the first letter gets doubled.
However, I do notice that, when first-word capitalization is turned off, the first word still gets capitalized about 1/3 of the time. I have not been able to figure out a pattern for why this happens. I imagine this would bother users who truly do not want the first word ever to be capitalized.
Perhaps it is worth reporting that in my iOS keyboard setting, I have had both Auto-Correction and Auto-Capitalization turned on for all of the testing. Do you think that would affect the testing outcome?
(This also reminds me to suggest that you retitle the command item as “Toggle Auto-Correction” rather than “Toggle Autocomplete”, to be consistent with the title of the corresponding iOS setting.)
It seems that iOS sometimes considers "– " the start of a sentence and other times not. It’s infuriating.
Will give it some thought over the next few days. 1.3 is in pretty good shape, so I will do some more iPad and defaults testing and see what I think.
The issue with this small bug is that a couple of users made very loud noise about it, and one of my most negative reviews on the App Store is all about it (why that person didn’t just reach out but rather chose to vent in a review speaks to how annoying this must make some people)
I recall using several other apps that have also struggled with consistently capitalizing the first letter after the "– " … must be a frustrating iOS issue. I’ve been satisfied with how it’s working lately with Auto-Correct and First-Word Capitalization turned on. I hope others find this to be so as well.
A few more suggestions. Only take the ideas you like (of course!).
Some notes about the duplicate/delete tools:
It’s nice that we can long-press the delete tool to also delete its children. Can we get the same feature for the duplicate tool? (Ie, long-pressing duplicate also duplicates its children?)
If you make this change (or even if not), you might want to standardize the language describing these tools, as seen in the Help screen. (The two features, though they function similarly, are described differently right now.) For example, something like:
Duplicate: Duplicate selected lines. Long-press also duplicates children.
Delete: Delete selected lines. Long-press also deletes children.
I love how customizable the tool belt is. A few ways it could become even more usefully customatizable:
Could you let us move (or remove) the vertical dividers? The more I stray from the default tool belt setup, the less sensible/useful the dividers become. (For example, I now have 4 dividers for 8 tools, which offers little organizational benefit, and takes up space that could otherwise be used for more tools.)
Could you let users remove the export tool and the styles tool, from the toolbelt? I’m not sure why these need to be always shown. I expect to use them rarely enough that I’d be happier accessing them from the command palette.
(If I could remove the vertical dividers, and hide the export and style tools, I wouldn’t have to scroll my chosen tool belt, which would make me very happy!)
I like the feature to focus in/out via edge swipes. But I would argue that the swipe direction should be reversed, so that right-to-left focuses in, and left-to-right focuses out. Here’s why:
Swiping LTR (ie, left-edge swipe) is pretty universally recognized as “going back” (such as in a web browser or hierarchical file browser). When a user is focused into a branch, and wishes to “go back” to the parent focus (or to View All), they may naturally swipe LTR. Hence, a LTR swipe should trigger Focus Out, rather than Focus In.
There is also a spatial logic that emerges if you reverse the current swipe directions. Specifically: swiping right-to-left would shift the entire outline toward the left (in the direction of the swipe), thus moving an indented child node to the left side of the screen. Conversely, swiping left-to-right would move the focused node back to the right, making room for its parent node to emerge on the left side of the screen.
To try to summarize: In my framework, the swipe shifts the outline in the direction of the swipe; while in the current framework, the swipe follows the direction of focus (as graphically depicted in the focus in/out buttons … ie, “right” for “in”, and “left” for “out”)
Does this make sense? If the current logic still makes more sense to you, I will understand … the change I’m arguing for reminds me of the shift to “natural scrolling” in OS X Lion, for which there were good arguments for and against.
Miscellaneous:
There are several settings toggles, accessed only via the Command Palette, which users may not realize are available. You have a line at the bottom of the help screen pointing users to support options in the Command Palette. Consider adding a hint about the settings available there too?
Apparently there is are Welcome and Guide documents available … but I’ve never been able to find either. Where are they? How did I lose them? Could you let me revive them somehow? Maybe via the template or command palettes?
How about allowing users to long press on the Add Task button to show a menu for adding a new project or note? (Would let users hide the Add Project and Add Note buttons, yet still have these features available just a long-press away.)
Thanks for considering, and let me know if questions about anything!
This is the sort of well considered feedback and suggestions that makes my weary developer eyes light up thank you
I will implement most of your suggestions.
Some notes
The several toggles I will be adding to a Settings view which I resisted since the early days but now I think the time is right, in addition to Command Palette
Welcome and Guide are installed locally, so you can find them through Document picker > Browse > “On My iPhone/iPad” (they are created only on first launch and the app never touches them after that so they will still be there). I will try to surface them on Welcome view.
The swipe directions you may be correct, will give it some thought!
When I go to a collapsed item in TaskPaper and add a new task, note, or project, the new item is not indented as a child in the hierarchy; instead, it remains at the same hierarchy level. However, if I go to an expanded item that already has children, new items are indented correctly within the hierarchy. This doesn’t seem to work the same way in PaperTrail, unless I’m missing something?
When I open the sidebar, everything appears expanded. That feels a bit cluttered and distracting to me. I often find myself collapsing everything first before choosing a filter. Would it be possible for the sidebar to open in a collapsed state by default?
P.S. It only seems not to work when I have focused into a portion of the outline
… the change I’m arguing for reminds me of the shift to “natural scrolling” in OS X Lion, for which there were good arguments for and against.
thank you