A Perfectly Legitimate Reason Collapsing is Needed in Task Management

jesse - June 30, 2008 10:01 PM

Sorry, started responding a few different times. I see your point, and I fully agree that collapsing is a legitimate way to organize tasks. And for some situations it maybe even be a necessity. But for me, and I think lots of people like me, it's not a necessity, and is in fact a negative feature sometimes.

If you are gathering and categorizing information (ie a digital notebook like Mori, etc) than I think collapsing is always useful. But if your goal is to just manage tasks related to a project then (again, for me in my own experience) I don't think collapsing really helps, and in fact I think it hurts. The problem is that it makes it to easy to hide information. And that makes it possible to make your project look pretty and organized, when in fact behind the collapsed items you've got decades worth of tasks to do.

And I think (no idea of I'm right) that the biggest problem with digital todo/gtd tools is that people enter to much information into them. It's really easy to type in years of work really fast. But once you've entered a lot of information, unless you are really careful, I am not, it begins to go out of date. Something changes in the real world, and one of those tasks that you entered is no longer needed. Or alternately if you have to many tasks entered you might start to forget about some of them, and start entering them twice... maybe not an issue for most people, but a big issue for me.

The best solution that I've found for myself is to just use a plain text file. (Essentially what TaskPaper is, with a few added enhancements that make working with the file easier) That forces me to always see everything right in front of me. If the resulting screen of information is to complex, then it's likely that the project is at fault, not TaskPaper. i.e maybe I'm committing to too many tasks, or maybe I'm tracking to much information, or maybe I've got duplicate tasks.

That's why a plain text file with no information hiding is great for me. It prevents me from tracking to much, and makes it obvious to me when things need to be cleaned up.

In your specific use case. It seems that you want to attach some project reference data to the projects task list. That's fine, I do it too, but TaskPaper is really supposed to be a "tasks" first tool. When I do have reference data for a project that I also want to keep around (if I had lots I would use a separate tool that's good a that sort of thing) I usually just put that kind of thing at the end of the project, and enter a few spaces to separate it from the projects main task list.

Not a perfect solution, but for my way of working a pretty maintainable solution.

reply | edit

jesse - July 1, 2008 1:58 PM

Then, to be consistent, don't you need to get rid of focus (hoisting) as well?

Don't contradict me with the facts! :) But for me I really do think that it is different. With project focusing I don't really feel like I'm closing off part of the document. Instead I feel that it's more like I have a really long sheet of paper in front of me, and I've moved my head close to one part so that just don't see the other parts. But as soon as I step back, it will all be right back in front off me.

Do you think you're in the majority on this? I'm just curious.

Not sure, and actually not sure if I want to be. TaskPaper really has two origins. First origin is that it was a side project for me. After Mori I didn't really want to do another "organizer" program. But after seeing beta's/screenshots of OmniFocus, and playing with iGTD, I thought there was a product opportunity for an "opposite" that was based around a plain text interface. It seemed that a lot of "smart" people were still just using text files to organize their tasks, even though they had all these fancy programs designed specifically for that task. So I thought I could cater first to these people, by adding a few things that made their plain text files easier to work with. I also though that even for the non geeks out their the plain text interface could be pretty refreshing.

Did you understand me to suggest that any user of TaskPaper be forced to collapse? Couldn't this be a setting in preferences?

No I realize that collapsing would just be an option, but it adds a whole new level of complexity to TaskPaper's use and implementation. Plus I think that no matter how I implement it most people with rightfully find that collapsing is better implemented in a pure NSOutlineView style outliner like OmniFocus, or OmniOutliner. So I feel like I'll go to a lot of effort to implement a feature that's not really going to be TaskPaper's strong point in the first place. One of my big goals (after selling Mori) is to make all of my software "small enough to be perfect". That's a goal, not something that I'll reach, but in general I think TaskPaper's strength is the plain text interface, I think if I reach to far in other directions TaskPaper will no longer be able to fit in my head all at once, and then it's down hill from there.

Maybe were are going about this wrong...

Right now I'm thinking of "collapsing" as a big new TaskPaper feature... and that's something that I just don't want to add. But TaskPaper already has a pretty powerful model/language to work with. Maybe if you could just come up with way to describe collapsing in those terms that it would all of the sudden be easy to implement, and also not really be a new feature :)

TaskPaper's model consists of:

1. A hierarchy of entries.
2. Each entry can have tags, tags can have values.
3. Text views, which display a subset of entries based on a search predicate.

I can almost imagine implementing collapsing in those terms. To collapse an entry add the tag @collapse. The theme would color that row differently so that you would know that the row was collapsed. And then somehow automatically looking for collapsed tags and creating a search that filter out any children that had a collapsed ancestor.

And ideally this would all be done in a somewhat generic way so that this automatic modification of the search filter could be used for things other then just collapsing.

Thoughts, ideas?

reply | edit

Matthew Crider - July 1, 2008 3:24 PM

Jesse,

Could the keyboard short cut be a toggle (either add or remove the @collapse)?

Eric has an ABSOLUTELY FABULOUS idea which is in keeping with your philosophy and in keeping with the temporary nature of ad hoc hiding (collapsing). I want to second Eric's suggestion for a quick key combo that tags and untags a parent level with the tag @collapse.

Oh, how I hope this meets with your approval.

Matt

PS Great suggestion, Eric!

reply | edit

Matthew Crider - July 1, 2008 3:43 PM

Jordan,

I'm going to pick up your program because I run Parallels and a program that syncs my "Windows" files with my co-workers located in other states. They are all with MicroSith Windoze and I work in Mac. So, I will be able to open my TaskPaper files with your program when I'm working in Parallels. You can open TaskPaper files, right?

Thanks.

Matt

reply | edit

Matthew Crider - July 1, 2008 3:40 PM

I can almost imagine implementing collapsing in those terms. To collapse an entry add the tag @collapse. The theme would color that row differently so that you would know that the row was collapsed. And then somehow automatically looking for collapsed tags and creating a search that filter out any children that had a collapsed ancestor.

Dang, I thought Eric's idea was great, but I just reread your paragraph quoted above. You envision a search that doesn't show children of parents with the tag @collapse. I was envisioning (and I think Eric was, too) something more along the lines of an ad hoc hiding of children right in the place where you are without having to go do a search (which would have the undesirable effect of losing your place) - hence the idea of a toggle.

I so hope this will get solved. You think of this as added complexity and I see it as added simplicity.

Matt

reply | edit

Matthew Crider - July 9, 2008 9:04 AM

Jesse,

Have you had a chance to consider this any further?

Thanks.

Matt

reply | edit