Story Board

[gps57]

Is anyone using EA to create story boards for their designs.  I'm starting a new project and I'd like to try story boarding it.  I am new to EA and UML, and I'm not sure how to approach story boarding.

Any comments?

[TrtnJohn]

What do you mean by "storyboard"?  I am not sure you are talking about UML any more.

You can describe your functional requirements using Use Cases and Use Case Scenarios.  But, the actually user interface is not shown.  Storyboards and UI can be prototyped with some of the UI elements of EA.  But this is still very primitive.  I like to make a seperate document showing screenshots of prototype UI and link them to Use Cases myself.

(Don't know if that was helpful or not?)

[Kevin Brennan]

"Storyboarding" usually means to show which UI elements are used to move through a particular scenario. If this is what's meant, then the Custom diagram has all the elements you'll need.

However, to do it properly, you'll have to be careful about either hiding the visibility of connections or using only instances of the screens. I suggest the latter as it'll be easier to manage.

[Hans]

Hi Kevin,

in UML 2.0 you would do that by use cases, although I'm pretty sure that it's not what you'd expect to be.
It's simply that Booch et al have come to the decision that a story board shall become superfluous..

Cheers,
Detlef

[Kevin Brennan]

Hans,

UML doesn't really handle UI design properly. I suppose in RUP you could do a sequence diagram with the boundary classes but the end result is meaningless to business users without a lot of education.

Sure I could teach them how, but I prefer to show them something that they'll naturally understand. Actual screens do that job a lot better. (Also, you may have multiple boundary classes per screen).

Either way, you often need to do multiple storyboards by use case. Scenarios (defined in this case as a particular unique path through a use case) give you a better estimate of how many storyboards/sequence diagrams you need.

[TrtnJohn]

A way to tie it into your use cases is to make UI dialogs a supporting actor in the Use Case.  In the Use Case diagram they are shown on the right side and using the square box notation.  In a seperate glossary document I contain a screenshot and/or description of the UI element.  And in each scenario they are noted by name wherever applicable.

[sargasso]

Similarly, in the case of this web app, I am using activity diagrams to storyboard the flow between pages.  But we place the following constraints on the modelling:
1. All diagramming  is done strictly from the user view of the flow.
2. An activity element defines something the user does, the server side does not partake in an activity, the "system" only partakes on the browser side and then only in the textural description of the activity (for example local scripts that valid an Age textbox as being numeric and between 0 and 120 years).
3. A control flow link represents either a manually induced page transition (i.e. the user clicks text, a button or a link image that results in a http request to the server) or an automatic transition that reflects a server side validation that returns the same page albeit with an error highlighted or something similar.
4. We have found it necessary to stereotype the activities html target attirbute, for example to delineate popups and child windows from the "main" browser window.
5. (TIP) Synch elements are used as placeholders where target activities are yet to be defined.

This has allowed us to build flow diagrams for the logical scenarios required for all the user actions in a use case and then to "combine" them to generate a mapping of all the links needed from and to a page.  We do this by creating a digram with a single activity from the "pool" and then using the add related elements.

In short,  storyboarding is a technique, different UML and EA notations can be employed effectively with the technique to explore or solve different analysi and design issues.

Bruce