OK, I think I see your point - that the folders item has an 'inhereting' property which can be used, in effect, to set defaults for its sub-tasks. But I think there's still a case for withdrawing some of the properties, such as Project, Effort, Task Statistics, and Dependencies
> I'm just not a fan of removing functionality. > Doing so imposes a particular usage model onto the product. I tend to agree in general. But in this particular case, I really think it would be removing redundant functionality. Like it or not, MLO does have an underlying 'usage model'. It's just that it's very flexible. I just think it needs to retain some kind of structural integrity. In other words, you need to have a clear idea of exactly what a 'task' is and what it can do. Same with projects. And the same with folders, but I think that in this case the intended usage of this element is not consistent with the options presented in the properties window. >Perhaps those parts could > be automatically collapsed when a folder is selected, although I > think it would be tricky because you would want the previous view > restored when a different task is selected. I'd prefer removing from view rather than collapsing. I really can't think of any instance when you would assign a folder as a project, need to view task statistics on it, assign an effort to it, or give it a dependency. Would be interested to hear any examples... --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "MyLifeOrganized" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/mylifeorganized?hl=en -~----------~----~----~----~------~----~------~--~---
