Archi 5.2 Tests & Review

[jbsarrodie]

@Phillipus After some issues with Eclipse and my Mac, I'm now able to test Archi 5.2. I've seen some issues and I have some remarks. Instead of opening multiple issues, I'm logging all my findings here.

Potential enhancements for Appearance tab two columns layout My Property view being on the bottom most of the time, I tend to use the two columns layout. In this mode, I think we should tweak a bit the order and position of some attributes to better group fill/outline related attributes:

1st column	2nd column
Fill Colour	Gradient
Fill Opacity
Line Colour	Line Width
Outline Opacity
Icon Colour
Text Alignment	Text Position
Font	Font Colour

Btw, I think we should make sure we use either the word 'Line' or 'Outline' but not both. I guess the name or the attribute should be the same for elements and relations, so I suggest renaming 'Outline Opacity' to 'Line Opacity'.

'Line Colour' and 'Line Width' issue when using icon notation There are two distinct issues:

• When using icon notation, some figures use only 'Line Colour' and not 'Fill Colour'. That's the case for Plateau, Work Package, Path and Communication Network. They should be tweaked so that 'Fill Colour' is used.
• Some figures only have an outline (e.g. Service, Event, Function, Process, Value...) and some have a more complex drawing involving internal lines (e.g. Collaboration, Role, Contract, Driver, Goal...). I think 'Line Colour' should only impact the outline, and not inner lines. This in turn raises the question of which colour should be used to draw these inner lines. I think the answer should be either a darker version of 'Fill Colour', or 'Icon Colour'.

Font scaling -Dcom.archimatetool.adjustFontSize=trueworks great !

Multi-selection editing of user properties Works great, except in some cases:

Case n°1

• Select several objects, some of which (or even all, doesn't matter) have a property 'X'
• Now add a new property with the same name 'X' and set its value to 'Something'
• The previous action is in fact split in two steps:
  • A new property 'X' is created on all objects
  • The value of previously existing properties 'X' are set to 'Something' and the new one is empty (if an object had multiple instances of 'X', only the first one is updated and set to 'Something')

I find this behavior misleading because it let the user think that a new 'X' property will be added on all objects with the new value 'Something', in addition to potential properties having the same name, while in fact it depends whether or not a property 'X' was previously existing on the objects:

• If an object hadn't the 'X' property, one is created with value 'Something'
• If an object had the 'X' property, its value is changed to 'Something' and a new, empty, 'X' property is added

Potential solution could be to:

• Implement the expected behavior (add a 'X' property with value 'Something' on all objects). This might be hard as it seems the property is added (empty) to objects when leaving the text field in the 'Name' column, and then its value is changed from empty to 'Something' when leaving the text field in the 'Value' column (ie. these two operations don't seem atomic).
• Reject the creation of the new 'X' property because it already exists on some objects. Might be the easiest.

Case n°2

• Select several objects. All share the same 'X' property with same or different values. One object has the 'X' property twice. Let's assume the first 'X' property is set to 'X1' and the second is set to 'X2'.
• Now, on the line showing 'X' | '(multiple values)', change the name of the property from 'X' to 'Y'
• On each objects, only the first instance of 'X' is renamed to 'Y', leading (on our sample object) to 'Y'='X1' and 'X'='X2'

Would it be possible to rename all 'X' property instances to 'Y' ?

Case n°3 This one is very similar to the previous one and maybe shares some root cause.

• Select several objects. All share the same 'X' property with same or different values. One object has the 'X' property twice. Let's assume the first 'X' property is set to 'X1' and the second is set to 'X2'.
• Now, on the line showing 'X' | '(multiple values)', change the value to 'X3'
• On each objects, only the first instance of 'X' is updated, leading (on our sample object) to 'X'='X3' and 'X'='X2'

Would it be possible to update all 'X' property instances to 'X3' ?

Filtering of relationships in viewpoint.xml Strictly speaking this was introduced in Archi 5.1, but I never tested it. I just did and it work great.

The only question I might have is whether or not we should force Grouping to be forced in all viewpoint? In several cases, we might not want users to create Groupings (which could "pollute" the model if created instead of Visual Groups), and only some of the viewpoints I use really require it. So maybe we shouldn't force it and explicitly add it to each viewpoints in the default viewpoints.xml (so that people don't notice)? This would allow people who manage their own set of viewpoints to have full control over it.

A similar improvement could be done for Junctions: asof now Junction is always shown, but because not all relationships can be use with Junctions, we might end up with a viewpoint in which Junction is shown but no relationship can be use with it. In addition, even though it is allowed, we might want to forbid it's use in some viewpoints (I forbid their use most of the time so that models are easier to "navigate" for scripts). So would it be possible to not force it but explicitly add it to each viewpoints in the default viewpoints.xml (so that people don't notice but advanced users can tune things up)?

~And I think I have now tested everything new I didn't tested before~

HTML Report I've found a small bug in the HTML Report which seems to have been introduced by Archi 5.0.x. When the report opens, on the bottom left we can read the text "Select an element in the model tree or in a view to show its details here". This text should be centered in both width and height. I guess I can easily manage this issue.

[Phillipus]

@jbsarrodie Thanks for the feedback!

Potential enhancements for Appearance tab two columns layout

The problem with this is that the Eclipse Properties API works like this:

1. It is split into horizontal Sections
2. A Section is visible according to a Filter (is this a connection, an object, does it support gradient? etc)
3. Where we have two controls (Font/Font Colour, Fill Opacity/Line Opacity) they are in the same section and so have the same Filter. An example of this is OpacitySection.
4. Normally, a Section would contain only one control, but I tried to be clever by combining two controls into one Section - but they have to have the same Filter

The problem is having two controls in the same Section that require a different Filter.

In the case of Fill Colour/Gradient not all objects have Gradient (Canvas notes) so therefore we can't group those controls together.

Also, if we make the Fill Opacity and Outline Opacity Sections separate this requires some major refactoring of the OpacitySection class as you can see it contains the two controls into one section. We would need to create two Sections.

Not sure what the answer to this is. Perhaps each control should be refactored into a separate Composite class that can be reconstituted/combined into a Section. The problem is that if a Control needs to be hidden because it's not appropriate for the selected object it has to be hidden.

TL;DR - it's complicated.

[Phillipus]

I suggest renaming 'Outline Opacity' to 'Line Opacity'.

An easy win. ;-)

[Phillipus]

When using icon notation, some figures use only 'Line Colour' and not 'Fill Colour'. That's the case for Plateau, Work Package, Path and Communication Network. They should be tweaked so that 'Fill Colour' is used.

But isn't the default colour for these icon figures black (or dark grey), which is really the line colour?

1. Create one of these figures. The default fill colour is pink, or green
2. Change the figure type to icon
3. The icon lines are now pink or green - not ideal!
4. So user has to change the fill colour to black
5. Now change the figure type to rectangle - the fill colour needs changing to pink, or green

If you like, you can experiment with these figures to see the outcome. You'd need to change graphics.setForegroundColor(getLineColor()) to graphics.setForegroundColor(getFillColor()) in the figure code.

[Phillipus]

Some figures only have an outline (e.g. Service, Event, Function, Process, Value...) and some have a more complex drawing involving internal lines (e.g. Collaboration, Role, Contract, Driver, Goal...). I think 'Line Colour' should only impact the outline, and not inner lines. This in turn raises the question of which colour should be used to draw these inner lines. I think the answer should be either a darker version of 'Fill Colour', or 'Icon Colour'.

Surely "line colour" is not "outline colour" but the colour of all lines used in the figure?

For some figures (Collaboration, Role, for example) there are no "inner lines". These figures use ovals/circles and so can only be one colour.

[jbsarrodie]

I suggest renaming 'Outline Opacity' to 'Line Opacity'.

An easy win. ;-)

Good.

Potential enhancements for Appearance tab two columns layout

TL;DR - it's complicated.

Ok, so keep it as it is or maybe (if possible) move gradient section after Fill Colour and opacity section before text and font related sections:

1st column	2nd column
Fill Colour
Gradient
Line Colour
Line Width
Icon Colour
Fill Opacity	Line Opacity
Text Alignment	Text Position
Font	Font Colour

[Phillipus]

Ok, so keep it as it is or maybe (if possible) move gradient section after Fill Colour and opacity section before text and font related sections:

I'm refactoring the controls into re-usable components that can be combined into Sections containing two or more controls.

The downside of re-arranging UI elements is having to redo all the Help documentation screenshots.

[Phillipus]

Potential enhancements for Appearance tab two columns layout My Property view being on the bottom most of the time, I tend to use the two columns layout. In this mode, I think we should tweak a bit the order and position of some attributes to better group fill/outline related attributes:

That's done now and committed to dev branch.

[jbsarrodie]

But isn't the default colour for these icon figures black (or dark grey), which is really the line colour?

Looking at the ArchiMate specification it seems so, but knowing how these icons have been designed, I can tell you that we (the ArchiMate Forum) didn't think about those subtleties ;-)

The icon lines are now pink or green - not ideal!

First, a disclaimer: I almost never use icon notation.

That being said, when I do, because I use a line color which is derived from fill color, the effect is that I do see them pink or green (well, at least my version of these colors which is not as bad as the default ones):

But using the fill color (and not a darker version of it) would be even better IMHO. Here's a comparison of spec vs derived vs fill, with deliverable and technology event for reference:

If you like, you can experiment with these figures to see the outcome.

That's my plan. Note that if I'm not able to do it in a short amount of time, this should not be a blocking point for the 5.2 release.

Surely "line colour" is not "outline colour" but the colour of all lines used in the figure?

Well, I really tend to see it as "outline" because that's how it is perceived most of the time (because most of the time people use the box notation). Also, being able to set some transparency only make sense for outline (thus the attribute named "Outline Opacity"), not really for internal lines inside an icon notation.

For some figures (Collaboration, Role, for example) there are no "inner lines". These figures use ovals/circles and so can only be one colour.

That's just how they are drawn today, but I could quite easily change that ;-)

If I find enough time to test, my plan would be to have an "Outline Path" that could be use to change the colour and width of the outline without impacting internal lines, but also in the futur to better compute anchor points (I've seen a very generic and clever algorithm for computing intersection of a line and a path).

Another related topic is ability to distinguish internal lines on dark fill colour: on the one hand, if the fill color is dark, we usually want a darker colour for the outline, but for a good contrast we need a lighter colour for the internal lines (on the right is a "simulation" with one icon on top of another one):

So... I have to do some experiments ;-)

[Phillipus]

So... I have to do some experiments ;-)

That's a lot of work and potential changes. Perhaps for Archi 5.3?

[jbsarrodie]

Potential enhancements for Appearance tab two columns layout My Property view being on the bottom most of the time, I tend to use the two columns layout. In this mode, I think we should tweak a bit the order and position of some attributes to better group fill/outline related attributes:

That's done now and committed to dev branch.

And now tested: PERFECT !

[Phillipus]

5.2 is released now.