Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enhance perspectives to allow style customizations beyond descriptions #36

Open
Midnighter opened this issue Oct 29, 2023 · 6 comments
Open
Labels
enhancement New feature or request

Comments

@Midnighter
Copy link

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 😃

@Midnighter Midnighter added the enhancement New feature or request label Oct 29, 2023
@simonbrowndotje
Copy link
Contributor

simonbrowndotje commented Nov 4, 2023

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
Copy link
Author

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
Copy link
Contributor

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
Copy link
Author

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
Copy link

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
Copy link

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants