Ability to create a "project"
People want lists to do more. There have been many requests for lists to be extended, such as to have a checklist, a list of todo items that get checked off one by one, and to be able to tag individual items in a list, etc. I think that these requests can be solved by making a new "project" type. A "project" is a list that can do more.
My idea is kind of a cross between a list, a tag and a note. A "project" would be a collection of other individual items, kind of like a tag is now. A "project" would also be a list. It would be able to assign an order to the tasks it contains. A "project" would also be a special kind of a Note, it would contain information about the project like a goal, status of sub tasks, etc.
Differences from a "tag":
1) Projects should have some way of providing an overview of the status of the project. I call this the "project overview". It contains a list or edit box to manage tasks. The project needs to be able to assign a sequence or an order to the tasks it contains. In other words, it can define a relationship between the tasks it contains.
2) Whenever an item in a project is changed, or updated, the "project" is updated. This lest the project maintain control over all sub tasks. Each item in a project has a link back to the "project". When the item in a project is updated, the project is notified.
Every item in Sandy can have multiple tags, but can only be a part of one "project". (I just think that would make it easier to implement.)
3) Should projects be allowed to use most tags? Does it make sense for a project to be tagged @todo or @weekly, when a task in the project can be tagged as todo or repeating? Should a project show up in the Daily Digest, or just the tasks n the project? (How about the "Recently Updated" list at http://iwantsandy.com/list does this show projects or just the itmes in the projects?)
4) There could be a separate display page for projects and a separate url http://iwantsandy.com/projects
Uses of a project.
1) Ability to define an *ordered* set of tasks.
2) Ability to add relationships between tasks.
Example: Can make some tasks dependent on other tasks.
2b) Can have task dates dependent on other task dates.
Example: task #2 needs to be completed 2 days after task #1 finishes.
When the date for task #1 is changed, then task #2 is automatically updated.
3) Changing any item in the project updates the project.
Example: Marking a task "@done" can trigger an action in the project. (Like marking another item "@todo")
4) Able to create a true "checklist", a *list* of items, that can be viewed in order, and tagged as "@done" individually.
5) any item in the project list can be tagged independently (something lists cannot do)
6) Have the ability to organize information about sub tasks. You can know how the project is doing, what step is currently being worked on, what still needs to be done etc.
7) Ability to manage a project, not just list items with a tag.
The more people who like this idea, the more it gets noticed.
-
Inappropriate?I really like this idea, as a cross-cutting way to bind other types of data. I frequently deal with appointments, todos, bookmarks and contacts through the life of a project, and binding them all together by tag feels clunky at times.
I've implemented task ordering it with priority tags p1 - p3. While it helps somewhat, it isn't as clean as it could be. Nor is it as powerful and organized as a first-class project type might be.
My favorite idea from kevin1's list is the notion of binding todos together. With that change, sandy really turns todos from a paper checklist into a project management tool. I normally use this sort of parent/child relationship to build up a big tree of tasks under the theory of 'work on the children first, then the parent and its peers', rolling up as I go. Tagging peer groups with priority (@p1 @p3...) helps me sort out the order that one peer group of tasks should be worked, but that's a poor substitute for parent-of and happens-before relationships.
I’m hopeful
Loading Profile...




