|
I don't have time to dig it out at the moment, but I recall reading in the forums there that the author of Stickies really didn't like the implementation of this apparently commonly requested feature. I have been meaning to go back and look to see if this had been dealt with differently in more recent versions.
|
|
|
|
|
Rather than just discussing technical matters, right now I'm wondering how people use the software.
When you flag a task as complete, do you leave the priority? If it was a high priority item, doesn't that leave this as a high priority but complete item? So do you downgrade the priority when its complete?
Does anyone remove the priority (set to <none> on items that are Complete or in another status that indicate no action should be taken? For example, I have statuses On Hold and Not Needed. Neither of these have a priority beyond Lowest or <none>.
What kind of pattern do you use to sort/filter your priorities for the day? Do you scan for a red High Priority? Do you sort by-descending priority? Do you generate a report?
Thanks.
|
|
|
|
|
FWIW I would also like to hear a lot more of these discussions to help me understand the types of people using TDL.
|
|
|
|
|
Unfortunately in this CP discussion medium we get about a week to discuss something before it falls off the bottom.
|
|
|
|
|
I tend to use priority a little loosely. I don't often change it once initially set (unless urgency changes - importance is usually unchanging). It is the challenge of having structured detail vs simplicity & intuition. I have found in the past that trying to keep the tasklist perfect results in me just working on the tasklist rather than the tasks. Working fully in a flat, task name & 'do date' only task list results in too much reactivity and a loss of focus on the longer term goals (for me anyways).
So no, I don't go back to change the priority. But then I hide completed tasks, so it doesn't interfere.
I have previously asked about a rules functionality that would do some of the 'admin' work for me. i.e. if this happens, then change that. TDL does this for the status when you complete a task. Perhaps Dan might consider putting in a preference to change the priority on completion also.
Note: Dan, I noticed that once the task is checked off, the status is set to 'Complete', and cannot be changed. Initially I expected the status value to just be changed, rather than locked down. I have had occasion to want to change it to 'Cancelled'. Not a major though.
How I use TDL is quite complex (used for managing tasks and managing the project portfolio also, all in the one tasklist), but briefly...
For tasks, I tend to work mostly on Due date for filtering purposes in Listview. I flag tasks that I want to tackle this week (somewhat subjectively, based on the situation, priorities, due dates, how I'm feeling...), then assign a day (custom attribute - it may be before the due date). I multi-sort, but could really use a 5 level multi-sort... Not ideal, but it works adequately.
Note Dan: Not sure if this is intended behaviour. I am finding that when in Listview and I change the Filter, the Sort is lost and needs to be reapplied.
Currently, I then move these out of TDL into a simpler view (no attributes - just taskname and the day it is to be done). I find this much clearer visually. I used to use a hard-copy notebook for this, but have moved to an electronic solution. Probably says more about me than it does about TDL... It does result in the problem of having to update tasks in TDL later.
Tasks that are 'nice to do' or less are given a low priority, and are given no dates. They get dates when I decide to tackle them. BTW, my work tends to be project based, and I tend to be able to set what I work on and when (within reason ).
I run my detailed report on a monthly basis to get an overview of the whole tasklist (filtered on dates), and make some updates after that.
Hope that is of interest. I am looking forward to seeing if your work with the library might help with some of my workflow (especially a simplified calendar view with the ability to uncouple the day a task appears on with its start and due dates).
zajchapp
|
|
|
|
|
Great info, thanks. About the library and a new calendar view - Sure, a developer can easily use any calendar component to display tasks based on any field available, like estimated due dates or a date from a custom column.
My usage of TDL is very different. My company has some long-term clients with software that needs mods and tuning over a period of years. Top level tasks under a given project include "add a field to a report", "create a web service", "create a new Excel workbook", or "research error 102 from process foo". Plus we get a lot of random requests from our industry. I rarely need to use due dates. The requests are more like "we need this" and after some initial discussion we're left to just do it as time permits over some reasonably short period of time.
When a project is defined I break it down into subtasks of about 3 hours each. I figure if I can't break it down further then the task isn't well defined. Most of my clients say they don't care how long something will take, but they need a real estimate so that they can budget costs and so they can report delivery estimates to their management. TDL is allowing me to get much better about providing estimates but I've found that some of my estimates are now "too real" and tend to chase new prospects away. Seriously, it's easy to under-estimate a project just to get a gig, to leave out things like possible communications issues, discussions, testing, etc. But these are real-world details that affect almost every project, so I add them in to the estimates. And because the estimates are so detailed, for larger projects I'm getting companies to pay for the time it takes to do the estimates - because I know for a fact that they're taking the TDL-generated reports and shopping them around to competitors. If a company accepts my proposal I'll credit them some amount from the cost of the estimate.
Tasks that haven't been started might be set with status In Planning or Not Started. When a task is approved it gets Assigned. As I or someone else works on a task, I flag the status as In Progress. If the client asks me to move to something else for an extended period, the status goes to On Hold. If I define a task that the client doesn't want done, I don't delete it, I set the status to Not Needed.
For daily efforts, I go back to open tasks by looking for In Progress but I've started changing the priority to get a better visual cue - tasks that need to be worked on now get a higher priority. I don't like doing that, and that's what prompted this thread. I don't know if we can do this already but I'd like to be able to set the color of a task row based on the status. An option would help to allow that color to be propagated to parent tasks. Over time, a task gets moved to Completed. Eventually siblings and parents are completed. I never archive tasks as we're frequently called upon to go back to completed projects for new mods.
For reporting I do an Export of all tasks, filtering out the ones that are Not Needed and a couple others. I go through that listing and check the status. I often find that a task that is getting active work is still flagged as Not Started, so I need to go back and change the status, then redo the export. It might be nice to get an enhancement to set a specific status on a task and all parents when time is logged.
Our reporting includes time logs with slightly modified versions of the new Analyses CSVs, filtered for the current time period. The export, per above, includes all open and completed tasks because it doesn't know which tasks were worked on recently. Ideally logging time might set a custom attribute which I can then use to filter the exported task data. Perhaps we could get an enhancement which updates the Modified date whenever time is logged on a task. And with that I think it should be optional to update the modified date on parent tasks. The idea here is that the export should include all "ancestry" as just a task name in isolation is ambiguous.
Based on a higher confidence in TDL, we're moving toward offering for-fee project management for our clients. This will include Gantt charts and new web-based reporting, emails, PDFs, and rich Excel workbooks created with the upcoming library[^].
|
|
|
|
|
Firstly, yes you can colour by status (although I haven't tried it). Go to Preferences | User Interface | Fonts and Colours | Task Colouring | Colour tasks by: and select Status. You can then set a colour for each of your statuses.
The challenge I have is the various uses I try to put TDL to. I am currently trying a new way of using TDL. My needs are possibly not overly unusual, but I have yet to find the perfect mix of effort vs benefit, complexity vs simplicity. For what it is worth:
1. Portfolio management
I need to manage a set of projects, and be able to report on their 'status'. This requires custom attributes for some meta-data such as 'Sponsor', 'Stage', etc to fit in with the company's system. Gantt reports are needed, and I have a special stylesheet to handle printed lists. This is normally done in Tree view, or Gantt view. Start date & due date and status are important.
2. Project management
Each project also needs to be managed (generally in waterfall mode). There are different columns visible for this function (some custom attributes too). The meta data is hidden, as the focus is different vs the portfolio function. This normally happens on a monthly basis, and happens in the Task tree & Gantt views. We have the Projects, Project phases, Project tasks, and Milestones.
I use one of my stylesheet reports to print current state, and sometimes a gantt chart. You can't save gantt baselines / change histories in TDL, but that doesn't worry me (I would export periodically to GanttProject if this were necessary).
3. Business as usual (BAU) Categories and Tasks. I also manage BAU tasks by grouping into categories, e.g. regular reports, regular meetings, budgeting etc,
4. Daily task management
As I now have a long list of project and BAU tasks (the leaves of the tree). They have an intended start and due date. On a weekly and daily basis (if I am being good), I select the tasks to do this week / today. I am trying to use flag and status more effectively for this. At the start of the week I also try to assign tasks to the days of the week, as discussed in previous post.
This is the task I find hard in TDL, as I would rather not touch the start and due dates. I have a variety of custom fields here also, including 'Action date', and some visual icon indicators of size and whether it is project task or BAU task (would be lovely to link these with built in attributes such as 'time estimated' - but that is unlikely I think). As mentioned above I tend to sort and extract the info out for a more streamlined view of things.
This activity is achieved in List view. If I need to communicate this, I can again use one of my stylesheets to print.
I don't use time logging, as it is too much effort for the benefit (it would only be for my interest).
I have started to separate out the task types outlined above (BAU Category, Project, etc) so I can more accurately filter. I have done this in the TAG attribute, to take advantage of the TDL function recognizing 'Milestone' in the Gantt. This also has the benefit of being able to find all projects (for instance), no matter what level or position in the tree they are.
zajchapp
|
|
|
|
|
Focus on task, change the status from the edit area.
The grid does a refresh with a bit of a jump, and while the row is still selected, it's no longer highlighted.
This requires a sort of hunt and re-select after changing the status.
This doesn't occur when other fields are changed.
HTH
|
|
|
|
|
1. 6.8 or 6.9?
2. Task Tree or List View?
3. Do you have a filter active?
|
|
|
|
|
Latest 6.9rc2, tree, no filters. Easily reproducible.
|
|
|
|
|
iamstarbuck wrote: Easily reproducible. Not for me apparently!
Can you reproduce it with a new tasklist?
|
|
|
|
|
Whoops, apparently I did have a filter on status, sorry. Does that help?
|
|
|
|
|
FYI, 'jumps' are almost always caused by refiltering. And refiltering is almost always triggered when the just-modified task no longer matches the filter.
So could you give me:
1. The exact filter that is active (all attributes pls, not just status)
2. The attributes of the task that pertain to the filter, BEFORE the status modification
3. The exact change to the status attribute
|
|
|
|
|
To test, we need a list with more rows than fit in the grid window (need scroll to see all).
Clear all filters except status.
For status, view all codes except one - the selection doesn't matter, we just need an active filter.
Scroll to view a task to the middle of the grid. There should be some items above and below out of view.
From the edit area, change that status to another one of the visible statuses, not the one filtered out.
In my list, the task jumps down to the last row in the visible area, or as far as it can go as the grid is now scrolled to display the first row in the list. The item is also no longer the selected row in the grid. It is selected in that it's still the active item in the edit area.
Does that help?
Best.
|
|
|
|
|
iamstarbuck wrote: Does that help? Very much so, thx.
|
|
|
|
|
If I take a dropbox link (https://www.dropbox.com/s/stuff.tdl?dl=1) and change the https:// to tdl:// - it is expected that the expected will result?
Intriguing possibilities.
Note:
- not a real link.
- ?dl=0 takes you to a web page, ?dl=1 is a direct download.
- File / Open / <url> fails (in TDL), which is to say, ... the fetching of the file would almost seem to be an OS thing to handle (but it doesn't), so not entirely sure this is a TDL 'thing'. OTOH - this is also akin to a (.tdl) e-mail link, a la .doc, .txt, .etc link.
If you consider the thread elsewhere that talks about a 'Table of Contents' list (be it an html page your browser brings up) containing tdl:// type links ... hmmm.
|
|
|
|
|
'tdl://' does not handle web links.
|
|
|
|
|
Granted, was only saying it would be interesting if it could.
Part of what I was getting at is this would almost seem an OS thing, not a tdl thing. e.g. On a Windows shortcut, it can handle either. On the command line (start/run, double-click, whatever) it triggers the protocol handler, e.g. tdl or browser (on http). I'm guessing if the OS were able to directly open the file, then TDL could. [Granted, the browser asks where to save the file - so OS doesn't save the file directly / handle the magic on the calling program's behalf.]
Anywho, TDL upon sensing an URL might use wget to fetch a temporary file rather than open() [or whatever], then open the temporary file. Tossing it when done. [User can do save as if they want to keep it, much like any e-mail attachment.]
Don't know if the functionality gained is worth the aggravation to implement, but the thought is intriguing.
|
|
|
|
|
In Analyse Logged Time, the File Path isn't remembered from prior calls. I tend to put all of my reports in a different folder from tasks, like .\Reports\...
For future consideration :
I also change the file name based on the (ending) time period and breakdown type. For example:
...\Reports\CustName_ByDay_141031.csv
It would be helpful if we had an option to automatically set these file names with all data used for the selection. For example:
ListName_BreakdownType_PeriodType_FYFMFD_TYTMTD.csv
FYFMFD are the From date fields, if used and TYFMTD are the To date fields. Any character or null can be used if the date isn't used for the report. The types correspond to the index of the field in the form.
From there a UDT or separate app/macro can easily rename the files to suit personal preferences.
Thanks.
|
|
|
|
|
iamstarbuck wrote: In Analyse Logged Time, the File Path isn't remembered from prior calls I'll get that fixed in the next RC.
iamstarbuck wrote: It would be helpful if we had an option to automatically set these file names with all data used for the selection I'm happy to include something in 7.0.
|
|
|
|
|
When we create a link to a task, we can get a partial link or a full link:
tdl://327 or tdl://C:\Users\name\Documents\Tasks\ListName.tdl?327
But that doesn't mean anything outside the context of the local system. The short link requires the person viewing it to have the right task list open.
I'm thinking it might be helpful to have an intermediate link, not as terse as the first, not as specific as the second. This might look like this:
tdl://ListName.tdl?327
That would open whichever ListName.tdl is found in a user's current ini. If there is any ambiguity, OK, it won't open, just display a message. But we already have a similar problem with either of the current options.
Another option might be a bit far out but I'd like to know if anyone else sees a benefit in the concept. What about a globally unique task ID which can be generated on any given task. When TDL opens this, a check can be made in a database (local or remote, not sure yet) which will work out which .tdl the user has locally that contains the specified task. So on my system I might access the list via DropBox, but on your system you'd get it with a different DropBox link, but your system should know where to find the .tdl even if I created the link on my system. The way this would happen is that the application would periodically go through a .tdl and get the local GUIDs, and store them in an external database for the user. Then when a GUID is encountered, that user's system would know where to get the task for that specific GUID.
Thoughts?
|
|
|
|
|
iamstarbuck wrote: But that doesn't mean anything outside the context of the local system Is this a feature you actually need or are you just coming up with an idea?
|
|
|
|
|
Thanks to @Dan and @_BS_ for responses.
This is completely brainstorming - no personal need at the moment.
I was editing a program from a local SVN repo. It contains tdl:// links for changes. It occurred to me that it would only work in a very limited scenario - like on the system of the developer who first wrote it, but no one else's - same goes for a link shared among any small group really. Bugzilla links, by comparison, are completely easy to follow because all of us can click an http link that goes to an internet-based website for centralized data. So I started thinking about ways to make the task links a little more useful for a team, though not global.
For reference, with the library, we Can extract tasks and make them accessible via web pages or web services (a sample in the library already does this). So if anyone wants this kind of task link, I guess at some point we should be able to create a UDT that generates a company-specific URL into the clipboard which can then be inserted into code. Click that and you go to the net-based rendering of a task, not necessarily to TDL itself.
Not knowing how many people use TDL in a group environment, I have no idea if this is useful or completely off the wall.
|
|
|
|
|
Oh it's useful, been an issue for as long as I can remember, back to at least Palm / ShadowPlan days - thus the central / initial ToC idea. ('First' item in any list is link back to ToC.)
Even for individuals, you may have groups of lists, and different lists in different contexts / hats (dayjob, volunteer job, jobjar(=wife)jobs), perhaps even from different computers/OSs within the home. At which point kids and spouses become contributors ... and you've got a group environment.
[Then try to jot something on a home list from work or public wifi and ... you're exactly into use cases you describe.]
You also get into chicken and egg - any such effort inevitably ends up pulling in multiple app files. So is the link from a calendar out to .tdl files, or from .tdl files out to a calendar (with, for example, .jpg links to family holiday pics). Same thing happens with a photographer's catalog or journal.
Problem is coming up with use cases to which programming can be applied, if it's not easier to do the programming in a wrapping app. i.e. It gets strange, fast, perhaps even one off solutions per environment, making it hard to come up with a generic algorithm worth developer implementation time for the value resulting. i.e. Enough similar use cases to which the general algorithm can be applied to, from tdl out vs to tdl in.
|
|
|
|
|
There is value to what you say, however there is a problem of relative to what. (The context of the user at that time. Then someone else somewhere else, some minutes later.) [Mind starts to boggle trying to track permutations.]
e.g. I would have expected your tdl://file.tdl link to find the .tdl in the current directory (never mind current exe, ini, or tdl directory of the moment - that's yet another wrinkle), not the last used same filename reference within the .ini file.
I have recently thought that wildcarding in the tdl:// links would be useful, e.g. tdl://{exedir}\thisone.tdl, with multiple possibilities for {}'s, exe dir, working dir, tdl dir. I bog down in that although save or edit time substitutions could be made to replace the {}'s, how someone else is to interpret at read time gets weird.
Your note does make me think though, there could be {TAGS} somehow defined. So, for example, in my preferences I could list my local path to my dropbox, you could do the same for yours, and tdl://{DROPBOX}\OUR-SHARED-DROPBOX-FOLDER\thisone.tdl links become possible. [Too bad windows doesn't have linux links.]
[I'm in the middle of 'app' developing this right now, thus my earlier question about tdl://, relative links, and how to sleuth out what's actually being called. So, I've been using relative links, and some scripts - users double-click on a .cmd file to maintain any given list, and being relative should work for anyone with whom the dropbox folder has been shared.]
I don't think your use case of outside your system applies, for a group of users I would have thought it would be outside your network. i.e. Users within the same network would have common mapped drive letters to the .tdl data areas, and all be able to call them with the same paths. (For that matter, Windows junctions would probably also work for you here.)
I do get your point for outside your network, but you're then talking a lot of grunt work on your end for the maintenance of cross-network common links. (Isn't a globally unique task id the entirety of 'listid.tdl?#'?)
Some of what you talk about would be solved by an old ShadowPlan era concept, a TOC file - One list per line, with a (relative?) shortcut to the list in the comments. [I do an html version thereof above for list readers - the list maintenance .cmd accessible only to those with whom the dropbox folder has been shared, .cmd because after the tdl call is a couple of msxml calls to create read only versions of the list - dropbox link shared and referred to in a link shared index.html file - dropbox as a mini static web server.]
So for your cross-network links, perhaps a crafted web page makes sense? Then your apache could build in intelligence for sleuthing out files and paths, perhaps as a cronjob. [Assuming the links are equal within a given network.]
In essence, you're also talking about 'publishing' lists within a network - and perhaps that is best as a manual process? i.e. Specific request to publish a list kicks in a bit of .html editing, rather than an automated find everything and make it all public process?
Which could be project specific. e.g. If you have a central project area, and .tdl's in sub-directories by project id, you might automate sleuthing out a ToC for those files, but perhaps not elsewhere within your net? Even that might be an .html solution, as presumably you have per Project ToC pages of some sort. e.g. Project 1 ... link to Business Case, link to Risk Analysis, and so on. In essence you also get 'sub-system' sets of .tdl's out of this idea as well.
It also sounds like you are creating new paths of access, similar to google drive, dropbox, ftp(?) access mechanisms already present. [i.e. Some of the concepts and coding and sweet spots may already be present?]
|
|
|
|
|