Color Views in Archi

Started by tgfranck, June 06, 2017, 10:06:11 AM

Previous topic - Next topic

tgfranck

Hi everyone,

I've been using Archi for a while and recently felt the need to add some more expressiveness to my views. Having used Bizzdesign Enterprise Studio before, I decided to try and write a plug-in to apply some colors. I've attached some examples of my initial efforts below.

Currently the plug-in does the following:

  • Gather input from the user via a wizard
  • Compare the contents of two views
  • Codify the contents of a single view based the value of a given property (three colors, numeric values only)
  • Apply colors to the view(s)
  • Add a very basic legend
  • Reset the colors and remove the legend
Before I continue working on more complex functions, I would love to hear your opinions. Do you see added value in coloring views? Do you know of anyone who has tried developing something similar? I searched the forums and found nothing. I would also love to hear any suggestions you might have for improvements!

All the best,

Thijs

Phil Beauvoir

#1
Hi Thijs,

welcome to the Archi forum and thank-you for sharing your plug-in idea. It's an interesting idea and certainly one that could be used for presenting views in a different way. Can you elaborate on what information is gathered from the user in the first stage?

(BTW - these forums do tend to be a bit quiet, so don't be surprised if there are only a couple of responses)

Phil
If you value and use Archi, please consider making a donation!
Ask your ArchiMate related questions to the ArchiMate Community's Discussion Board.

steen.jensen@sll.se

I think this feature should be valuble. Some sort of "filter-view" there you can select witch attribute to select color on, i.e a "status" attribute that is used for more than just coloring...
Normal View, and a copy view where you filter on attribute as show/hide or set a color on value

tgfranck

Hi all,

Thank you both for the encouraging remarks! Attached is an example that shows in more detail the process of adding colors to a view. Phil, this should also show you what information is currently gathered from the user. Steen, I think our approach is somewhat aligned, but I would love to hear your thoughts.

I am currently still busy improving the coloring functionality. Particularly, I would like to not simply use the default colors to reset views, but actually retain custom colors a user may have applied too. For example, if a user colored a particular business process green (instead of the default yellow), I want that business process to show up green again after the colors have been reset.

Do you have any suggestions on how to approach this? I am thinking of using the preferences mechanism to store the values temporarily, restoring the original colors before a model is saved or the application is closed. Let me know what you think!

Best regards,
Thijs

tgfranck

Hi all,

I solved the problem of retaining user-applied colors and added some more functionality too.

Firstly, I added the option to compare plateaus. The user selects two plateaus, as well as a view on which to apply colors. Concepts are then color coded based on whether they are in the one, the other, or both plateaus. I feel like this is particularly useful when working on e.g. an impact analysis. What do you think?

Secondly, I added a function to automatically reset views to their original colors before the model is saved. I believe the colors should be a temporary 'layer' over the original views. Archimate relies on colors to easily distinguish between concepts of different layers, and the use of user-applied colors outside of color views should still be an option. Moreover, color views can be easily re-applied.

However, the implementation of my solution feels like a bit of a hack. I would have liked to override the behavior of the save function (as defined by the com.archimatetool.editor.actions.SaveAction class), but was could not figure out how to do this without changing original code. Instead, I have my plugin register a property change listener with the Model Manager. This listener triggers whenever a 'model saved event' is fired. I then simply reset the views to their original colors and save the model again. Does anyone have a suggestion for a cleaner way to approach this?

Looking forward to hearing your thoughts.

Best regards,
Thijs

Phil Beauvoir

Quote from: tgfranck on June 12, 2017, 08:12:27 AM
Instead, I have my plugin register a property change listener with the Model Manager. This listener triggers whenever a 'model saved event' is fired. I then simply reset the views to their original colors and save the model again. Does anyone have a suggestion for a cleaner way to approach this?

The listener approach is correct, but not sure that double saving is a good idea. Perhaps you're coming at it from the wrong way. Have you published your code?
If you value and use Archi, please consider making a donation!
Ask your ArchiMate related questions to the ArchiMate Community's Discussion Board.

tgfranck

#6
Hi Phil,

I cannot share all the code with you yet. However below is the code that registers the listener. The save operation fires another event, so the applied variable is there to prevent the listener from becoming stuck in an infinite loop. Applied always becomes true again (eventually).


public class StartPlugin implements IStartup {

@Override
public void earlyStartup() {
IEditorModelManager.INSTANCE.addPropertyChangeListener(new PropertyChangeListener(){

boolean applied = true;

@Override
public void propertyChange(PropertyChangeEvent propertychangeevent) {
applied = !applied;
if(!applied && propertychangeevent.getPropertyName().equals(IEditorModelManager.PROPERTY_MODEL_SAVED)){
IArchimateModel model = (IArchimateModel) propertychangeevent.getNewValue();
try {
ColorView.resetModelViews(model);
IEditorModelManager.INSTANCE.saveModel(model);
} catch (IOException e) {
e.printStackTrace();
}
}
}

});

}

}


Phil Beauvoir

I mean the general approach and workflow. Whether it could be achieved by some other means.
If you value and use Archi, please consider making a donation!
Ask your ArchiMate related questions to the ArchiMate Community's Discussion Board.

tgfranck

I'm sorry, I misunderstood your question.

At the essence, the workflow is about codifying concepts (in a view) using colors. I chose to do so by changing the fill colors of the view components. That seemed like a very straight forward way to achieve my goal.

However, since I do not want to persist the color views, I need some way to return the views to their original state before saving them. If I do nothing, the altered colors will be stored along with the model. So long as the editor is not closed, it would still be possible to restore the original colors by resetting the colors and saving the model again. If the editor is closed without resetting and saving, the original colors would be lost.

Option 1: Find a way to reset the views before saving. This is what I have attempted. However, I could only find a trigger after saving. This is why I decided to go with the current approach.

Option 2: Find a way to color the views that does not affect the model. If the state of the model is not affected, the problems with saving the model could be avoided. I have not seen a way how I could do this, but maybe you have some suggestions?

wombach

Hi,

the basic idea behind the concept of color views as we use them is that it allows us to do some basic analytics on the models: explicate differences and commonalities between views, plateaus etc. The colors are used by the modeller to highlight certain aspects of his/her model. We do not want to overwrite these model specific settings permanently, but for the purpose of an analysis want to change the colors to highlight certain aspects. To avoid that we are "accidentally" overwrite the user color settings, we are looking for a smart way to make sure that we switch off the color view and reset the original colors of concepts and relations before saving the file again.

br
Andreas

Phil Beauvoir

OK, I have a better understanding.

It seems really that you need another way of looking at the view. Something akin to "Apply Color Filter"? This means that your Option 2 is the preferred approach.

I'm not clear about this - are you generating another View altogether with the new colors? Or changing the View in question?

Phil
If you value and use Archi, please consider making a donation!
Ask your ArchiMate related questions to the ArchiMate Community's Discussion Board.

wombach

Hi,

we are changing the colors in an existing view and are not changing anything in the view besides the color.
We do not want to create new views for every coloring. The colors are just temporary as a result of an analysis and will not be persisted.

Do you have an idea on how to add an additional data structure to maintain the analysis colors per view for all views in an elegant way? We are still learning on how to use/extend the data structures in the Archi tool.

Thanks in advance.

best regards
Andreas

Phil Beauvoir

If you change the colors in the model code then, yes, you have all sorts of problems. What you need is additional presentation code that applies the colors to the View. Unfortunately, Archi doesn't have this kind of extension point so I think anything is going to be a hack. Even if you did store the colors in the <metadata> tags of an IArchimateModel class you still need to hack the code to show the colors. Other than presenting it in a new type of diagram View I can't think of another way to do it elegantly.
If you value and use Archi, please consider making a donation!
Ask your ArchiMate related questions to the ArchiMate Community's Discussion Board.

tgfranck

Hi Phil,

Thank you for the feedback. As Andreas has mentioned, we would prefer not to create new views/duplicate existing ones. Your suggestion of applying some sort of filter sounds interesting and I think it is worth looking into. The closest thing to a 'filter' I have seen in Archi is the way in which viewpoints are handled. The color (or transparency?) of the view components that are outside of the viewpoint change and the borders are dashed rather than solid.

To figure out whether and how I could tie into this, I would like to understand how viewpoints are applied to views. I have found the viewpoint definitions, the function that fires an event whenever a viewpoint is changed for a view, and the function that filters which view components belong to a particular viewpoint. I have not yet found the function that applies the gray tint/transparency and dashed borders to view components that are outside of the viewpont. Could you maybe point me in the right direction?

Thijs

Phil Beauvoir

Hi Thijs,

if you do this then you'll have to hack the core Archi code, and your plugin will no longer be standalone.

com.archimatetool.editor.diagram.editparts.AbstractArchimateElementEditPart:

    protected void refreshFigure() {
        // Set Enabled according to current Viewpoint
        if(Preferences.STORE.getBoolean(IPreferenceConstants.VIEWPOINTS_GHOST_DIAGRAM_ELEMENTS)) {
            getFigure().setEnabled(ViewpointManager.INSTANCE.isAllowedDiagramModelComponent(getModel()));
        }
        else {
            getFigure().setEnabled(true);
        }

        getFigure().refreshVisuals();
    }
If you value and use Archi, please consider making a donation!
Ask your ArchiMate related questions to the ArchiMate Community's Discussion Board.