FoldingText 3

FoldingText
1

Hi All :wave:!

I know we’ve been silent recently so I wanted to share a quick sneak peek into what’s going on with FoldingText.

We’ve been thinking hard about what the future of FoldingText looks like, and I’d like to share what we have at this point. This is not a release post; there are still rough edges and more work needs to be done before we can open it up for private beta. The good news is that I’m using it daily and it is very stable even now.

We believe FoldingText is far too powerful and expressive to be kept as a single document editor. FoldingText 3 will be a database backed application that allows you to take quick notes, and keep all FoldingText notes consolidated. FoldingText 3 will offer full text search for the database, and importing your existing documents will be trivial.

This is a fundamental change to how FoldingText is designed, but it opens up exciting opportunities with what we can do with FoldingText. Think autocompletion of tags across multiple documents, modes that can function without having a specific document open, attachments, linked documents, and much more. At this point in time, we’re just starting to think about what we’d like to introduce with the first launch, so you’ll have to stay tuned to see what kind of tools we build atop this. Of course we’d also love to get ideas from you about what you’d like to see in FoldingText 3.

image

FoldingText 3 is a major rewrite as well as a major re-imagination. To that end, extensibility and some existing features of FoldingText 2 may not be available at launch. It’s something we would still like to do, but to have full feature parity with FoldingText 2 will not be a trivial task and will delay the beta.

FoldingText 3 will also not be a free upgrade. The only way to ensure development can continue with FoldingText will be to have some sort of perpetual payment model. I’m afraid we’ve still to decide the specifics, but we believe that FoldingText can only thrive when customers support the development effort.

FoldingText 3 is also written in electron, so we aim to work on a windows version after the release of the Mac version.

image

We’ll keep you posted regarding the beta and when it’ll start. There’s a lot to do still, but we wanted to give you a sneak peek into what we’ve been up to.

Regards,
Mutahhir

2

Happy to see development in Folding Text. I personally use it less now— over the past 18 months I’ve shifted to using an iPad Pro as my primary computing device. That said, I still return to a macOS computer now and then.

With FT3 moving to a database model, is there a workflow for interacting with “external” documents? Scrivener had (has?) the ability to sync to plain text files, which made for the best of both worlds: you could work on documents in Scrivener, but still sync the majority of your work with any Dropbox enabled text editor. Any such thoughts for FT3, or would FT3’s database/note-store facilitate manual import/export only?

3

I understand that change is usually difficult for those who are already users to accept. It makes sense, they self-selected into the group that liked and used the thing when it was the original thing, so by design they are likely to not like the thing as much when it changes to a new different thing.

This makes me sad. FoldingText was unique and powerful because of what it did with a simple text file that I could open at any time. It did this amazing thing of adding a layer of interaction and clarity. It was the closest I’ve seen an app give me the benefits of rich text, the added ease of reading and scanning a document and its sections and recognizing important or familiar parts, without sacrificing the plain text nature of the file, and it was easy and fast and was just one window per file and was that simple to use. I’d be looking at a file, and I’d think “you know what this needs, this needs the FoldingText treatment”, and I’d have it open in a FoldingText window in a second, do what I need to do, Command+S, Command+W, done!

For my use, FoldingText is moving into an area where there are already established competitors like Ulysses, Bear, and The Archive, that, and I sincerely don’t mean to be discouraging, are firing on all cylinders. As far as I knew, no one was doing what current/previous FoldingText was doing - giving me this lightweight toolbox to work with plain text files. It seems there are plans to add some kind of extensibility to the new design, which will give the new FoldingText unique features, but it’s unfortunately taking a backseat to the database model which is… I guess not for me.

I hope other users, both current and new, love the new FoldingText, and I hope it’s great and kicks ass :slight_smile:

4

Sound great would love to know more about the tech deployed in the electron version. I’ve been playing around with this a little specifically in relation to markdown and would love to here some details on workflows and approaches. Look forward to FT3

5

It’s something I really want FoldingText to have too. I don’t know the details on how that’d look yet, and it may not be there at launch, but it’s not something we’ve ruled out.

6

Thank you for your feedback. I agree that this is a departure from the original FoldingText. I also appreciate that there are other editors out there that are doing a great job.

I have always felt that FoldingText could be much more than just an editor. The database, while I agree has it’s side-effects, is not intended to make FoldingText heavyweight, instead it opens up a move to a model where you can come to FoldingText to write out what’s on your mind. For me, there’s still no tool that comes close to the flexibility that FoldingText provides for writing out what you’re thinking. Notes, thoughts, interspersed with tasks, or running a pomodoro timer on the work I’m intending to do this afternoon, all kinds of workflows can be done well within FoldingText. However, and this is probably just me, but I hate saving, giving names, and managing all my disparate text files that cannot talk to each other and I cannot get an overview of. This version of FoldingText intends to be a central piece where you take a second to dump your brain and move on. It will eventually hook into your other systems and perhaps allow you to write plaintext, and consume in a variety of applications that you use on your phone or watch etc.

Regarding FoldingText’s unique features taking a backseat to the database, I don’t think this will ever be the case. I would like the unique features be augmented with the database, allowing you to leverage your collective writing in a way that helps your daily life, and not the other way around.

Thanks again for the great feedback, I’ll keep all this in mind, and I hope you keep an eye on how FoldingText develops.

7

Sure, I’d be happy to answer any questions you may have. Honestly, I have to think about FoldingText’s extension features from the ground up because it’s no longer a native Mac Application. That project will start once we have a proper release out.

8

I’m open to this idea, I’ve just discovered nvALT, having a folder on Dropbox really keeps my notes under control (organised is not really the key idea for me, that’s a waste of time IMO). However I really experience trepidation when I see the word ‘database’ used in this context. Maybe it is being used as a metaphor if so great, but the idea of something that can get a corrupted index, records don’t update correctly I would find that horrifying. Maybe you can set my mind at ease?

9

database and subscription. good luck.

10

FWIW the model Ulysses uses is built on sqlite and lets one find the raw text easily if needed. I have 900k words in it and it’s blazing fast on every device. I switched from NVAlt bc syncing on Dropbox was slow and conflict prone in practice, & linking notes by file name as opposed to a fixed ID in the database was highly breakable. I think this approach for FT looks promising .

11

I’ll be interested to see what you come up with. I admit I’m not initially enthusiastic mainly from the database structure and the early glance on how it’s implemented on your screenshot. I’m hoping that will easily be hidden and replaced with something based on the selected document’s hierarchy.
I look forward to hearing/seeing more.

Pros:

  • Windows version – I LOVED the implementation of Folding Text in Atom, partly for this reason. Finally I could track client/project text files in a program I liked and could make use of.

  • Attachments and linked documents would be very welcome.

Cons

  • Still no iOS version? That’s the main reason I’ve moved away from the current version of Folding Text. I use my iPad a lot now.

  • Database structure – this is not ideal, though if the the database structure sits atop a normal file structure of text files I’d be happy with that. I don’t really need another text system that requires me to export a file in order to access it in another program.

  • What’s going to differentiate this from Bear, Agenda, Ulysses, and any one of the number of text editors following a database and subscription model?

12

“FoldingText 3 is also written in electron”
I lost interest right there.

1 Like
13

Exciting to see further development on Folding Text. I hope it goes superbly.

As I understand the changes you outlined, I’ll be moving away from Folding Text. Several reasons. If development went in a way that avoided these, it would be awesome and I’d love to support FT going forward. Regardless, best of luck with it.

  1. My ecosystem relies on trivial access to plaintext, perhaps with Markdown. If the database sits on top of plain text transparently, super. If not, that’s a show stopper.

  2. I understand the attraction of a subscription model for software. In fact, for lots of software, I think it serves the interests of both developer and user very well. However, I think that’s generally more true of apps for consumption than production. For example, the podcasting app Castro is going to a subscription model. If they suddenly go out of business and Castro becomes inoperable, I just have to find a new way to listen to podcasts. So, I’m happy to support their subscription model. I’m not willing, however, to make access to writing I produce dependent on FT (or any other program) remaining active.

Of course, it FT’s database were transparently on top of plain text files, I’d be a lot less concerned about both of the above. Losing some tagging info if FT became inactive would be a reasonable risk.

Less major issues.

  1. Lack of iThing version. You know your current and desired audience best, but I care much more about moving between parts of the Apple ecosystem than between a Mac and Windoze.

  2. Performance. Okay, I get that complaining about performance of software that isn’t even in beta is really stupid. But, hearing that FT is moving to Electron is not encouraging. I love a lot about the Atom editor, but its slowness seems to be inherent in its Electron-ness.

All in all, I’m not seeing the value proposition beyond Atom plus some extensions for folding and nv-alt like functionality on my Mac, Drafts or Editorial on my iThing, and a common cloud location for files from both. I’m not thrilled with that solution and would love to see something better.

Thanks for all your work on FT to date and best wishes for its thriving future!

14

With the proposed move to a database application, lack of iOS versions of the app, and finally the move to a subscription model, I just don’t see myself having any interest in FT3. Hope it is successful for you, but unfortunately it is not for me.

15

I don’t get the Database approach.
What I’m using FoldingText for is editing source documents, saved in plain text files, versioned in SubVersion or Git which will then be transformed into several target formats (HTML, PDF and ePub).
So, a file-based editor is essential for my workflow. Actually, I really don’t see any sense in Markdown text which is not saved into files which can later be processed by markdown processors. As a simple database for notes, I’m quite happy with Apple’s Notes app.

So my question is: Will FoldingText 3 still be usable as a file-based document editor? If not so, It’s useless for me.

16

Another dedicated foldingtext user here expressing concern about this direction. I’ll address this concern from two angles. Firstly, from my personal perspective as a user, then from a general business strategy perspective. Of course, I recognize that I’m just some guy, please don’t mistake my confidence in my opinions for pompousness or thinking that I’m definitely-definitely right. This is all just my opinion, written with an authoritative voice.

User

Why do I use FoldingText instead of Workflowy or Ulysses or Bear or any of the other lovely alternatives?

  1. The “sections” scheme. In other words, the ability to fold sections and manipulate them easily (workflowy and its ilk all have this)
  2. Work directly with plain-text files. This is an absolute must; my workflow uses plain text, and that absolutely will not change. As another user said, if the database sits on top of plain text / syncs live with plain-text files, cool. If not, then I’ll be using another tool from now on. (Nobody else has this! This is your key, core distinguishing feature!)
  3. Blazin’ fast. If my text editor is anything but incredibly incredibly fast, I’m out. (sorry, Word :disappointed_relieved:)

Business

I really really recommend taking some time to work on a real, cohesive, holistic business strategy. It seems like you’re approaching FT3 from a concerningly ad-hoc and developer-based perspective. You are running a business. I don’t know how successful it is, but I do know that you have a niche and several important factors that distinguish your product from it’s competitors. And the changes you’re describing mean losing a huge portion of your advantage. By making your product more similar to that of your competitors’, you are dooming yourself to failure. What your goal ought to be is to maintain (and maybe even expand) your product’s unique selling points in order to better serve your market. That could mean making under-the-hood decisions that are similar to those made by your competitors… but it also may not. I am certainly skeptical that the database idea is a good one— it sounds like you’re giving away a core competitive advantage in order to follow the pack. If you think that what I’m saying here is interesting or makes sense, here’s some reading that might help:

Conclusion

I love FT, and I’m really hoping to keep using it as a tool in the future. I hope my comment is helpful. Thank you for your work!

17

Loyal FT2 user here.

I wouldn’t mind the switch to a subscription model and Electron, but moving away from plain text files would be a total deal breaker for me.

If anything, I was hoping for FT3 to be able to consolidate my various text files into views, i.e. show me all “@todo not @done” entries across my open files in one window regardless of where the entries actually are, and when I change an entri in the virtual file (or view), it also gets changed in the original file. FT2 is already great at automatically reloaded a file that has changed, I rely on this feature a lot.

Maybe have different content backends that you can develop as needed? E.g. a plain text local file system backend to start with (you already have it), a DB backend, a Google Docs backend, an Office 365 backend and FT3 acting as powerful glue among all those?

Also, I get immense benefits from using tags and I was hoping for even smarter tags, such as:

  • being able to create synonyms, i.e. @p=@project @urgent=@priority(1) and then if I search for @project(x), @p(x) is a hit as well, and if I search for @urgent, @priotity(1) is a hit as well, and if I search for @priority(>=1), @urgent is a hit as well
  • being able to create a tag hierarchy, i.e. @people<@jon (think of “<” as the edges of a graph) and being able to hit @jon when I search for @people
  • being able to automatically apply a tag to children of the current node, i.e. if I write @todo+ instead of @todo, all the children of the current node automatically get a @todo when I create them (I know, there is a .todo mode but I prefer explicit tagging like this, works much better when you archive etc.)

just leaving my two cents here, hope it helps with the develpment of FT3, and wherever you decide to take it, good luck!

18

Also for me not supporting plain text files is a deal breaker, I keep my important things portable, so that I can view and edit them on my Mac, on my PC, on my phone, on my ipad, on my Linux machines, I can add to the files from Drafts, from Workflow, Alfred, Applescript etc… - most of this would ‘poof’ and disappear in a dust of smoke if I move to a database system.

For me, somebody might have said it already, Foldingtext adds the magic sauce to text files.

I am also not a big fan of subscription as most of the time, when I compare it with what’s out there, it fails to deliver a constant stream of new and improved features but rather pays for bugfixes, you’ll notice that very few developers offering the subscription model have an interesting release history. Having said that I do pay for one subscription (Setapp) which I think overall on the aggregate it’s delivering on the money.

19

Thank you all for your awesome feedback.

I understand your concerns. As a fellow FoldingText user, I would personally prefer to have FoldingText have a database, because it helps me write quick notes without the hassle of giving names to files. While it makes my life much easier as a developer and gave some cool potential features (like versioning, syncing, etc.), I haven’t been able to come up with a paramount reason why it can’t be a simple folder of text files with some metadata storage on the side. How it’ll eventually be implemented is still in flux, but I assume it’ll be a hybrid of some sort where the text is stored in plaintext files, and FoldingText 3 will maintain a database to allow library level features like full text searching across the library, filtering by tags, modes, and such.

Regarding the subscription model, as mentioned before, I’m not sure how it’ll be implemented, but a purchase for every major release (set to an annual cycle or so) is also in consideration. I’ll keep everyone updated as I work through this. For now, my main concern is ensuring FT3 is a worthy upgrade.

Once I get through making some of these lower level changes, I’ll keep everyone posted regarding the progress and features that I’m working on for FT3.

Thanks again for the honest feedback. I really appreciate it.

Regards,
Mutahhir

20

I like the architecture of “FT2” despite of a lot of bugs that are never getting fixed, e.g. i) constant crashes under macOS 10.13.x, ii) document-specific cookie corruption leading to improper line parsing and rendering when the text file is edited outside of “FT2” (even if the file is not currently opened with “FT2” when edited).

Because of the existing bugs of “FT2”, I’ve been looking for the alternatives; no luck yet; sticking to “FT2” hoping for the stable version. It’s good to see something is going on for the future of the app, but, it looks like it’s going to a very disappointing direction.

  • Subscription-based payment (including annual major version renewal) / one-time upgrade payment: I prefer the latter.

  • Database-backed app without the ability to incorporate the traditional folder/file system and plain text files on the initial release? NO. You’ll lose the majority of the existing loyal customers.

  • Electron for cross-platform development? NO, that’s not good. Does anybody know what “Sublime Text” is developed on? I don’t even like the current “FT2” rendering architecture–which is not macOS naive text i/o interface while “TaskPaper” is. I wonder why they’ve adopted different approaches.

  • Speaking of “Sublime Text”, I’d rather want to see the “FoldingText” package for “Sublime Text” which could do what “FT2” can do now. I would rather pay for that than the current snapshot of “FT3 dev”.

Thanks.