[Feature Request] Please consider additional support for the former alternative Archi interface representation

[rojoweko]

Hi,

please consider readding support for the former alternative Archi interface representation, because they offered an elegant and scalable way of visualizing interfaces in diagrams. The round, colored shape made them identifiable as interfaces at an instant and a (usually) directly to the shape connected composition relationship practically provided the line segment for the alternative interface notation specified in the ArchiMate standard. Therefore I used this notation in most of my diagrams. They potentially have to be readjusted to look proper again with the new representation.

Would it for instance be an option to add the oldstyle representation as an additional alternative shape or to introduce a preference setting that substitutes the old alternative shape for the new one?

Thanks in advance! ;-)

[Phillipus]

The old Interface figure was just a circle, and an oval shape when the figure was resized to a rectangle. That was a legacy thing on my part which was just wrong. The new Interface figure matches that in the 3.1 spec:

https://pubs.opengroup.org/architecture/archimate31-doc/apdxa.html#_Toc10045477

I'm not going to change it back, or have a special case of 3 possible figures. However, we plan to provide a set of alternate shapes for all concepts so this will be possible then.

[jbsarrodie]

@Phillipus in fact I agree that the old one was better. I should have told you before but was focused on specialization and forgot to come back to new figures.

Re interface, the alternative notation is not an icon but only a ball. The connection is a tricky part because it is not part of the interface but an alternative notation for the composition (which then looks like an association). So the previous alternate figure (ball) was the best compromise until we also tune composition for this special case.

I might also have some adjustments or remarks on other figure. We should sort this out quickly so for 4.9.1.

I'll have a look this week-end.

[rojoweko]

Thanks for dealing with this! ;-)

@jbsarrodie: Opinion regarding the tuning of the composition relationship: To my mind a modification of the composition relation in combination with an interface is not favourable for the following reasons:

• A modified composition relationship could easily be confused at first glance with an association relationship (which I often use for instance to provide additional information about the interface or to clarify what data will be transmitted via the interface, etc...).
• It could cause user confusion, because many users probably do not know about this special notation of the composition relationship in this particular case (I actually have not known about this as well).
• The target side of the composition relationship does not have an arrowhead, so there is no need for an modification at this end, because it looks the same as an association relationship.

[jbsarrodie]

@jbsarrodie: Opinion regarding the tuning of the composition relationship: To my mind a modification of the composition relation in combination with an interface is not favourable for the following reasons:

I understand your points, but ArchiMate specification made this clear until 2.1:

A business interface may be part of a business role through a composition relationship, which is not shown in the standard notation[...] (see here) An application interface may be part of an application component through composition (not shown in the standard notation)[...] (see here

In both excepts, "standard notation" refers to icon notation (which was borrowed from UML)

@Phillipus here is my global feedback on new icon figures and some enhancements proposal. I can certainly manage to code them quickly, but before doing so I'd like us to agree.

We have two types of icons:

• Some can easily be stretched and thus can behave like a box (e.g. Application Component, Process, Role...). I'll calll this the "Box behavior"
• Some are real icon and shouldn't be stretched at all (e.g. Material, Interaction...). I'll call this the "Icon behavior".

Issues:

• Collaboration fits in no category while it should use the "Icon behavior"
• Principle uses the "Box behavior" while it should be the "Icon behavior"

If we focus on the "Icon behavior":

• While when the text is (centered) on top or bottom the icon stays on the opposite side while touching the border of the figure, when the text is on the (middle) left or right, the icon is on the opposite side but without being fully pushed to the border. This is anoying.
• There seems to be some magic to define the exact icon size. But this "magic" takes the size of the text into account, which means that if the text changes, the icon size will change. I think this is an issue because there's no way to make sure the view will stay the same after renaming some concepts and this will also makes it difficult to have multiple icons of the same size on a view. I think the size of the icon should be defined only based on the size of the figure.

To fix these two issues, I would suggest two possible behavior:

• Either have all icons of the exact same size that we define arbitrarily (that's already what we do for the small icons for the classical "box" notation. I would suggest three or four times the size of these small icons. - Or use this one (assuming icons are contained inside a square box, which is not always the case and should require some math adjustment):
  • If text is centered (i.e the icon is centered too): use the maximum available space without stretching the icon, i.e. icon size of Min(figure.width, figure.height).
  • If text is vertically on the middle but horizontally on the left or right (i.e. the icon is pushed to the far right or left), make the icon the size of Min(figure.width, figure.height).
  • If text is on top or bottom (i.e. icon is pushed to the far bottom or top), make the icon the size of Min(figure.width/2, figure.height). This ensure the icon is always visible but not too wide so that the text is a bit wider.

Now, re "Interface": The issue I see is that some people already use the alternate figure, so we should try to limit the impact for those users. And as said, there's a misunderstanding on what the real icon is (because for Interface, Networks and Path, the specification in fact describes an alternative notation embedding the relationships, and not a real icon notation). So I think a good compromise would be to not draw the small line in the icon and keep only the ball:

• With text centered (which is the default) this would really look like the original implementation (but would always be a circle, fixing the original flaw). In most cases I've seen, users keep the figure as a square with text centered, so this should look exactly the same.
• With text in another position, with the adjusted behavior described before, the ball would always touch at least one border, making it possible to have a continuity with the relationship comming from an active structure element.

[Phillipus]

@Phillipus here is my global feedback on new icon figures and some enhancements proposal. I can certainly manage to code them quickly, but before doing so I'd like us to agree.

After having spent months of my life tweaking these figure and making them look half decent, plus the nightmare of last year working around line thickness and other issues, I really don't care any more.

[jbsarrodie]

I've just added a new icon-figures branch containing adjustments for my previous suggestions.

• If text is on top or bottom (i.e. icon is pushed to the far bottom or top), make the icon the size of Min(figure.width/2, figure.height). This ensure the icon is always visible but not too wide so that the text is a bit wider.

After some experiment I don't find it nice or useful to use figure.width/2, simply using figure.width (or figure.height if smaller) seems better.

Here's an example of what icon figures looked like before for each cases (all text position, portrait and landscape):

And how it looks now:

Icon size is no more influenced by text size, and resizing the figure is enough to have the text outside the drawn icon.

Here's what Interface looks like with my proposed patch:

And how it (IMHO) solves original issue while still be better than what we had in 4.8:

[Phillipus]

@jbsarrodie Yes, I get what you've done there and this certainly provides more options for the user.

The Collaboration, Interaction, Gap, Material, and Course of Action figures are smaller, though.

Compare before and after (text is middle, centred):

Before:

After:

[Phillipus]

There is an AbstractTextControlContainerFigure#getTextControlMarginHeight() method which some of the iconic figures over-ride and return a value of 0 in order to give more space for the figure when the text is at the top or bottom. But with this new way of drawing figures this is no longer needed and if we don't over-ride it, it keeps the margin consistent between alternate and main figures.

[jbsarrodie]

The Collaboration, Interaction, Gap, Material, and Course of Action figures are smaller, though.

Yes, this is because in my code I tried to limit changes so that we can discuss them if needed.

I can easily fix this by changing the signature of AbstractTextControlContainerFigure#setFigurePositionFromTextPosition(rect) method so that it takes another argument iconRatio (could be optional and in that case 1would be used). This will make it possible for the figure to make sure the returned rect better fits the icon.

That being said, I have the feeling that some icon are a bit unbalanced anyway and I might also adress this.

[Phillipus]

@jbsarrodie Do what you think is necessary. The aim is to make the figures as good looking as possible.

BTW - the idea of having text above and below the icon figures came from Nicolas Figay:

https://www.linkedin.com/posts/nfigay_archi-version-49-is-progressing-well-in-activity-6829809625982926848-4f8f

[Phillipus]

(rect.width / 2) - (diameter / 4)

becomes

(rect.width - diameter) / 2

See, I knew there was a real mathematician around here somewhere. 😉

[Phillipus]

@jbsarrodie Did you get any further with tweaking the figures? Shall I release 4.9.1 with existing changes or wait a little longer?

[jbsarrodie]

I had to switch to another topic but will finalize today. So please wait a bit more.

[jbsarrodie]

I had to switch to another topic but will finalize today. So please wait a bit more.

Now done. Can you please see what it looks like with your test model (mine seems fine) ?

BTW, I also fixed a regression to be sure that custom image (if any) would fit the whole figure instead of only the icon portion.

[Phillipus]

Thanks for that.

BTW, I also fixed a regression to be sure that custom image (if any) would fit the whole figure instead of only the icon portion.

I'm not sure if this affects SVG export to image.

Rectangle imageBounds = rect.getCopy();

// Set line width here so that the whole figure is constrained, otherwise SVG graphics will have overspill
setLineWidth(graphics, 1, rect);

Here. rect is changed by setLineWidth so imageBounds won't have the offset that setLineWidth adds. Not sure if this affects SVG or anything else? I can't see any difference. but just point this out...

[jbsarrodie]

Not sure if this affects SVG or anything else?

Not sure too. And if it does affect SVG, that should be only with custom images. So I suggest to keep it like that, publish 4.9.1 and wait for more feedback from users.

[Phillipus]

I'm happy to do that. I'll release 4.9.1 tomorrow. Any tweaks can be done in 4.9.2 if necessary.

I'll merge your branch if OK with you.

[jbsarrodie]

I'll merge your branch if OK with you.

Ok ;-)

[Phillipus]

Just a note for the record...

When I was tweaking the figures the use cases to test the figures are:

With:

• Windows 100% and 200% device scale
• Linux 100% and 200% device scale
• Mac 100% and 200% device scale

Test:

• SVG Export
• PNG Export
• Zoom in at 100%, 200%, 300% and 400% in diagrams
• Line thickness set to 1, 2, 3 (currently not implemented but could be one day)

I found that it's hard to get the right balance. What might look OK in one case might be off by 1 pixel in another.

Having said that we do a bloody good job of it compared to Mod..., er, another Eclipse based modelling tool... ;-)

[jbsarrodie]

• Line thickness set to 1, 2, 3 (currently not implemented but could be one day)

I have plenty of use cases for this, but we should also revisit border color at the same time though (be able to set 'auto' darker color or 'custom' color on a per visual object basis).

[Phillipus]

• Line thickness set to 1, 2, 3 (currently not implemented but could be one day)

I have plenty of use cases for this, but we should also revisit border color at the same time though (be able to set 'auto' darker color or 'custom' color on a per visual object basis).

I don't think that would be too difficult. I'll take a look at that.

[Phillipus]

Archi 4.9.1 is available with these changes.

[rojoweko]

Thank you very much for the changes regarding the icon representation of ArchiMate elements in the new release! That makes the diagrams look much nicer! ;-)

Just one other question regarding this topic:

Is it possible to have the connections terminate at the visible (inner, not necessarily rectangular) boundary of the icon instead of the invisible (outer) boundary with the resizing handles? The termination at the invisible boundary potentially leads to a visual gap between the end of the connection and the element symbol, which is a little bit unfortunate (especially with the non-square default size boundaries of the icons, that cause a quite large gap when connections terminate on the left or right side of the icon). This seems to apply to all icon representations as well as many other non-rectangular shapes.

[jbsarrodie]

Is it possible to have the connections terminate at the visible (inner, not necessarily rectangular) boundary of the icon instead of the invisible (outer) boundary with the resizing handles?

Because of the way connections work, that's not possible.

But with the new icon figures, you can change the icon position by changing the text position (if text is on the right, icon will be on the left and so on). And because icons will (almost) always touch the border, this means that you should be able to find an icon position that makes it appear connected without any gap.

That's how I did this (elements are selected to visualise their "bounding box"):

[rojoweko]

OK, thanks for the quick response! ;-)