|
|
|
|
|
We have a couple of choices
regarding the Process layout.
One is the Model Style. This is
a toggle between Enhanced and
Basic.
The second is not a setting but
a default for the line style of
new lines. System-drawn lines
ignore this, but that may be
fixed later.
|
|
|
This is the default ‘Basic’ Model
style. Analysts will typically
use this as it is less cluttered.
This is also the style we are
used to.
Notice that the Action icons are
now larger, which is a welcome
reversion.
|
|
|
This is the ‘Enhanced’ style.
The differences are that you
have ‘quick-launch’ icons to
jump to the Visual Scripts for
Actions and Stages, and shapes
for Stages.
|
|
|
This replaces the need to
select the Stage and then
select the Visual Script (see
forthcoming section) from the
properties box.
|
|
|
The shapes for Stages can be
selected from the Design menu,
or from the Context menu.
These Stages do not represent
anything apart from the graphic.
We feel that as the ‘Enhanced’
style is really for Developers,
and the ‘Basic’ style is more
suited to Analysts, the
inclusion of shapes in the
‘Basic’ style would be far more
appropriate. Analysts will care
about visual aspects, not code,
and Developers will care about
Code not visual aspects.
|
|
We also cannot see the ‘Enhanced’ style being employed for
documentation as it is too ‘busy’. Thus the shapes become
useless in our view. Pretty, perhaps, but useless as they are.
What it really needs is the shapes to be used in the ‘Basic’
model, but allow ‘None’ to be selected as well (in case you don’t
like them). It is a good differentiator of Stages from Actions.
|
|
|
This is the Rectangle shape,
|
|
|
The Rounded Rectangle shape,
|
|
|
The Parallelogram shape,
|
|
|
The Ellipse shape
|
|
|
And finally the Diamond shape.
|
|
One puzzling omission is the lack of Shape selection from the
Context menu. You can select a Line style from the Context menu
for Actions (see below), but not a Shape style from the Context
menu for Stages.
|
|
|
|
|
Lines also have a Style. We
use the Curved style at all
times for a number of reasons.
Mostly because it is the only
one that is unambiguous in all
eventualities. The others may
not be, as we shall see.
|
|
|
The Line style may be selected
from the Context menu or
Design menu. You can apply
the same style to multiple lines
by multi-selecting them and
selecting a style from the
Context menu …
|
|
|
or from the Design menu.
|
|
|
Here the Direct style is used.
|
|
|
This is the Rounded style,
|
|
|
And the Straight Style
|
|
|
One nice feature of the
Rounded and Square styles is
that the lines ‘jump’ over each
other when crossing. To the left
is an extreme scenario.
|
|
|
|
|
|
Although these new line styles are attractive, in all but the
Curved style (what we used to have) we get significant problems
that will force us not to use them, unfortunately.
|
|
|
Imagine the scenario to the
left. Not an uncommon one, we
feel.
|
|
|
If the Straight style is selected
for all these lines, look what
happens.
One action has completely
overshadowed the other, not
even leaving an indication it is
there. The Principle of Least
Astonishment™ is thus violated.
|
|
|
We feel that the Rounded and
Straight styles suffer from
serious flaws too.
Take the fairly basic map to the
left.
|
|
|
When we change this to the
rounded Line style, it becomes
impossible to tell in which
direction many of the Actions
are set. This will definitely be a
potential source of confusion,
and we would not suggest
using them.
|
|
|
The same is true of the
Straight Line style.
A nice idea, but it will not work
as is, I’m afraid. Back to bendy
lines!
|
|
|
Although we feel the Direct
style is flawed for general use,
it does have one very nice
ability. Starting with the layout
on the left, we decide we want
to move things around.
|
|
|
First we change the line styles
to Direct.
|
|
|
Then we move the Stages
around, before changing the
line style back to Curved. Note
that we never moved any of the
Actions ourselves.
I think you can see that we
have avoided the need from
previous versions to move all
the Actions around to align
correctly with the new Stage
layout, which is a big
improvement.
|
|
|
|
|
Roles, as well as being
employed in the same way as
they used to be, can be added
to the Process map as
‘Swimlanes’.
|
|
|
You just drag and drop a Role
onto the Process map,
|
|
|
And a Swimlane is created.
|
|
|
You can add as many as you
wish in this way.
|
|
|
The way Stages are assigned to
lanes is to drag them to the
lane.
|
|
|
We notice that moving on the
same lane works too.
|
|
|
This adds the Role to the to-do
list of the Stage.
|
|
|
Dragging to a lane adds the
Role that corresponds to that
lane,
|
|
|
and dragging off that lane
removes it.
|
|
|
Notice that when dragging a
Stage, the lane that will be
used if you drop the Stage is
highlighted while the others are
dimmed.
You can also change the icon of
the Swimlane, so you can
represent different roles with
suitable pictures, for example,
should you wish.
|
|
|
System and Linked Process
Stages do not change their To
do list but their Watch list
when being moved from lane to
lane. This makes sense for a
System Stage, although we are
a bit dubious about the Linked
Process Stage.
|
|
The most obvious problem we have found with the Swimlanes are
that dropping a new Stage onto a Swimlane does not select the
Role. In fact, the default To do list item of Originator is set,
meaning you have to deselect it.
If that was fixed it would make the Swimlanes much more usable,
but as it is you need to jump a few hoops to make it work as it
really should, at least not to violate the Principle of Least
Astonishment™, anyway.
|
|
|
|
|
|
1. Designer User Interface
