James:

I'm in a situation in my life at the moment where I find myself at the computer at all hours and frequently when a QR action is about to start or is in process. As you know, many of QR's processes really take over the CPUs, making my work grind to a halt unless I cancel the action.

If it is at all possible:

1. Could QR play more fairly with the other children? Share the CPUs in a less monopolistic fashion?

and

2. Could QR's activity monitor gain a "Pause" button, obviating the need to remember to launch QR and manually start a canceled action? (Of course, one would still need to restart the action from the activity monitor, but...)

(Just noticed this thread and see you've already gone in depth into the question of responsiveness.)

Thanks!

Steven M. Alper wrote:1. Could QR play more fairly with the other children? Share the CPUs in a less monopolistic fashion?

That's the job of the operating system. QRecall just does its thing. It's up to the kernel to balance the load amongst multiple processes.

That said, there are number of ways in which QRecall can be less of a burden on system resources. Significant ones have already been done, which you'll see in the next release. Others I'm still experimenting with.

2. Could QR's activity monitor gain a "Pause" button, obviating the need to remember to launch QR and manually start a canceled action?

A "pause" button is interesting, but I'm worried the process could be left hanging indefinitely. What would you think about a "reschedule" button that would appear if you cancel an action?

James Bucanek wrote:
A "pause" button is interesting, but I'm worried the process could be left hanging indefinitely. What would you think about a "reschedule" button that would appear if you cancel an action?

You mean like Apple's Address Book's alarm: Repeat in 1 minute; 5 mines, 30 minutes, 1 hour, 1 day, 1 week... etc.? That would be fine, although I think it should be a separate button on the activity d.b. so that you don't have to go through another screen if you really do want to completely cancel at this point.

Of course, the other way around, if the user left the pause "hanging indefinitely" they'd always have the activity d.b. floating around to remind them.

Steven M. Alper wrote:You mean like Apple's Address Book's alarm: Repeat in 1 minute; 5 mines, 30 minutes, 1 hour, 1 day, 1 week... etc.? That would be fine, although I think it should be a separate button on the activity d.b. so that you don't have to go through another screen if you really do want to completely cancel at this point.

I was considering two interfaces: If the action was canceled, an additional "Reschedule..." button would appear in the confirmation dialog. Click it and the "Run At..." dialog would appear.

Alternatively, I'm considering adding these kinds of "power user" features to some contextual pop-up menus, rather than cluttering up the core interface. If you right/command+clicked on a running action, "Cancel and Reschedule..." would be one of the options.

Of course, the other way around, if the user left the pause "hanging indefinitely" they'd always have the activity d.b. floating around to remind them.

Assuming they haven't closed it.

James Bucanek wrote:I was considering two interfaces: If the action was canceled, an additional "Reschedule..." button would appear in the confirmation dialog. Click it and the "Run At..." dialog would appear.

That's what I think you want to avoid, a multi-step process for a simple cancel. If I want to cancel, I just want to cancel. It's like those annoying "Are you sure you want to quit" or "Are you sure you want to revert" d.b.'s -- yes, I want to revert! why do you think I clicked the button?

So if you've got two buttons side by side -- cancel and reschedule -- no extra steps for someone who just wants to cancel and wait for the next scheduled event.

Alternatively, I'm considering adding these kinds of "power user" features to some contextual pop-up menus, rather than cluttering up the core interface. If you right/command+clicked on a running action, "Cancel and Reschedule..." would be one of the options.

I honestly don't think adding a "Reschedule" button to the pretty-sparse-already activity floater is really clutter, especially considering the benefits to the user. And I don't think rescheduling should be considered a power-user feature; everyone's going to want to delay a process at some point. If you want to save space you could replace the button with a pull down menu -- I don't know what the default would be... "Interrupt"? -- with "Cancel" and "Reschedule" as the selectable choices.

Or you could have two symbol buttons: an X for cancel and a return symbol (that arrow with the stem bent to the left) both of which gave a pop-up menu -- "Cancel" on the X and maybe a list of predefined choices "Resume in 5 minutes," "Resume in 15 minutes," "Resume in 30 minutes," "Resume in 1 hour," "Resume in 2 hours," and <drum roll>"Pause and remain open."</drum roll><cymbal crash></cymbal crash> on the other.

(This is also in response to the following quote....) The "Pause and remain open" choice could lead to a subsequent uncloseable float and fade d.b. like the current activity d.b. with a prominent "Resume" button.

Assuming they haven't closed it.

Wow, I haven't given quite so much thought to interface since I designed the interface for a fake competitor to AppleWorks and MSWorks: ArmidilloWorks. That was for something David Pogue did once upon a time....

Best,