|
[d3m0n] wrote: But I think the real killer would be to make each item in a column editable. That would get rid of the controls on the bottom, so you can see more of your tasks. I know it might be difficult, but just think for a minute how nice it would look. It would make editing a lot easier. You could use Tab/Shift+Tab to move around the columns.
I was writing this one in my comment too, but we need to think of an elegant way to keep the 'change attribute for all selected tasks' function (ie select 3 tasks and change the due date for all of them). Maybe you'd select all of them and then change one of the inline due dates...
|
|
|
|
|
[d3m0n] wrote: But I think the real killer would be to make each item in a column editable. That would get rid of the controls on the bottom, so you can see more of your tasks. I know it might be difficult, but just think for a minute how nice it would look. It would make editing a lot easier. You could use Tab/Shift+Tab to move around the columns.
Sorry, I disagree here. I can see your point, but it would require to show much more columns (and you have only one row per task!) which would end up in scrolling left/right all the time to see various informations. If such thing would be an option, I can live with it, because I wouldn't use it. But I would not want to see this hardcoded.
Short explanation:
In my case, the columns only show the most important fields. The fields below the tasklist show this plus all other information I want to see (plus fields I never use, which I would like to be able to get rid of).
Best regards,
Martin
|
|
|
|
|
I have depended on ToDoList for over a year and wouldn't have done so if the interface was "ugly and painful." Perhaps the author of the quotation should have tried using the software for several complicated projects before giving this opinion. I'm reminded of the "usability engineers" that work with me and development teams on software projects. Occasionally they propose changes to a UI that show they don't understand what the "value proposition" of the software is. The value proposition of ToDoList is to help one manage an otherwise unmanageable set of tasks, and to do so in a way that supports multiple levels of complexity, frequent and substantial changes to the organization of the tasks, and copious records of work on each task.
I use the Category, Dependency, Due Date, Flag, Percent Complete, Position, Priority, Remaining Time, Risk, Start Date, Status, Time Estimate, Time Spent, and Track Time columns. Every morning before I do anything else, I sort my tree on Due Date and also on Priority. I read my comments on the tasks that are at or near the top. I also look at tasks further down. Then, I flag each task that I intend to work on that day. When I work on a task, I use the Track Time feature. If a new task comes up, I can easily create it as a new task either under an existing parent task or not. (I have some tasks that are 8 levels down, by the way.) In the comments for tasks, I summarize discussions, meetings, or my own work. Most importantly, when I have my twice-monthly status meeting with my manager, or whenever any higher-up wants to know what I'm doing in a certain area or project, I can sort my tasks on the categories that I've created and explain my work quickly and thoroughly.
One more example: each member of the team that I work on was recently asked to send our team lead a list of the new software features that we are working on, as well as our dates, whether we have all of the info we need, and what our progress has been. I simply selected and exported the right tasks out of ToDoList and into a spreadsheet. In a Comments column, I added comments based on the records that I keep in ToDoList. Of 25 members on our team, my "report" (I was told) was the only one that gave my team lead exactly the info he needed.
"Ugly and painful"? How about as detailed as you want it to be, simple to use, and career-advancing because it helps the conscientious person to stay on top of what he is doing and to explain it to higher-ups?
|
|
|
|
|
Many thanks for your considered opinion and for avoiding the urge to task a feature request on the end
|
|
|
|
|
Very well written!
And if I might add, even if Dan is not going to improve the UI, I see myself still using this great peace of Software in years ahead of now (I'm already using it since years *g*), because:
- the program works!
- it lets me do all I want and need to do!
and that is what counts for me. Everything above that (like the suggestions posted) is a bonus for me.
BTW, I think this is a good time to mention that TDL is still a free piece of Software, and that we could support Dan by either helping with a translation into a foreign language and/or by hitting the "Donation" button in the help menu.
Best regards,
Martin
|
|
|
|
|
Thanks Martin.
ps. The Wiki Translation should be fixed now :hopeful:
|
|
|
|
|
.dan.g. wrote: ps. The Wiki Translation should be fixed now
It doesn't look good with the page. Even the Wiki support reverted the changes back.
edit: I just tried to updated the page, but then again, all the content was deleted.
@dan: did you receive information from the PBWiki Support about this issue? Can/will they resolve it?
Best regards,
Martin
modified on Wednesday, February 25, 2009 6:12 AM
|
|
|
|
|
ToDoList is not ugly or painful, sure there's always room for improvement (maybe a little for the GUI). Still a great tool and a very practical tool to use.
gman8779
|
|
|
|
|
gman8779 wrote: sure there's always room for improvement (maybe a little for the GUI)
I would welcome any suggestions.
|
|
|
|
|
If you compare it to a web application designed for Joe Public, then ToDoList certainly looks functional rather than groovy. That's a very good thing.
I suspect whoever wrote that comment isn't in need of a serious application. The words "ugly and painful" give it away.
Dumbing down the UI won't help anyone. Dan, you already get constructive criticism on this message board, and your instincts are normally spot on.
It ain't broke, so don't try to fix it.
|
|
|
|
|
|
I can't agree with the criticism you cited.
I find the user interface quite intuitive.
It's far from 'ugly and painful'.
I see a small weekness in the printing interface:
The stylesheet approach is very powerful, but not
easy to use without experience in this field.
Frank
|
|
|
|
|
Frank Mueller wrote: I see a small weekness in the printing interface:
The stylesheet approach is very powerful, but not
easy to use without experience in this field.
I totally agree.
|
|
|
|
|
I’m very happy with the interface. I couldn’t find the review you mentioned on google, but would imagine they said it because a) It doesn’t look like Office 2007, and b) Some people look at a tool with more than 3 screen elements and say it’s too ‘complex’ and not ‘accessible.’ But those people aren’t the target TDL users anyway- they’ll be using tasks in outlook or on paper. Don’t be tempted to dumb TDL down!
I manage really long lists and have tried to think what would make interfacing easier.
- Collapsible ‘Section markers’ you can insert in the tree which can be collapsed, similar to ‘regions’ in visual studio which you can collapse. Each section could put a little stripe of its colour a few mils wide, at the left of the tree so it doesn’t affect task colouring etc, but you can see where it starts and ends. Visually breaking the list up would be great.
- If no ‘section markers’ were possible some way to make higher level or 'milestone' tasks stand out would be good (formatting for each level, using extra icon types in addition to folders, or something).
- The reason the lists get big: I start a task called ‘blah project’ which evolves into something huge. I’d like to split it up or archive, but this changes their ID. I use the ID’s in my email subjects to people so I can search for related messages, so I can’t move them. A global UID (which isn’t overly long) for each task would fix this- it’s not an interface issue itself, but it’s the reason my lists get really long. Maybe the user level UID could live in the ini file so you can set it to your desired 'continue from' number if you reinstall elsewhere.
- Docking windows etc is ‘nice’, but if that means adding lots of components, ribbon controls etc, there’s no way its worth it for the loss of speed and stability. Simple is good.
- Horizontal scrolling only scrolls one of the controls rather than both.
- Minor tidy ups like hiding the rich text/plain text selector and leaving that in the options, removing the ruler etc would save a bit of screen real estate. You mentioned a possible move to HTML editing- I do find lots of tools with HTML editors have annoying habits with tabbing/editing, and double spacing text unless you hit shift-enter on each line. If it meant having table support etc it could be worth it but there would be lots of bug swatting to be done I’m sure.
Hmm, I'll have to think about if there are other things. In summary, it is the best app of its kind and due to all its features will always scare off users after a 'bare bones' app. There are a million bare bones list apps, so let them use those!
Cheers mate
|
|
|
|
|
Once you use it, I think it is the opposite of ugly and painful - it is quick and effective to use even for non-techie users.
Initially, though, it can look very complex and busy - and that can put some people off. But having everything visible on the page is a very quick way to learn what the prog can do and then makes it much faster to work. It could look simpler, or more colourful (look at MLO or ThinkingRock) and less rectangular - and maybe that's what the writer was wanting. Posibly I was a little put off when I first loaded it - but after using the prog for a short while, I came to the view that not only did I like the design, but that the design is what made it relatively easy to use for a complex program.
|
|
|
|
|
you might want to check out the palmOS pimlimco datebk5 application. In particularly, the profile functionality in there. It is amazing. Basically the profile features allows the user to choose from pre-defined sets of program preference.
The implication is that one can have a profile for setting recurrence, another for looking at priorities, yet another for setting file links, etc. This reduce screen clutter and allows the user to focus on the attributes that he or she is interested in at that time.
rather than keeping all the fields / attributes visible and building up screen clutter.
|
|
|
|
|
Thank you, .dan.g. for ToDoList.
I use it almost everyday, both professonally and privately. Keep up the good work. You are my hero!
|
|
|
|
|
|
Hi,
we use ToDoList in collaboration on a Windows 2003 Terminal Server.
When i use and save my private ToDoLists in my private homedir (H:\Projekt\ToDo), the directory i set as workdir in the windows shortcut on my desktop, all is working fine and i can save and archive my completed tasks. They are removed from the normal tasklist, and appear in the archive (<listname>.done.tdl).
BUT, when we use a ToDoList, that is stored in another directory (say: J:\Mandant\ToDo), which is on another server, and is accessable by multiple persons, i can't archive the tasks. I can load and save the list, and it is updated when somebody else is making changes, but there is no archive that is being loaded by ToDoList. "Archive completed Tasks" will move the completed tasks to /dev/null, i suppose. however, the tasks are gone. It seems like we lost a lot of tasks. When i move this list to my private folder (H:\Projekt), i can use the archive, and all is working again.
could this be a bug?
thanks
T.
|
|
|
|
|
Torsten Mueller wrote: could this be a bug?
It could be. What I'll do is add some code to log what path ToDoList is archiving to and then get you to run ToDoList with the -l switch and send me the log.
|
|
|
|
|
Thanks for the Message.
After updating to 5.7, which i expected to have the "added code for logging" already inside, now i have another problem:
the new screen effect that grays out the screen objects while highlighting new popup dialogs, doesn't work when in maximized mode on a terminal server 2003. rather than showing up the dialog, it places the new window "under" the main window, and i can't move anything (!) on the whole desktop. after pressing ESC (and thus closing the dialog) all is working again, but the graphics are somewhat screwed up. i have to minimize and maximize the window in order to get back a working, clean ToDoList.
another point: when shrinking the window to 800x600 (or the like), i can see the popups together with the fancy fade-out effect (by the way: makes the app cpu-consuming and slow!) again, but the window is so small it can't be used. when i slowly "grow" the window, after some point it doesn't work anymore like being in maximized mode.
on my Windows XP notebook all is working fine, even in maximized mode. but since we use TDL in a collaboration on our terminal server, this effect renders the tool completely unusable for us.
can you make this optical gimmick switchable in the settings?
many thanks!
T.
|
|
|
|
|
Torsten Mueller wrote: can you make this optical gimmick switchable in the settings?
It should be able for me to detect when ToDoList is running under Terminal server and disable it. I'll fix this immediately.
|
|
|
|
|
Hello Dan,
I've been having trouble working with my files in ToDoList.
The problem started after I gave the program a round trip to and from the quick launch bar (My OS is Windows XP): I had dragged what I thought was TDL's shortcut from a file folder into the quick launch bar; then, after deciding that I didn't really want it there, I deleted the icon from the quick launch bar. Then when I tried to open my TDL tasklists either from their shortcuts stored in several folders or directly from the program's folder in "Program Files," I got messages saying either that the files couldn't be found or that the shortcuts no longer worked. I finally looked in the recycle bin and found them there (I had no idea how deleting icons from the quick launch bar could send the files themselves to the recycle bin).
After I restored them, those files seemed to work normally at first; but then I started to get this error message: "[Application name] has encountered a problem and needs to close. We are sorry for the inconvenience. If you were in the middle of something, the information you were working on might be list. Please tell Microsoft about this problem. We have created an error report that you can send to us, etc., " followed by 3 choices: "debug, send error report, or don't send." Clicking on "debug" would close the application and the message box, while clicking "Don't send" would bring up this dialog box: [File name - Application name] - Application Error: The instruction at [a letter and number series] referenced memory at [a letter and number series]. The memory could not be 'read'. Click on OK to terminate the program." At first these error messages would crop up intermittently while I used the application; after a while they started to appear as soon as I entered new data in a tasklist.
I tried deleting the program folder and then downloading (I no longer had the zip folder I downloaded before) and unzipping the program again; I tried both the 5.6.6 and the 5.7 beta versions; I tried opening my tasklists from within the newly downloaded programs, or importing the tasklists into new files in them. The above problem, however, has persisted. It stopped for a while after I imported a backup of a tasklist, but then it came back.
Please advise what's the best way of getting rid of the problem. Many thanks for your help!
|
|
|
|
|
If I were to have a stab in the dark I might point the finger at MSXML.dll but this may be a red herring.
It may also be that the tasklists are corrupted in some way. If you trust me, feel free to send the tasklists to me to see if I experience the same problems, or a co-worker if the contained information is sensitive.
|
|
|
|
|
Hi Dan,
Thanks for the reply. I just emailed myself one of my TDL tasklist files which kept generating those error reports, switched over to the other partition on my computer, Drive C (I usually use the D drive, where the problem occurred), downloaded and extracted ToDoList 5.7 to Drive C, and opened the attached tasklist in my email, and it started to behave normally again--entering and saving new data worked O.K. this time. What does this mean? Could my deleting TDL's icon from Windows XP's quick launch bar have messed up something in Drive D rather than corrupted the tasklist files? I haven't yet downloaded 5.7 on Drive D (I now have both 5.6.6 and 5.7 beta there, which were both getting the error msgs when used)--I figure I'd better not do anything else until I get some advice from you as to what is the best course of action for getting ToDoList to work again on my partition (Drive D). Many thanks for your help.
R.S.
modified on Saturday, February 21, 2009 12:02 AM
|
|
|
|
|