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!

The low fidelity non-feature in Lucid Spec

I'm a big fan of the book Paper Prototyping by Carolyn Snyder. The book discusses how to create low fidelity (crude black and white) paper prototypes and then use the prototypes to get useful user feedback to better understand requirements and general usability. Joel of Joel On Software has said similar things about creating low fidelity functional specifications to flesh out design and usability issues. The basic idea is that low fidelity prototypes help users focus on how something is supposed to work rather than on whether something is pretty. You may have been in design meetings where users become focused on the color of a widget instead of whether that widget provides the necessary functionality. I know I have.

Therefore, I assumed that many users of Lucid Spec would request a low fidelity option to automatically morph all screens into a simple black and white style. I assumed wrong. In fact, not one user has requested this feature. I'm not really sure why this is. Are low fidelity prototypes something that you should do, but don't? Do people that create low fidelity prototypes only use paper? It remains a mystery to me.

Creating Lucid Spec documents for existing applications

I spent several hours using Lucid Spec to explore possible enhancements to an existing application, and I'd like to describe some of the issues I encountered and how I approached them.

The application's user interface is similar to Outlook and other apps. There's a menu bar and tool bars across the top, a tree-like menu down the left side, and the remainder of the window contains a panel or a set of panels. The application performs complex, multi-step mappings, and I wanted to explore ways to help users visualize the steps and their contents. I didn't need to reproduce the entire application in Lucid Spec, but I did need to be able to simulate many of the key panels. I considered several approaches.

First, I could focus only on the parts of the app directly related to my goal of visualizing steps, and simply ignore everything else. This "low res" approach is a bit like paper prototyping. However, some of the people who would be looking at the spec might be confused by the visual differences - my quick low res mockup wouldn't look much like their familiar application.

Second, I could try to replicate large parts of the app in Lucid Spec, so that my mockup would look more like the actual application. Given the number of menu and toolbar items, and the complexity of many of the panels in the application, this would be difficult and time consuming, even if I didn't try to match all of the colors, styles, and fonts. This approach might make more sense if we were planning a complete GUI redesign, but it seemed like overkill for my more limited goals.

As usual, truth and beauty lie somewhere between the two extremes. I wanted something visually similar to the original app, but which would allow me to focus my time and attention on a few key pieces. This led to a third approach, which worked pretty well. I captured screenshots of the app (with SnagIt), imported them into LucidSpec, positioned transparent rectangles over the widgets that I needed to link to other screens in the short term, and then added new screens and widgets for new functionality. No problem!

Actually, it did take some work. All of my screenshots shared a menu bar and tool bars, and many also shared the menu on the left side of the screen. So first, I used SnagIt to remove the content panel from a screenshot (leaving the window frame, menu bar, and tool bars), and used that as the background image for a master screen in Lucid Spec. Second, I trimmed a screenshot so that it contained only the left menu, and inserted it as an image in a second master screen, based on the first. I then trimmed the other screenshots to show only the relevant panels, and inserted each as an image in a new screen, based on one of the first two master screens. Once I had all of the screens I needed, I went back to the master screens and added transparent rectangle widgets over the key controls, and linked them to the appropriate screens. I could now simulate the original flow between screens & panels! Using this as a basis, I started experimenting with other ways of presenting the steps and their contents.

I found myself wanting a callout or postit note widget that I could use to annotate the original screenshots.
One more thing for the future feature list for Lucid Spec, I suppose.

In the future, we might try to make this sort of project easier to accomplish in Lucid Spec. If this is something you need or would really like to see, or if you want to suggest possible approaches, please let us know!