Screen Flow Documentation

[JohnDoe]

Hi folks,

I just stumbled upon this excellent diagram:
http://wireframes.linowski.ca/2012/09/large-canvas-flows-with-references/

Any idea how to achieve this with EA tools ?

Greetings
John

[qwerty]

I guess by using Visio or OmniGraffle (like the author). I have no idea what this diagram got to do with UML.

q.

[JohnDoe]

If you create software, you should have a link back to requirements and USeCases. These features are supported by EA. But IMHO there should also be a visual screen action model in EA, which is the foundation for technical UseCases, StateMachines, ActivityDiagrams and all the other stuff. The visual interface is, what your customers will see. They won't see stateMachines or objectCommunication, unless it is shown in the interface. Most discussions in User Acceptance Tests are raised, because customers do have a different perspective than developers (developers fulfilled a technical requirement, but users have a different opinion of how to show or use it in the user interface).

Why EA ?
In EA today there is already a wireframe toolbox, which is a good starting point. Therefore the EA guys have supported us with toolboxes describing UI as part of our software projects.

IMHO the screen action model is THE essential tool for user tests, acceptance tests and the expected user experience.  If you document usecases and technical requirements in EA, you must collect the expected screen action und user experience model as well in EA. The user perspective is THE perspective when your system is tested in UserAcceptanceTest. This is what your audience will feel and see and this is what they expect - a visual experience and a set of hidden functionality. UI based screen action models should be part of the Software Requirements Specification and the foundation of all UI based test cases.

My question here is, how to create an understandable screen action model and how to document it in EA.  Are you guys using Visio or OmniGraffle or EA anyone ?

Greetings
John

[qwerty]

EA is not a drawing tool (though creating UML diagrams needs basically some drawing features). The fact that EA does not offer all those drawing features as e.g. Visio has its good and its bad (not going to discuss this here). What you can do is  to use shape script and alternate images. Sometimes the simplest is the best (Occam). You can create graphics in Visio and use those in EA as alternate images.

q.

[JohnDoe]

Qwerty, I dont want EA to paint like Visio. That is not the point here.

My approach is to use the EA wireframe toolbox. It is there in EA and I want to use it. My question is how other users make us of the wireframe toolbox and create comparable inter-screen-flows with the given EA toolboxes.

An export could look like the picture shown above in this post, but could differ since EA has a different approach. There is a big difference to Visio: EA can reuse elements and link them back to other elements, what makes the huge difference.

Anyone using wireframe models to construct the user experience ?

[Eve]

There's no built-in profile for specifying user interface behavior.

What I see on that diagram would be relatively simple to accomplish with a few shape scripts.

[Guillaume]

Hi John,

With previous "User Interface" models as well as Wireframes, I've used the navigate association between screens, or from a UI element such as a button to another screen.
The advantage of EA is that you can show the empty screen with a link to a diagram that provides more details, or show everything onto a single diagram.

Here is an example:



I can however see this being improved e.g. to what's illustrated from your link. If that can be easily achieved via Shapescripts, such enhancements are welcome for a future build.  

[JohnDoe]

Thanks Guillaume,

thanks for backing this.

I have to document a huge web application with 200+ Web Screens, which collaborate extremely behind the scenes (many unclear features and undocumented UseCase paths as well as hidden functions).

Therefore I need to create a visual click&jump model, which shows the paths across the many web pages. This will also be  a foundation for the testing team, which needs an overview of all UseCases (where do they start, where do they end, pre/post conditions, performance requirements etc.).

It would be great if there were more modeling features to visualize UseCasePaths across Screens (UseCase starting points, end points etc.).

ShapeScripts and MDG would be an idea, but there is barely good documentation about this stuff and every user would have to install and keep it updated.

IMHO Enterprise Architect should offer some ScreenFlow standard toolbox OOTB (UseCase start, UseCase steps and UseCase ending points which show a UseCase along a line across Screens). Also there should be more  integration between ScreenDesign and UseCase specification editor.

Greetings
John

[qwerty]

I guess you mix up use case actions with user interface design. They are related, but it's not that you can/should map a use case directly to a UI design. If you shortcut that you loose the ability to optimize use cases from the"use" perspective since you focus on graphics. Sure you have extra work but I think it will always pay off.

q.

[jfzouain]

Ho John

I understand your frustration and that is why I wrote my eBook:
UML - ERP Workshop
https://leanpub.com/uml-erpworkshop

It tells you how to design and document you application in EA, this particular volume 1, out of several that I will be writing in the future it tells you how to slice and divide your Business Requirement Document (BRD), telling you the flow of the screens, Use cases, Activity Diagrams.

I like to use Business Rules in my BRD, which gets translated into Classes, Sequence, Data Model and so on when the TDD (Technical Design Document) is written. So they go hand in hand, describing what you want.

Hope this helps you.

[JohnDoe]

just check this product of one EA competitor and see how they collect and structure requirements and screens

http://www.visual-paradigm.com/features/uexceler-supports/

this tool is excellent for cutting down requirements and screens, but it lacks the EA features for code generation and reverse engineering, so I would  recommend to enhance EA in the area of requirement and business documentation

my hope was that EA already offers some of their nice feature list

[skiwi]

As far as improving EA diagramming is concerned there are some interesting posts on the forum, see for example
Ability to change Sparx direction
diagramming or modelling
or not