Low tech simulation logic in Lucid Spec

In Lucid Spec, we're often trying to balance power and ease of use. Actually, it's less a matter of "either ... or" and more a matter of "both ... and" - we want novice users to be productive quickly, and we want experienced users to be productive in larger and more complex projects. We try to keep this in mind as we evaluate potential new features (thanks for your suggestions - please keep them coming!).

A good example is the issue of enhancing simulation capabilities. In the first release of Lucid Spec, most widgets (buttons, text fields, etc) have a "jump to" property - if the value of this property is a screen name, then Lucid Spec will jump to that screen when the widget is activated during simulation. A user can type the screen name, or select it from a menu. For example, a login screen typically has two text fields and a button or two - you enter a username and password, click on a button, and go on to the next screen in the application. Not surprisingly, we get requests and suggestions for more power and flexibility.

Some ideas involve saving user-supplied data on one screen so it can be reused later in the simulation. So if I enter "kussmaul" as my username on the login screen, I should be able to see "kussmaul" on other screens in the simulation. Would this be nice? Absolutely. Could we implement it in an easy-to-use-but-powerful fashion? Probably - although this is the sort of feature that can lead to more and more related features, until suddenly we've reinvented Visual Basic. Is it essential for GUI prototyping? I'm not so sure - it might encourage users to spend more time than they should early in the project.

Others present a bigger concern - suppose that data values I enter on one screen affect which screen I will see next? For example, the login screen might lead to different screens for different categories of users.
This sort of situation is pretty common, and there are several ways we might accomplish it:

1. Make multiple copies of the source screen (perhaps all based on a single master screen), each going to a different destination screen. This might be OK with a login screen for each category of users, but it gets more complicated quickly, and I try to avoid duplication.
2. Add widgets to the screen that won't be part of the final application, but can be used to select the appropriate destination. For example, the login screen could have buttons labeled "login as guest", "login as admin", "login as user", or an extra menu with these options. This approach could work on simple screens (especially if we use different colors or fonts to suggest that the extra widgets are someone different), but could interfere with the layout of crowded or more complex screens.
3. Use what I've been calling a "helper screen". When a user clicks on the login button, they see a screen with a menu or set of buttons that lets them choose the next screen in the simulation. I usually make helper screens with different background colors or fonts to emphasize that they won't be in the final application. In this approach, the simulated screens don't have to change, and we can support much more complex interactions with minimal duplication.
   

We could also extend the existing "jump to" capability in Lucid Spec to include some sort of selection logic that can use widget data values to determine the next screen. Once again, the slippery slope towards Visual Basic. Furthermore, we're trying to fix defects and make other enhancements, so we might not get to this right away.

If you have other ideas, or more reasons why we should enhance simulation logic sooner rather than later, please let us know!