The Omni Group Forums

The Omni Group Forums (http://forums.omnigroup.com/index.php)
-   OmniFocus 1 for Mac (http://forums.omnigroup.com/forumdisplay.php?f=38)
-   -   Feature Request: task prioritization! (http://forums.omnigroup.com/showthread.php?t=3836)

Weasel 2007-07-19 02:56 PM

1 Attachment(s)
I love the idea, it is kind of similar to LB's scheme of importance.

[IMG]http://forums.omnigroup.com/attachment.php?attachmentid=260&stc=1&d=1184885516[/IMG]

Having experienced this feature for the last few years, I know I'd like to have a more graduated scale. I had asked for adding just 10 little marks below the slider. Some kind of visual clue...

On the same note I prefer the little squares on the screen when adjusting the volume on a mac over the drop down slider from the menubar.

GeekLady 2007-07-19 03:29 PM

I love it.

Beautiful.
Elegant.

Probably too much for 1.0, but I would cope with flagging if I knew something like this was coming in 2.0
[QUOTE=curt.clifton]Here's a crazy idea for consideration ... Without rehashing the debate about the GTD-osity of priorities, I'd love to hear what others think of this idea.[/QUOTE]

Ken Case 2007-07-19 03:52 PM

[QUOTE=curt.clifton]Dragging a task to a new position in the list would set its priority slider to the average of its two new neighbors. Thus, rearrangements in context view would "stick".[/QUOTE]

It turns out that this is exactly how we order actions now: each action has a "rank" which is assigned based on its position relative to other actions in the list.

It sounds like the proposed change, then, would be to allow actions to have individual ranks in context view rather than forcing them to only have child ranks within their own project. This would let you interleave actions from different projects in context view, effectively assigning individual priorities to each action (based on their position).

Ken Case 2007-07-19 04:00 PM

[QUOTE=Ken Case]It sounds like the proposed change, then, would be to allow actions to have individual ranks in context view rather than forcing them to only have child ranks within their own project.[/QUOTE]

I should mention that we've considered this approach somewhat already, and the big sticking point has been that we're worried about performance when you have to rerank everything to make room: right now you only have to rerank the other actions in your group (hopefully not more than a dozen or two—which also makes it unlikely that you'll ever have to rerank at all), but in this other system you'd have to rerank every action in your database (including the completed ones, since you want to preserve their order as well) whenever you run out of ranks between two items (which would happen much more often).

Of course, that's not nearly as big a problem if you have a separate priority field rather than using it as the only indication of order. (Maybe an easier path would be to just give people more flagging options, so you can flag something as "high" or "low" priority rather than just "a" priority?)

Ken Case 2007-07-19 04:16 PM

[QUOTE=Ken Case]right now you only have to rerank the other actions in your group (hopefully not more than a dozen or two...[/QUOTE]

Pardon me while I reply to myself yet again, but I thought I'd mention that this is not to imply that it's unreasonable to have hundreds or thousands of actions in the same group, just that that's a lot less common than having that many actions in the entire database.

curt.clifton 2007-07-19 04:23 PM

Ken,

What would it do to the performance if the priority was stored as a floating point number instead of an integer? For all practical purposes there are an infinite number of floats between any other two floats. (Of course that isn't technically true, but I suspect disk capacity issues would arise before anyone exhausted the precision of 64-bit floats.)

Weasel 2007-07-19 06:56 PM

[QUOTE=Ken Case](Maybe an easier path would be to just give people more flagging options, so you can flag something as "high" or "low" priority rather than just "a" priority?)[/QUOTE]

Multiple levels of flags would be fine and quite help to achieve my goal if the sorting by flag status is possible.

Another thought, if you add multiple levels of flags, would this not be after all a priority system which some of the forum members so vehemently fight against?

And as I understand many of the anti-priorities faction use one level flags and they would probably not be happy with multi-level flags?

Would it not be possible, and maybe more considerate to all sides, to add the priorities system as a separate feature and have an option in preferences to enable/disable it?

al_f 2007-07-19 11:29 PM

[QUOTE=GeekLady]I think that this constant harping on how priorities change too quickly to be worth keeping track of is really falling into one of the traps GTD is designed to help us avoid: [B]don't stop to immediately process a new task or piece of information, unless it's absolutely necessary.[/B]
[/QUOTE]

I don't think that really has much to do with whether pre-assigning priorities to tasks is canonical GTD or not. I'm pretty sure it's not, but I think we'll have to agree to differ on this one as I don't want this to turn into a "priority vs non-priority" holy war. :)

Suffice it to say that I don't mind if there is a priority system in OF as long as it's hidden until you choose to use it and it doesn't degrade perfomance. I personally wouldn't use it, but if it works for you that's great.

markbrown00 2007-07-20 12:17 AM

I've said previously that I couldn't see myself using a priority feature (although i don't mind if it is there for others)...however, i probably would use a dragable priority system like Curt suggested

BwanaZulia 2007-07-20 12:46 AM

[QUOTE=al_f]I don't think that really has much to do with whether pre-assigning priorities to tasks is canonical GTD or not. I'm pretty sure it's not, but I think we'll have to agree to differ on this one as I don't want this to turn into a "priority vs non-priority" holy war. :)[/QUOTE]


Too late. :)

BZ


All times are GMT -8. The time now is 03:44 AM.

Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2024, vBulletin Solutions, Inc.