What is the best way to model a richly interactive GUI (using use-cases or other approaches)?

My company develops a rich GUI from a detailed specification document, written as 100+ Use-cases (UC's). These detailed UC's drive the development. They are written as tables with actor and description columns. We (me and others) have mangled real UC prose style to support the interactive nature of our application.

We also use the specification to generate (manually) a test spec, so the detail (to me) seems important. This test-spec is used in verification to get sign-off.

Note: There are many more components to our product than just the GUI. The GUI team is 6-10 strong, the project as a whole, about 60.

Until recently I used to create a "storyboard" document detailing each panel and its interactions in relation to the specification. There also used to be a GUI architecture, plus designs for major sub-components. Ouch! It has led to very slow development times, a poor code base (ha!) and a poorly motivated team.

The app is more of an IDE, allowing users to create their own tes开发者_C百科t-cases (for mobile 'phone testing) using a drag'n'drop, flowchart idiom. It is very complex, mature (7+ years) and offers many functions. The test-cases are then run and the results analysed. Being such a free tool (user can follow a nearly infinite number of paths through the tool), it seems to make a nonsense of sequential use-cases. We use "O" to mean optional, "R" to mean repeatable, nesting and many other "extensions". UC's are fundamentally a poor match for designing an IDE's interactions. Think of this app as offering a blank worksurface (like a word-processor, or spreadsheet), where users can do anything, in any order: this has led to the UC bloat.

Currently there is a desire to simplify the specification from 100+ UC's into fundamental UC's: "Develop Test-case", "Run Test-case", "Analyse Results" (or something similar).

Whilst I understand our UC's are not "true" UC's (focussing on the business value), my concern, as team lead on the GUI and also developer is that without the detailed information, my guys won't know quite what to develop. Three UC's just seem too abstract.

We follow a form of Unified Process, with spec done up-front. Perhaps we should change to a more agile process, with developers themselves doing the interaction design.

Some kind of drag'n drop based IDE/GUI-tool would have been nice? With capabilities to record the interactions, and put descriptive text on animations. Instead of UC's design IDE you let IDE do UC's. With the IDE/GUI in a specific state you can let a pop-up show what happens by write UC or some text on that pop-up, comming up every time that specific state is conditioned by the user or developer. The pop-up can be connected to more pop-ups depending on what happens in the real world. Like those text adventures asking "what do you want to do now?". And a UC pop-up kan trigg events to change the IDE/GUI or change other states according to test-suites made from the specifications.

A test-suite map inputs to outputs. Interactions with the IDE/GUI select inputs and the outputs changes the state of a prototype of the data-layer of the program. Theoretically you can do all functions with in/out-tables (some infinetly large) instead of algorithms. Practically when a table is big enough, let one programmer use it as a test-suite to do an algorithm and exchange the table. The table now used as a test-suite reporting errors.

Let the IDE/GUI-tool generate the code for the final event driven IDE/GUI interacting by events with code, data and user layers, or better you let it be reflective with all in one layer, to get rid of endless restructurings.

That was just some idéas

In OpenLaszlo recomend a four steps design process: 1.Wire-frames. 2.Storyboards. 3.Animations. 4.Engineering prototypes.

It's very interesting...