elastic threads

forks and minimalism

christiantietze:

Note that no one’s forking it to remove features.

I disagree with (a possible, yet implicit conclusion of that) post:

Since we’re dealing with apps which do One Thing Well here, the quoted remark at the very end of that post is equivalent to “look! how they make the program less focused on a single task but make it more complex instead.” Which in my mind basically means either (1) Notational Velocity in its original form was just perfect, hence the impossibility of removing stuff, (without any word of critique concerning the forks,) or (2) whatever state Notational Velocity was in, it was doing one thing well and we developers jumped in, breaking the golden rule of Unix, namely: do one single thing and do it well. I disagree to that second possible conclusion. (Because I wholeheartedly agree to the first one.)

All of us “forkers” try to make something entirely new out of NV. I want to transform it into a text editor for (Multi)Markdown files…

My personal aim will be a toolset which combines Notational Velocity browsing with TextMate editing and Markdown-powered preview.

Agreed. I think there’s a difference between piling on features and expanding existing ones/creating room for existing features to shine. It’d be one thing if someone started turning NV into an everything box (yojimbo style). No. NV is about texts. But it is possible to extend the keyboard-controlling, search and type, manage and edit your notes goodness of NV. Letting you shift from a “quick let me just track down this bit of info” mode of small-windowed NV to a “ok, let me hide the distractions and write” mode   OR a “let me stay in NV and preview how this will look once rendered from markdown”…     I’m not sure “feature-bloat” describes that.

My own opinion is that minimalism isn’t the number of features or functions something has, but how seamless something is put together. A very robust product polished well can provide a very calm, “minimal”, and intuitive experience.