Enhance perspectives to allow style customizations beyond descriptions

[Midnighter]

Description

As discussed on Slack, it would be wonderful to allow style customization in perspectives. Unlike the DSL you previewed there, it would be more natural to me to use tags that are defined on the elements, because the perspective value is intended for descriptions, the [value==bla bla bla] syntax could get awkward.

So instead of what you proposed:

model {
  softwareSystem "A" {
    perspectives {
      "Technical Debt" "1"
    }
  }

views {
  styles {
    element "Perspective:Technical Debt[value==1]" {
      background green
      color white
  }
}

I propose using tags, maybe like this:

model {
  softwareSystem "A" {
    tags "High"
    perspectives {
      "Technical Debt" "The tech debt of the A system."
    }
  }

views {
  styles {
    element "Perspective:Technical Debt:High" {
      background green
      color white
  }
}

I can see this being very useful in visualizing many different things like security, privacy, organizational units, and more.

Priority

Medium

Resolution

I'm willing to pay for this feature (add details below)

More information

I cannot promise payment, but let's discuss on Slack. If you give me a quote I can certainly discuss with my manager. I've just introduced Structurizr and there are many happy people around. So the timing is good 😃

[simonbrowndotje]

So my plan with this is to add a value property to perspectives, which can then be used in those element style expressions ... admittedly that's currently not the case with the POC, and the description is used instead.

Feel free to use the donation link if you'd like to support the project financially.

[Midnighter]

Admittedly, I am biased by my current workflow, but I thought about it some more and to me there are two good reasons for using tags:

1. Tags are familiar, whereas a value property introduces completely new syntax.
2. Tags can be flexibly (and programmatically) added to elements.

To illustrate point 2: I currently parse system information from ServiceNow. It is straight forward at that point to add further tags to a system based on properties in ServiceNow, such as GDPR, Decommissioned, Organizational Unit responsible. I then define the views in the workspace manually.

I could easily define perspectives styling them based on those tags. Defining the values in the perspectives either forces me to do this manually (meaning I will probably miss updates to the data being done on ServiceNow), or force me to define the views automatically, which I'd rather avoid since it excludes contributors who can't code but can handle the DSL.

[simonbrowndotje]

Perspectives can also programmatically be added to elements via the addPerspective method -> https://github.com/structurizr/java/blob/master/structurizr-core/src/com/structurizr/model/ModelItem.java#L196 (this would be enhanced to also allow a value property.

The problem with tags is that they can ambiguous when combined with perspectives. To add to your example:

model {
  softwareSystem "A" {
    tags "Low"
    tags "High"
    perspectives {
      "Technical Debt" "High - The tech debt of the A system."
      "Cost" "Low - The cost of the A system."
    }
  }

  softwareSystem "B" {
    tags "Low"
    tags "High"
    perspectives {
      "Technical Debt" "Low - The tech debt of the B system."
      "Cost" "High - The cost of the B system."
    }
  }
}

views {
  styles {
    element "Perspective:Technical Debt:High" {
      background green
      color white
    }
  }
}

[Midnighter]

I see your point. Probably in this scenario the tags should be named "Tech Debt Low" and "Cost High", so that the auto-generated legend also makes sense for viewers. Otherwise they'd ask, "what is high?", "what is low?"

I concur that pre-generating the perspectives on systems but not the views would probably be the best way to go in my use-case.

Thank you!

[asos-alexwhite]

For what it is worth, I don't like the idea of using the tags on the element in this way. As Simon describes, the ambiguity across different perspectives in the same diagram (say security alongside tech-debt) then that 'high' tag is unlikely to apply properly to both of them.

So I much prefer the option of adding values to a perspective which allows me to vary the styles I show per perspective more easily and in a more structured form.

I wonder if there might be a slightly nicer syntax to use in the style, but I don't have any ideas on that right now I'm afraid.

[lschricke-hw]

Hello Simon!

Thanks for this very nice tool, I love it!
I'm having the same need as asos-alexwhite in this comment: I would like to style the relationship the same way we can with elements for perspectives.

Do you plan on adding this feature too by any chance?

(I'm adding this request here since you mentionned it in this comment)

Thanks!