I'm a new user, and I was testing the ability to cut paste Rich Text into the Comments field.
The thing is, when I created my first Tasklist file I did it in Unicode. This seemed to work OK until I closed and re-opened the program. At that point I got the error where it says my file "contains malformed XML that the MSXML component could not interpret".
I was able to go back and find the last backup before I added the Rich Text. I then saved in non-Unicode and things were fine after that.
I went back and re-traced my steps. If you start with a totally new setup, create a new TDL file, then hit "Save Tasklist As..." it will default you to Unicode. If you hit "Save Tasklist" it will default you to non-Unicode.
This is exactly the type of inconsistent behavior that causes novice users to get tripped up. I almost lost a week's worth of work over this.
Sorry, I wasn't trying to imply anything by my tone. I was just so happy to find a program where I could dump all my random stray thoughts and then I ran into this...
The thing that triggered it was cutting and pasting from an email in MS Outlook that contained formatted tables (which in turn must have originated in Word or Excel). Does this forum let you upload attachments? Because I can easily replicate this and send you the corrupted file.
Were you able to replicate the way it defaults to Unicode when you do "Save As" but not "Save"? Is it that way on purpose?
Were you able to replicate the way it defaults to Unicode when you do "Save As" but not "Save"?
Unfortunately not. Can you describe the precise set of steps to reproduce the two behaviours?
Richard Smith wrote:
Is it that way on purpose?
It ought to default to Unicode both times, but the problem may have been triggered by the fact that 'Introduction.tdl' is a non-unicode file.
Richard Smith wrote:
Because I can easily replicate this and send you the corrupted file.
It would be more useful if you could send me a copy of the text that caused the corruption, as well as the corrupted file.
ps. And if you could reduce the corrupted file to a single task that would make things a lot easier for me too.
In TDL Release 6.7.DR2, when I copy from some outside source then navigate to my desired task and immediately right click over the comments field with the intent of pasting the copied text, TDL bombs on me.
This is an interesting problem. There are several potentially useful views of the data.
I set up the stylesheet 'Z_TimeSpentReport.xsl' to present the estimated and actual time spent next to one another. The calculated times sum up for the parents. This has 2 weaknesses:
1. You can't easily compare. For instance, if you want to compare month to month, you need to filter for the month, generate the report, print or store the data, then do the next filter etc... Would be great to have a report that presents time data for several time periods.
2. Accruing / grouping times on something other than parent. For instance, grouping by a tag or category. A common thing would be to say (e.g.) I will spend x% of my time on routine work, y% on improvement work etc... I would like to then compare intended with actual over time.
Of note, ideally you would be able to assign a target percent to the category, rather than messing with all the individual tasks contributing to the category.
I still intend to write a stylesheet to report times grouped by category.
The above would depend on the filter applied prior to the report. For review purposes, you would mainly be using completed tasks.
I am not sure 'due date' vs 'completion date' will be generally useful. Depends on how TDL is used. If due date is used as a deadline, then reporting on say % tasks completed before/after/on deadline (and related measures) is useful. However, it is less useful where the due is used like an 'action date', and is constantly moved.
One thing TDL currently can't measure that might be of interest is either how many times a start / due date has been deferred, or the magnitude of the overall deferral. This is related to the concept of the 'baseline' in projects and gantt charts.
Depends on how you want to do it. As a minimum, you could store a 'baseline' due or start value. This could then allow the calculation of the total amount of time deferred. If you want to know the number of times deferred, you could do this using an integer counter I guess. If you want to know the actual deferral dates as well, you need to store the actual dates...
What this doesn't tell you of course is the number of times you actually worked on a task / project. A way to do this would be to log the start and end times of a task, when using the timer. Therefore a task could/would have multiple start and end times, potentially over days or weeks. But that would be a lot of data. As I understand it, TDL currently adds the duration to a total duration.
The above suggestion would allow for a 'journal' style report, potentially linked in with a calendar.
This could lead to assigning times to tasks ahead of time (eg when planning your day). This could mean you don't need to use the timer function to generate the data. Ideally this would be achieved by dragging on a day calendar...
But all of this is a significant change to how TDL works, and I am not sure what the interest would be for this type of reporting.
Ha! That makes more sense.
As I understand it, the burndown would only be a reflection of either the completed tasks vs uncompleted ones, or the % effort completed / not completed. This is useful I guess as a monitor of progress against a tasklist/project.
The Business Case
TodoList is an excellent tool for managing Projects of a variety of sizes because it makes it easy to break down a project into its components and keep breaking them down until there is a good list of manageable pieces to work on. Because of the percentages at the various levels it allows you to get a pretty idea of how far along you are in completing your project.
The problems is that by looking at the percentages and the number of tasks remaining it is hard to get a real idea of how much longer it is going to take you to complete the remainder of the outstanding items.
Scrum and other AGILE methods use the concept of a Burndown Chart. A chart that shows you visibly how fast you are burning through the existing task list. By looking at this chart you can get a good idea of how much progress you are making against the existing backlog of tasks and how fast. If tasks are being added (scope increase) or if existing tasks are more complex (further breakdown) or if task estimates go up, then the Burndown chart will clearly show this by levelling out or even going up. If real progress is being made then the chart will flow down. As you look at the trajectory of the chart over time it will become very clear when (if ever) you can realistically expect to be finished.
This chart is great to show to a client/customer because it is easy to understand and it is great leverage when you need to talk to them about limiting the scope of the current phase of a project and moving certain functionality to another phase to make the initial deadline.
The X axis of the chart would be time. With the first date being the creation of the first task that matches the filter and the last date being either today or the completion of the last task that matches the filter. Optionally the user could specify a deadline date for use as the final date.
The chart would plot two lines.
The first line would be the number of incomplete tasks over time. This number is absolute and should not be affected by any indication of completeness. I would optionally limit this to child tasks only. (See options) I am pretty sure this data already exists in ToDoList because you know when a task was completed and you know when it was started.
The second line would be the estimated number of hours that are still outstanding. If the person has added an estimate(hours) then use that value if there is no value then use the configured default. Allow a configured default of Null. If there is no estimate and no default then the task won't be included in the remaining effort chart line. The remaining effort for each task should take into account the percentages complete if specified.
Include a note on the chart indicating the number of tasks without an estimate and show the default estimate value (if specified). This helps make it clear how it is calculated.
You could either have to two charts, one above the other on a single tab or you could superimpose the one chart on the other. I think having them on the same chart is best.
Burndown Chart Options
• Child Tasks Only (bool)
Allow for the excluding parent tasks when counting the number of remaining tasks.
• Default Hours Estimate (float value)
Use this value for any tasks that don't have the estimate hours populated. This is handy for those people who generally try an break out tasks into a specific block size. This allows them to only put estimates on especially small or large tasks.
Allow a value of Null which means that the tasks without an estimate won't have a weight.
The key benefit of this chart is that it will allow a TodoList user to get a real picture of how fast they are progressing through their task list and when they might realistically expect to be finished.
This would also make ToDoList suddenly very attractive to anyone that likes/uses the whole SCRUM methodology.
I just want to poke you about this idea again. From past/current experience working on a scrum team I can definitively say that this chart would be a huge plus for TodoList and all your users.
The sweet part about a Burndown chart is that it is immediately useful even if you never/ever enter estimates or start and end times. It also clearly shows you the cost of scope creep or poor design (as the line levels our or moves up) and it consistently puts the pressure on and helps you to stay focused on getting to zero.
Thx for the reminder, I had started to get focused on the Calendar upgrade, but I will definitely include an initial implementation of the Burndown plugin in 6.8 (in the same way that the current Gantt view is an 'initial implementation').
I love this project. It is what I need. I have also the same dream to write a software to use. If I need something, implement it myself. Enjoy such freedom! I also notice that the project is updated frequenctly. I admire this author. I am doing the same thing to write an useful software!
Depends how hard it is, how much time will be involved, and the risk of anything breaking. As you know, I am really snowed under for the next few months though. It is more that the ipad belongs to my significant other...
This is a great project, and I am happy to contribute where I can. This is an area of interest of mine, and your responsiveness and improvement rate is outstanding. Why wouldn't I support it?
Last Visit: 31-Dec-99 18:00 Last Update: 18-Sep-14 23:04