I’ve been working a lot on WriteRoom 4 ideas for the past week and a half. Here are some notes on what I’m doing and answers to some questions that I’ve had:
Why WriteRoom?
WriteRoom started as a unique and simple app. It’s recently languished and the concept’s been duplicated. WriteRoom’s “Distraction free writing” tagline now describes a whole category of software. For this reason I’ve had a number of comments from people wishing I would just continue working on TaskPaper because it’s more unique. The thought is that any new version of WriteRoom will just be another entry in the “Distraction free writing” category.
I understand the thinking, but I see lots of room for improvement and unexplored territory in the writing app category. My overarching goal as a software developer is to build better tools for thinking with text. TaskPaper is great, but it’s really meant as a planning/todo list. I really want to work on a more formal writing tool and have a number of ideas that will fit well into a writing app, but not a todo list app.
This isn’t a new goal, FoldingText was my first attempt at this. And I know many people really like it (and I’m very happy Mutahhir continues to work on it) … but for me it missed the mark in the end. For me it reached to far and became too complex. With WriteRoom my goal is just to create better place to think and write, not the “plain text productivity” goal from FoldingText.
What am I working on right now?
So far I’m just experimenting, but my focus is to improving the core text editing experience. (Note that improvements here also transfer over to TaskPaper). In particular I’m working really hard on performance, which is tricky considering the underlying JavaScript outline document model that I’m working with. (Again, WriteRoom will have same model and scripting API as current TaskPaper).
The good news is that I’ve had some successful experiments and “think” I’ll be able make some dramatic improvements to memory, speed, and editor features. My goal is to scroll "like butter!!! " through 100,000 lines. Resize that window with zero choppiness. Etc. To my knowledge this type of performance isn’t possible in existing OS X apps that support multiple fonts and OS X typography. Some programmer’s text editor with a single font can do it, but a single font is a simpler implementation. Paste that much text into TextEdit and things quickly go bad.
Why should you care? Nobody makes documents that big anyway? Because I think all of this optimization will show up in much smaller documents. All the little lags that you probably don’t even notice, I think you will notice once they are gone.
How will this effect TaskPaper’s development?
I certainly don’t see TaskPaper as “done”, but In the midterm TaskPaper releases will slow down. WriteRoom work will take my creative time. I expect to make TaskPaper bug fixes, but am unlikely to add any big new features.
But remember I’m building WriteRoom on the same codebase and it uses the same underlying data model as TaskPaper. This means that once WriteRoom 4 is out I should fairly quickly be able to make a major new TaskPaper release with that takes advantage of all the work that I’ve done for WriteRoom. Starting with a much better text editor assuming I can get that part implemented.