Blogs about Jazz

Blogs > Jazz Team Blog >

Building Views with IBM Engineering Lifecycle Optimization – Engineering Insights (ENI) Part Three – Customizing the Look and Feel of Views (The Basics)

<< Building Views with IBM Engineering Lifecycle Optimization – Engineering Insights (ENI) Part Two – Building a Traceability View

In the previous article we built out a simple traceability view – as a reminder here is where we ended up:

While functional it isn’t particularly appealing visually. In this article, we will apply some formatting to improve its consumability.

Formatting Resources

It’s probably worth mentioning straight away that formatting for Artifacts differs slightly from formatting for Custom Artifact Elements. In this article, we’ll focus solely on Artifacts (which we used to create the traceability view in the previous article).


The formatting of resources displayed on the view is done primarily through Nodes. We can open the Node definition for any type of Artifact by right-clicking (any) resource displayed inside an Artifact Container and then selecting Edit Node:

Note that editing the Node for a particular Artifact (e.g. Story) affects all containers of that type on this view.

UI Types

Nodes are based on UI Types that define the basic display characteristics of an element such as its shape (for example it’s a rectangle that is 160 wide and 30 high), its content (for example it has one line of text), its colors and so on.

These characteristics (parameters) have default values which may then be overridden by the Node that uses them. In the screenshot above you can see that the Story Node is based on the simpleResourceNode UI Type – which is a rectangle with a single line of text. By default, the rectangle is 160 wide and 30 high, and the single line of text is populated by the title property of the underlying resource when it appears on the view.

If we select a different UI Type – for example the baseResourceNode UI Type; this one is slightly different in that it has two lines of text, populated by the shortTitle and title properties respectively:

Note that the preview at the top-right displays the current value setting of the parameter, not the name. Rather confusingly, for example, the UI Type has a parameter called title, which by default uses the shortTitle property of the resource. It also has a parameter called summary, which uses the title property of the underlying resource. Don’t worry too much about this – just change the values in the table and then look at the preview for the effect. For example, if we modify the title row to use the id property instead of the shortTitle:

Then the view updates so that Stories display their ID as well as their title:

Another simple change we can make to improve the look and feel is to change the fill color of a Node:

Fill colors may be solid, gradients, or patterns and it doesn’t take very long to create a more pleasant looking view. Don’t overdo this of course and you will find that lighter colors work better than darker ones.


Conditional Properties

Any value defined in a Node may be set statically (for example width=30 and fill color=yellow) or conditionally. This is particularly useful for applying properties like coloring, for example, the Test Result container could color its display based on the verdict (passed, failed and so on) of the underlying test result:

Want to change the width of the displayed artifacts on a diagram so you can read them? Change the width property in the Node definition. Resizing a container will do just that (resize the container) not the displayed elements inside it.

Note that UI Types may be customized and new ones added – but this is beyond the scope of this article.

Line Styles

Aside from the elements in the containers, the other thing we may want to customize on our view is the connections. Note that in edit mode, there is a dashed line between containers. This line only appears in edit mode and is there to allow you to customize the display of the actual OSLC connections between the resources:

Right-clicking the dashed line will give the following options:

  • Show Connections: This is a toggle to show/hide the actual OSLC links (between the resources in these containers) on the view. It is sometimes useful to hide these links – for example, if you have a DOORS Next module, with a linked container showing the requirements used by that module, the links are not only superfluous but make the view unnecessarily busy, so we can simply hide them.
  • Show Linked Nodes Only: When we create a container using Show Links To, we are doing two things: (a) Adding a container of elements (for example Requirements) and then (b) filtering that container by only showing ones that have incoming links from elements in the previous container. Show Linked Nodes Only is the second part of this equation. Disabling it will remove the filter and instead show ‘all’ elements (of course any other filters on the container would still be applied)
  • Edit Connection: This is where we can edit the look and feel of the OSLC links between these containers, and the dialog is similar to the one for Nodes:

The most useful setting is the UI Type combo box:

  • baseConnection = rectilinear
  • roundConnection = spline
  • lineConnection = straight line

Also very useful are the startDir and endDir properties (although these are set to ‘auto’ – this is unfortunately far from automatic and it is much better to select either “Left or Right” or “Top or Bottom”:

There is no capability (at least at the time of writing) to annotate a connection (perhaps with the type of relationship it represents). Although one can imagine if there are many OSLC links such annotations would quickly cause the view to become unreadable, still the option would be nice. Here is what our sample view looks like after applying a few of the properties described above.

That’s all for now; in the next article, we’ll see how to make this view dynamic so that consumers of the view can easily select a Story with a single click and instantly see the traceability view change.

Building Views with IBM Engineering Lifecycle Optimization – Engineering Insights (ENI) Part Four – Building Dynamic Views >>

Andy Lapping
Technical Enablement Specialist
Watson IoT & Engineering Lifecycle Management