+1 here.
Which leads us to the "right" answer which would be to split things
into 3, 1 being the outline/list pane, 2 being the properties and 3
the notes and then allowing the user to decide how to arrange same to
suit.
How much of a challenge this is depends on the capabilities of the UI toolkit...
--
Murph
I think part of the problem, at least for me, is that the way the
shortcuts work currently isn't intuitive, because there's no symmetry.
Alt-1 toggles between the task list, on the left, and the task notes,
which is a tab on the right.
Alt-2 through Alt-6 toggle between the task list, on the left, and a
portion of the properties tab on the right; they also show and hide that
part of the properties accordion.
Alt-F1 says "Properties pane", but it really shows and hides the whole
right-side pane, which includes both Properties, Task Notes, and the
text box with the full name of the task.
It's very awkward to use; I always have to think about what exactly I
want to do, instead of just doing it. I can't particularly think of an
easy fix, or desired behavior, but if nobody else has suggestions I'm
sure I could come up with something.
Check the checkbox on a project to show that it's completed. Look at
the status: Not started.
Uncheck that checkbox, add a task, and check off the task. Now the
project is still "not started", but 50% complete.
I can't think of any reason it should work that way! It seems that the
attribute "This is a project" doesn't mean anything to MLO, other than
setting its own checkbox. It should affect behavior, in these ways and
probably others.
Jay
I agree this would be the ideal solution.
Steve
Again as with a lot of things in MLO there are two ways of looking at it overall. The first is that the project status should be configured by the user. The second is that projects should automatically have their status updated by the system, depending on the actions that are taken.
Now if the status is configured by the user, it means the user has control. Completing a project related action, doesn't start the project. Marking off all the actions for a project doesn't mark it as complete. It is up to the user to decide on the status of the project. So you could have a project with multiple actions already completed, that you might want to record as part of the project. But the project doesn't start in earnest until some time later, sort of prep work for example. Personally I like the status being a manual option, it means I have to actively participate in updating and setting project status. I personally think it makes me review projects more than I would if it was an automated process, I have a better handle on what is started, suspended, complete etc.
At the same time, there is obviously a second viewpoint. That project status should be an automated process, if you complete an action the project should be flagged as started. If you complete all actions the project should be marked as complete. If you suspend a project it should hide actions in the ToDo list etc. I see the validity of this point of view as well.
I wonder if this should be handled by confirmation dialogues? So in other words if you complete an action on a project that is not started, it questions you 'Project has not been started, do you wish to update the status to started?' sort of thing. All actions complete 'Mark Project as Complete?', If these confirmations could be turned on and off, then you could have a happy medium between the two different perspectives. An automated approach if they are on, a manual approach if they are off. I must admit I am not a big fan of confirmations, I think they get in the way. Perhaps alternatively having a separate option, manual project control, automated project control. Depending if this is on or off, indicates which behaviour you want to represent.
All the best
Steve