|
All fixed now, .dan.g. Thanks.
|
|
|
|
|
Hi,
sometimes the expansion buttons of my tasks disappear.
This happens when I resort the tasklist with clicking on certain column headers. What actually happens is that the task titles shift a little bit to the left, eventually hiding the expansion buttons partly or sometimes entirely.
I have not been able to find a reproducable schema for this yet, but maybe someone else has seen this before.
-tafkat
|
|
|
|
|
hi tafkat
you may find that this is standard tree control behaviour when there is a horizontal scrollbar. the tree control is attempting to make as much of the item text visible as possible so it scrolls right until the left hand edge of the text is flush with the left border of the window.
to test this theory try the following:
1. find an item with a long title and select it
2. resize TDL until some of the text is clipped on the right
3. sort any column
one possible solution is for TDL to save and restore the horizontal scroll position when doing a sort (although i'm not sure how easy this will be)
.dan.g.
AbstractSpoon Software
|
|
|
|
|
Ahhh, yes that's it.
I didn't even realized the scrollbar - stupid me
.
I think this is a too minor issue to invest too much time in it.
-tafkat
|
|
|
|
|
Part II - the TDL I need.
preface: Sorry if I come off demanding, not grateful, and too long. But that's me when I like a tool. Also, uplease nderstand that the following is a hodgepodge between use case, specification, demand, and dream
Post-scriptum-preface: in the following, when talking about "times", I mean a duration (minutes, hours, weeks,...). Only a "date" means a time point, which is fine for me with resolution of one day.
I'm currently using TDL for planning software implementation details: it is a guideline to break down tasks (house rule: tasks for which are planned more than 4h have to be split up), as a tool to calculate times for milestones and completion times, and a "red alert" button when the schedule is slipping. The latter requires to keep the list up-to-date. TDL by far beats previous tools: Project on simplicity and price, Excel on hierarchy and commenting, and Word on tabulating and automatic calculation.
So here's the setup I need (much of this is possible with TDL, not everything would have to be exactly like this, this is my idea/spec/use case):
(1) Tasks.
Task hierarchy + comments as it is now.
Each task has estimate, time spent, completion checkbox, priority.
I can filter out all tasks below a given priority, which also means they are excluded from all calculations (aggregated times, due dates, etc.)
Order of tasks gives order of execution. If the schedule is slipping, but my release date is fixed, I can filter out uncompleted low priority features (I assign a lower priority only to features that can be kicked from the release, and that's the only real need I have for priorities.)
times can be entered as 2w1d3h20m (wwek/day/hour/minute), and are displayed as such. I can configure how many hours in a day, days in a week, weeks in a year. (I would avoid month as a unit of time, as a variation of 10% is not acceptable)
Parent tasks can not have no individual time associated, but they atomatically aggregate the time of all children (recursively), and are complete if and only if all children are complete. If there is a child task which is not complete, and has a zero estimate, a "+" is appended to the parent's estimate to indicates that the total time may be longer, since estimates are missing. This "+" bubbles up, of course
I have a shortcut that allows me to split up a leaf task into two two sub tasks: Task A is split into A1 and A2, where A retains onl the name, A1 inherits all properties of A (comment, times, dates, etc.), and A2 is a completely new task.
optionals track for each task *when* time has been spent on it (but I see that as a separate tool).
"Completion" date, which works as a fixture for the milestome calculation below. Or, alternatively (thinking about, I prefer it), I can insert "away from project" tasks, which go into date calculations, but not into duration aggregates. This can acocunt for holidays, sickness, and "the server caught fire" days.
(2) Changes
This schedule does change. New entries are set to blue. For a task tree, or the entire list, I can select "accept schedule", which turns all items to black, but new items will be blue again. How to handle changes to existing items?
(3) Milestones
Milestones handle dates and aggregate times, but no time can be allocated to them directly. Currently I could live with "milestones" only on the top level, I have some ideas/uses for nested milestones, too.
Technically, A Milestone is the parent of a task tree that are required to compleate this milestone. Visually, however, I'd like to have them *below* the tasks to complete. I think the "nicest" implementation would be:
mark a parent task as milestone, which enables the "special behavior", and display aggregated times below the milestone (and all sub tasks)
A milestone works differently from tasks. It has the following dates assigned:
- planned start date
- planned completion date
- actual start date
- estimated completion date (calculated)
- actual completion date
Estimated completion date is calculated as follows:
- for completed tasks, the total time used on them is taken into account.
- for incomplete taks, the max of estimate and spent is taken, and multiplied by the "slip rate" of completed tasks of this milestone.
- total time is adjusted by the slip rate of previous, complete milestones
- (slip rate is max(1, sum of time spent / sum of stime accumulated))
- start date is actual start date if given, expected start date otherwise.
Milestones have aggregates: subtotals for the Milestone itself, and total aggregates for all milestones. Numbers: Original Estimate, Estimate for changes, Total estimate adjusted for slip rate, total time spent.
Other things
I have some problems with "unexpected automatic" handling (automatic setting of dates, etc.) Generally, I would make times and dates either (a) entered by user, or (b) calculated automatically without possibility for the user to enter. Only on a few chosen places I would add automatic, but when in doubt, rather leave it empty/unmodified.
(e.g. when clicking the start clock, and the corresponding milestone has no start date set yet, it is set to the current date).
There is a dozen minor things in the current TDL, independent of all this drivel. But maybe this is a third post
Phew. Thank you for reading. It's not that I didn't have anything better to do. I just... don't like cleaning.
we are here to help each other get through this thing, whatever it is Vonnegut jr. boost your code || Fold With Us! || sighist | doxygen
|
|
|
|
|
thanks peter. i've printed it out so that i can read it slowly and understand it fully.
rgds
.dan.g.
AbstractSpoon Software
|
|
|
|
|
thanks again, peter.
whilst i ruminate on the more structural issues, i propose to implement the following simpler items for the forthcoming release:
1. split task (only into 2 subtasks? or 3, 4, 5...?)
2. if time tracking and the start date is undefined, then set to current date
3. change some of the default preferences to be more 'useful' (you're welcome to more precisely define your 'ideal' setup).
4. append '+' or '-' to accumulated values if subtask attributes are undefined (note: '-' would be used if 'earliest due date' was specified but some due dates were missing)
rgds
.dan.g.
AbstractSpoon Software
|
|
|
|
|
[edit]: general: just keep in mind that this is a "typical customers wish list". You have to make me fight for every feature, why I really need it, or if we find a simpler solution [/edit]
(1) yes, just two. a third, 4th etc. task can be added normally using Ctrl-N
The problem I am trying to solve with the "split" is this:
To split a task, I typically create a new task above, then indent the task to split up (so it retains it's original estimate, etc.). That's most effective, but not intuitive.
A few times I added a child task, noticed the estimates were gone (hidden, actually), unindented the child task, transferred the settings, and indented it again.
Maybe it would even be enough to offer a "make current task child of a new task", but that's an awkward action noone understands.
Q: would it be possible to some kind of macros for things like these? I could set it up myself, and not bother you. But that depends on your code base.
(2) Main point was: mostly disable the automatic time assignment (e.g. when I start a new task, current date is assigned a "start date", and I have to remove it) You already have many users, it's not easy to change such policies, I know...
(3) OK, I'll go through the preferences in general, seeing what can be renamed to make it more obvious (or even removed. I'm a big fanatic on "no options" - but that doesn't work with your app I know...)
Some minor things:
the dime displayed in the estimate has maaaany digits, the display is awkward, and input length is limited. so when I have the chess clock running, and want to add some 10 minutes I forgot to have it "on", I first have to do an awkward calculation, then delete the lesser digits auf the auto value, so I can edit at all.
The return key, to get back to the list. Any other key would be fine for me I'll dig into your code base...
I can't get rid of the "due date is earlest" option. top Task has no date assigned child 1 has 24th, child 2 has 30th. Tp task alwas displays 24th or earlie, no mater how I set the "due dat is earliest.." option, or assign a date to the top task
we are here to help each other get through this thing, whatever it is Vonnegut jr. boost your code || Fold With Us! || sighist | doxygen
|
|
|
|
|
(1) you can also try copying the selected task (ctrl+C or by context menu) and then pasting it onto itself (ctrl+V or context menu).
with this in mind i propose to do a 'real' split for the split task functionality. ie split time estimate, make first subtask due in half the time, etc
(2) there is a preference on the Tasks>Defaults page to disable this. do you think it should be disabled by default?
i'll look into the "due date is earlest" issue.
.dan.g.
AbstractSpoon Software
|
|
|
|
|
(2)
My bad, I never made it to that page
(1)
perfect! (if you make Ctrl-V to paste "after item".)
I don't think a split is necessary then. while it looks like a cool feature, times never distribute evenly. Maybe ask others what they think.
we are here to help each other get through this thing, whatever it is Vonnegut jr. boost your code || Fold With Us! || sighist | doxygen
|
|
|
|
|
actually, the split feature is trivial to implement so i'm going to do it anyway.
on a related point, peter, splitting a task automatically raises the idea of linking subtasks, such that changing the due date of one would change the start date of any siblings which began on the original due date.
eg.
task 1 starts on 11/11/04 and is due on 14/11/04
task 2 starts on 14/11/04 and is due on 17/11/04
if i change task 1 to be due on, say, the 15/11/04 then this would bump all the remaining sibling tasks on by one day.
your thoughts?
.dan.g.
AbstractSpoon Software
|
|
|
|
|
I wouldn't 'mess' with user choices more, except when he says so explicitely.
When running a project, there's always the question "why did it take longer than the plan", and you want to compare the planned schedule with the actual.
For that, I would keep the original due dates, and *never* modify them automatically (except perhaps when the user says "recalculate due dates now"). In parallel have a column "expected completion date", which includes all time exceeds.
For me, TDL is an important tool *not* to simply readjust the due dates when one part of the project slips.
I hope to find the time to look at the code base any time soon. I have no feeling for what can be done, what not, and at which effort.
For the save/load prefs:
A first step would be:
- Save all settings to an (XML) file
- Load all settings from an (XML) file
Now, the next question is: can any combination of settings be applied to any task list? Or is there any data that changes it's meaning when you change settings? (this would be bad)
Can we move *all* settings to the todo list file? (I am not sure, maybe you still need the "global" options, maybe you should split up options - UI configuration and "processing" configuration. That seems more poerful, but less transparent)
In this case, any todo list could act as a template. I could configure it, and give it to my coders.
"Load settings" could accept either a specific setting file, or another ToDoList. Or maybe the separate config files are not needed at all.
Another thing: Is there a reason you named the files ".xml"? I thought picking a nice extension (like ".todo"), and associating TDL with it would be the way to go.
we are here to help each other get through this thing, whatever it is Vonnegut jr. boost your code || Fold With Us! || sighist | doxygen
|
|
|
|
|
>> wouldn't 'mess' with user choices more
sorry, i didn't make myself clear. this would only ever be a user preference (another one! )
>> For the save/load prefs:
todolist can already save/load settings from an .ini file courtesy of MFC, and you can enable this functionality simply by dropping an empty .ini file into the same folder as the executable.
>> Is there a reason you named the files ".xml"?
yes. initially i used '.tdl', but when i came to try and parse this in a web page in one of the popular browsers it failed because the extension was _not_ '.xml'. and since this was part of the 'selling' point (that the raw tasklist' could be parsed and display by the same javascript in all browsers) i stuck with '.xml'. one thing i was thinking was adding a preference (!) to allow users to save tasklists to a custom extension which would then be associated with TDL on their machine.
.dan.g.
AbstractSpoon Software
|
|
|
|
|
(1) as said, I'd rather have it as separate column, or make this an explicit command. It's one of the preferences that makes it less transparent what's happening. But maybe others see it important enough to make i automatic.
(2) good to know. per-TDL-options, Save/Load/Load from TDL would be cool though
(3) You can associate TDL with an extension, when saving, allow to chose between "xml" and ".todo" (or .tdl or whatever you like). "Associate with [extension] is a setup option.
Yes, I am "anti-option". This thought is not by me, but pretty much sums it up: Every option is a design decision, that was avoided.
we are here to help each other get through this thing, whatever it is Vonnegut jr. boost your code || Fold With Us! || sighist | doxygen
|
|
|
|
|
>> Every option is a design decision, that was avoided.
do you also think that keyboard shortcuts should be hard-coded ?
.dan.g.
AbstractSpoon Software
|
|
|
|
|
eh!
It's an opinion, not a rule. And your app *needs* to be configurable. (But I *do* think less is better.)
But, thinking about it, hardcoded keyboard shortcuts have their benefits. Sitting down on my coworkers PC I can edit the TDL with the same keys as at my PC. How do I get my "improved" assignments from my home PC to my work PC? You can much easier embed keyboard shortcuts in all documentation/UI feedback. Macro recorders will work much better with TDL, I can take my macros with me.
No, don't hardcode them... I'm just playing devils advocate
The problem is: you have to think long and hard about every such decision, and most of them are cast in stone.
we are here to help each other get through this thing, whatever it is Vonnegut jr. boost your code || Fold With Us! || sighist | doxygen
|
|
|
|
|
>> I'm just playing devils advocate
i had an idea you might be, but i just felt i had to flush you out!
nevertheless, i very much appreciate the time you've spent articulating your position, it helps me maintain a sensible middle ground when deciding what and how to implement things.
rgds
.dan.g.
AbstractSpoon Software
|
|
|
|
|
(1) as said, I'd rather have it as separate column, or make this an explicit command. It's one of the preferences that makes it less transparent what's happening. But maybe others see it important enough to make i automatic.
(2) good to know. per-TDL-options, Save/Load/Load from TDL would be cool though
(3) You can associate TDL with an extension, when saving, allow to chose between "xml" and ".todo" (or .tdl or whatever you like). "Associate with [extension] is a setup option.
Yes, I am "anti-option". This thought is not by me, but pretty much sums it up: Every option is a design decision, that was avoided.
we are here to help each other get through this thing, whatever it is Vonnegut jr. boost your code || Fold With Us! || sighist | doxygen
|
|
|
|
|
since you asked
Most incredible about ToDoList is: you immediately see what it lacks to make it the perfect tool. Often it's far from what I expect, but I know exactly what I would have to change to make it "the one I'd write if I had the time".
Now, these last few percent, different for many, is what I'm thinking about.
Let's talk, for a moment, about the downsides of ToDoList:
The options are already a pain to try out and see if I can make it the one I need. The automatic date handling is never what I expect. Dates are automatically entered where I don't want them, aggregated times and upper-level dates are weird. There are two different "Start Dates" (planned and actual), and I need them both.
The Crux of ToDoList is that it can be used for so many different jobs, and every job has it's own defaults.
I was going to post my expectations (just wait for the next post... ), but this will not solve the fundamental problem: If you implement 10% of all wishes, you need TDL-Doctorate to configure it.
Suggested Roadmap:
(1) Allow to (a) save the entire "job based" configuration in the todo-list-file itself, and in a separate file. Can a configuration file be applied to an arbitrary todo list?
(2) People no longer select a combination of "Due Date is earliest..." and "columns abc", but between jobs like "detailed implementation plan (single developer)", "Project Overview (Team)", "peterchens favorite party planning". Some of them are built-in configurations, others are taken from external files.
At this point, it doesn't matter to much anymore how complicated TDL is to configure. But wait, there is more.
You *need* to isolate different schemas to calculate times, due dates, etc. Adding a new Schema to the code base should be easy, and mostly isolated from the UI handling.
Next on CP: How I think TDL has to work, no excuses allowed.
we are here to help each other get through this thing, whatever it is Vonnegut jr. boost your code || Fold With Us! || sighist | doxygen
|
|
|
|
|
i think the idea of associating specific preferences with specific tasklists is an excellent one.
however, someone has to create the configurations to start with and users need to retain the means of tweaking them to suit their own needs.
notwithstanding your subsequent post which i have now read and am digesting i would welcome any further ideas on how you would actually see it working.
rgds
.dan.g.
AbstractSpoon Software
|
|
|
|
|
|
Moderator pls delete, spam message
|
|
|
|
|
A really useful feature that will complement the sorting features is "view filtering". By this I mean, being able to show only tasks with a certain property (such as my tasks, Tim's tasks, tasks due tomorrow [yes I know you have something under Tools that does a popup for that but this is different], tasks due during a specific period, and so on).
The parent chain of a task that satisfies the filter should remain visible. Moreover, the children of a task that satisfies the filter should also be visible.
It should also be possible to combine filters. Think of them as toggle controls like the Bold and Italics buttons in Word. It may actually be a good idea to have them as buttons. But because there can be too many, the user may want to customize such a View Filters toolbar.
Of course, the user should be able to do the regular stuff such as sorting on the filtered view.
Anyway, I looked at CTreeCtrl and I don't see an obvious way to cause an item to be ignored except by actually deleting it. (I think you can disable it but it will show a space in its place which isn't that useful). So I can why implementing this would be challenging (lots of deletions/insertions) unless you can think of a better way. Either way, good luck!
|
|
|
|
|
>> So I can why implementing this would be challenging
i'm glad someone else can
i still believe (possibly naively) that a (relatively) elegant solution to this exists which is why its taking so long in the coming. but it _is_ coming.
rgds
.dan.g.
AbstractSpoon Software
|
|
|
|
|
Right now, it seems that POS means the current sort order. So if I spend half-an-hour rearranging my tasks in a some order, and then I click on say "Due", I lose all the changes I made. (But please correct me if I'm wrong).
I do not see the usefulness of POS if done this way. Another way is to make it correspond to some user provided meaningful ordering (such as a chronological order of tasks/subtasks). This would be much more powerful and useful.
This mean that the only way to change a POS value, is to manually move tasks up and down (or insert/delete/etc.). From a GUI standpoint, this can be achieved by allowing the user to click on the "Pos" tab if he/she chooses to see the tasks in the POS order. If the user clicks on another tab, the items under "Pos" will simply no longer look sorted.
What do you think?
|
|
|
|
|