Tracks

I’ve read here that you are trying to make Tracks as flexible as possible…  Some people, myself included, would like to be able to enter multiple todo items for a project, yet have only the top item show up.  The response I’ve seen to this is that there might be multiple next actions that could be taken on a project, and that is a valid reply… 

Let me next say that I’m not a big fan of tags, as I’ve seen them implemented on many popular websites…  From reading posts on the forum here, it sounds like you are planning to add tags to Tracks todo items.  While tags are certainly hot a “Web 2.0” thing, I think they will only serve to add more overhead to Tracks, making it more complicated.  I’m striving for an automated approach to things, letting Tracks do the work of deciding what I should do next (assuming I’ve fed it that already).

Instead of tags (or perhaps, in addition to), if todo items could be treated more like lists, with the drag icon, allowing them to be sorted (only on the project page).  This would let you add multiple items to the list, then sort them by order that they should be done.  A new preference item could be added - something like “max incomplete todos shown on home page from same project”, (ok - so that’s probably not a good name for it, but you get the idea)...  This could default to 0 (unlimited), but the user could set it to 1 or 2, etc. 

So, lets say that you’ve added a project, three todo items, and have the new max preference set to 1.  The home page would show only the top item from that project, no matter what context it is in.  When that item was checked (completed), it moves to the complete area at the bottom of the home page, and the next todo from that project populates the appropriate context. 

In this way, someone could fill out 5 steps or more in, say, 5 projects, yet if their max preference was set to 1, for example, the home page would have a much more manageable list of 5 items to accomplish.  Alternatively, if this setting is 0, it would operate just as it does today.

I’ve started looking at the source code (to the latest stable release) to see how feasible this is.  I’m fairly new to rails, having only written two applications in it for my day job, so I’m still not used to the “Ruby way” of doing things…  It makes reading Ruby code that I didn’t write a bit difficult… 

Anyhow, does this sound like something that anyone else is interested in?

@ptaylor: Thanks for the suggestions. I should say that I’m not sure what the solution is, and I’d be interested to hear what others think.

A couple of things:

1. Tags are already in the trunk, but they are entirely optional. If you choose not to use them, the only indication you will see that tagging is possible is a ‘Tag’ text field in the next action entry forms. Otherwise, if you don’t want to use them, you don’t have to, and there is no other clutter in the interface.

2. I do understand what you mean about next actions in projects and having the selection process automated, but—and this was my point about flexibility—there are as many different types of projects as there are people. I for one would like to be forced to only have the top item on each project list appear on the home page, because I typically have several actions in each project which are possible to do concurrently, and I would therefore be missing out on the opportunity to do them unless I kept an eye on the project page. This doesn’t mean that we couldn’t do it, just that I would prefer if it was optional.

3. We did try having a draggable next action list, but there were a lot of technical problems, and we never got it to work well. If you’d like to have another go, by all means have a bash at it, but it isn’t trivial.

To reply to your #2 point, my suggestion was that it be an option… The user could select the number of items in a project to have as viewable on the main screen, so if they only wanted one from a particular project, they could, or if they’d like to limit it to another number (or have it unlimited), that could also be the case… I don’t know how easy this would be to implement, but hey, it’s an idea…

As for a next items list that you can drag around, I don’t know what technical issues you ran into, but it would seem to be fairly straightforward if you only allow sorting on a per project level.  (Set the scope to be on a :project variable, not the :user)..  Since each project id is only tied to a single user, I would think that would still give us what we need…  You couldn’t have the actions be sortable within a context, since they come from multiple projects..

I’ve already started trying to code this…  I’ll keep at it and see if I can come up with anything…

Well, so far I’ve been able to add the position column to the todos table, modified the todos model to be acts_as_list with a scope of project, modified the code to the point that I can reorder the list of items for a project…  But, when I reorder, the POST isn’t firing…  (Using firebug, I see the post firing to the /project/order action when I Drag the DRAG div, but the post never fires when dragging todo items.  That post is to todo/order, which is remarkable similar to project/order )

Anyhow, I think I’m done for the day…  I feel close, for this part…  But, as I think more, I’m not sure how the ordering will work for todos because once you “check” a todo item as done, it’s no longer considered in the order…  But, if you check one off as done, reorder your list, then uncheck a “done” task, it may end up conflicting with the position of another item…  Is this the tricky part you talked about???

Ok - Got the problem solved with it not firing the AJAX update…  It wasn’t able to serialize things properly…  So, now I am to the point where I can sort todo tasks via drag/drop on the project page, then I can go back to the page and the changes stick.  I’ve also cleaned up a couple things that I broke because it was necessary to change the div name for the item container div. 

Problems:
- When adding a new todo items, they are not immediately draggable.  (You have to refresh the page)  Not sure how easy this would be to fix.

- When editing existing todo items, the DRAG item disappears after saving the change.

Hi ptaylor,

The issues of todos transitioning from completed <-> active <-> deferred are some of what complicates the implementation of ordering todos within a project.

I think the approach of setting a number of next actions to show on the home page across all projects doesn’t match the way next actions really work. One project may have four “next” actions while another might have only one.

I’ve been leaning toward a “star” model for indicating “next actions”. The user could star (a la gmail) the next actions in a project and depending on user preference, only starred items would appear on the homepage.

All that being said, if you’ve got a solution to these issues and are close to functional with have only a few Ajax issues to work out, feel free to create a ticket on the trac and attach a patch. I’ve got a fair bit of experience working out these Ajax intricacies now, and I’d be happy to help.

Cheers from NYC,
Luke