New app, Bike

Posted by MadaboutDana
May 20, 2022 at 11:58 AM

Interesting, Jesse, thanks for the feedback. I’d be happy to run these tests again – it’s perfectly true that actually editing the middle of a very large document separates the sheep from the goats.

However, given the difference between the performance of my i7 MacBook Pro (now, alas, defunct) and the new M1-powered Mac, I do wonder if processing speed – but above all, OS optimisation – also makes a difference here. I’ll check it out.

By the way: loved/still love FoldingText. Please, please refocus, produce equally nifty iOS app, make large fortune from outlinersoftware forum members ;-)

Cheers,
Bill

Jesse Grosjean wrote:
>And just for a laugh, I opened the markdown version of the file (1.2 MB
>>in size) in various markdown apps. Here’s how they all did:
>>
>> ...
>>
>>Now granted I’m running these apps on a new MacBook Pro 14
> >This is interesting, but not my experience at all.
> >I’m on a 2015 iMac 27, maybe that’s making a big difference, but
>generally it still feels very fast.
> >I think you may not be doing the full set of tests…
> >Scrolling top to bottom, yes most apps can handle that OK. This is
>because it gives the text system time pre-render and pre-layout. Same
>thing if you resize the window or edit at the start of the document.
> >The problem, in my experience, comes when you scroll down into the
>middle of the document and try things. I’ve just retested (macOS 12.3.1)
>and I still see major problems:
> >1. Bear (good) – Best that I tested. I think they might also be
>using a custom built text view. Maybe it doesn’t matter for your
>use-case, but I can’t figure out how to really resize the window text
>dynamically. Line width is fixed. Yes you can change global preference,
>but that’s not really what I mean when I say resize window. Also if you
>do change that global preference while viewing test file you’ll find it
>very slow to update. Anyway I would say Bear passes test well, but its
>text presentation is less flexible them I would like for a text editor.
> >2. ia Writer. I scroll half way down… I resize the window: It’s very
>rough, screen only updates maybe once a second. I type: There’s a
>noticeable delay. I type and there’s a noticeable delay. I don’t think
>it passes, but it’s better the next apps (for this particular test)
> >3. Nota. I start wonder if we are doing the same tests. Forget window
>resize (which is the hard thing) if I type in the middle of a nota Moby
>Dick document it takes multiple seconds before any text shows up.
> >4. Taio. Same story as nota. Typing is pretty much impossible in the
>middle of the document.
> >I encourage a couple of other people to try these tests. Maybe my
>computer really is just to slow, but I know when I do these things in
>Bike on my computer things are instant.
> >Generally I use TextEdit to compare Bike against the default text
>system. It performs better than the listed apps that I’ve tried (except
>for Bear), but still has major problems. For example scroll to middle of
>test document and resize window. For me that often loses my place. The
>window resize also effects scroll position and I’m lost. Or other times
>it saves my place, until the first time I click anyway to place my
>cursor, then it scrolls off into nowhere land.
> >> You don’t have to slim own your app to the
>> point of having no real features at all to benefit
>> from fast loading and scrolling (and editing, for that matter).
> >Bikes editor speed is independent from feature design choices.
> >> So what’s his point? In short, what’s the point of Bike (I’ve got some
>very
>>large outlines in Dynalist, and they don’t slow down noticeably in any
>>of the apps – even though they’re markdown-compatible)?
> >My point is that I think outliners and text editors can be better than
>they are. So I try to imagine it and then I try to build it.