How do you expect macros to behave?

[tranglos]

Joel Spolsky says in one of his essays:

A user interface is well-designed when the program behaves exactly how the user thought it would.

It's also been called principle of least astonishment^w. So here's something that's been puzzling me for a long while: the behavior of macros. Leaving aside how macros work in popular software like Word, how do you expect macros to behave in these three situations?

1. While recording a macro, you use Edit|Paste. What should happen when replaying the macro?
a) the macro should insert the same exact text that got inserted by Paste when recording.
b) the macro should insert current clipboard contents (or nothing if the clipboard is empty)

2. While recording a macro, you use the File|Save As command and specify a new name for the document. What should happen when replaying the macro?
a) the current document should be saved using the same filename that was specified while recording (possibly overwriting an existing file)
b) the macro should display the "Save As" dialog box, letting you specify a name, just as if you clicked File|Save As manually.

3. While recording a macro you select some text and click Format|Bold. The text was using normal style before, so now it is bold. What should happen when replaying the macro?
a) regardless of whether current selection is bold or not, the macro should make the text bold (leave it bold if it was bold already)
b) the effect should be the same as manually clicking Format|Bold: if text was normal, make it bold; if text was already bold, make it normal.

There is no perfect solution, of course. Each a and b choice has its downsides. Number 3 is especially bothersome for me, because it's very common to have this kind of toggle, and I can't decide which behavior is more useful or more "natural".

All (a) choices are "do exectly what happened while recording", while all (b) choices are "do what would happen if the command was invoked manually in the current document". So what is your preference? Straight As, straight Bs, or some combination?

marek

[mouser]

As you say there is no perfect objective answer.

And so before i answer, here is how i would hope a great macro program would work, which I think is more important:

I wouldnt have a strong expectation about which choices would be made in 1+2, i would expect that i'm going to have to see what it does and change it if it does what i dont want.  This means i would expect to be able to go in and see the macro "script" it recorded and be able to change the script to do a or b as i wish.

Ok now having said that, here are the default decisions i would make: I would expect the macro to play back my basic keyboard interactions.  So 1->B and 2->B.  But in case 3 i would go A, because it would never occur to be to use bold button on a bold text to unbold it, and because there is no menu command to "force bold".  Again this is a case where having a script would be the ONLY way to offer a user choices to (toggle bold, force unbold, force bold).

One last repeated suggestion: if i were making a macro tool like this i would focus first on a text-based scripting system, and then add on a wizard macro-recorded that created a script.  Then it's not so critical that the macro recorder be perfect, as the user will always be able to manually edit and tweak the script.

[tranglos]

Thanks, mouser. The reason I'm asking is because I'm trying to find the "least astonishing" behavior, and in this case it's not obvious to me. There is of course a story behind the question. I have a fairly complex command execution engine for KeyNote. It has a UI builder on one side, which lets you tear down the default menus and toolbars, all of them, and create your own from scratch. (Allowing only one menu to be customized makes little sense, because the mechanism required to run it is exactly the same as the mechanism that allows you unlimited customization.) Another part of the scheme is a macro engine, which records and replays commands and, yes, persists them as scripts that you can easily edit.

Basically, commands have required and optional parameters. The optional parameters fill in default values, while required params must be given explicitly. So for example, a File|Open command looks like this in a menu configuration file:
<menuitem command="fileOpen" />

When this is triggered, the engine finds that the required "filename" argument is missing, and finds a handler for the command that gets the filename (e.g. by putting up a dialog box). The command also has an optional "readOnly" parameter, which defaults to false. What this lets you do is add a menu item like this:
<menuitem command="fileOpen" fileName="c:\somefile.txt" readOnly="true"/>

In short, you can put a mini-macro right in the menu. This, I hope, would be useful for things like commonly used font styles, etc - instead of going through a dialog box every time, you can add a custom menuitem that defines all the style settings. When you do so, you can specify whatever parameters you need, and the engiine will either fill in missing optional params, or prompt you for the missing required ones.

But once you have this, you need to figure out how much information to store when recording a macro the "normal" way, for replaying. For each command I can either store just the command itself (which would require user action on replaying, if the command has any required parameters), or I can store some/all of the actual parameters used for the command.

I agree with you about seeing what it does and tweaking the scripts manually, but most people won't go as far. For them, I need to provide the most useful behavior out of the box.

On edit: And you will be able to have a three-way toggle <bold/> by itself would toggle, and then there's <bold on="true"/> and <bold on="false"/> to force it either way. I'm sinplifying the syntax here, but just to give the idea.

marek