Stop Diagram Filters being user specific and...

[Graham_Moir]

... global

From information from RoyC in a separate thread it has come to light that diagram filters only apply to the current user, i.e. if another user opens the model and looks at a diagram where you have a filter applied, they won't see it.  

Together with the fact that the filters are global - i.e. once you've set a filter it applies to all diagrams you look at, it seems to me that the  functionality defined for diagram filters is fatally flawed.  

I would definitely like to:
- apply a filter and have a diagram with the filter applied visible to other users.
Also, I'd like to:
- create a diagram and populate it,
- then clone it multiple times and highlight different specific parts of it on each clone using different filters
- have the HTML output reflect the set of diagrams and applied filters

In my view, this would be a very useful communication and education mechanism.

Link to other threads on this topic
     http://www.sparxsystems.com/cgi-bin/yabb/YaBB.cgi?num=1403607477

[Eve]

Seems to me that both of the things that you are trying to achieve have always been possible by building the diagrams to express the points that you want.

Diagram Filters on the other hand were designed for the situation where you want one complete diagram and then without modifying the diagram  dynamically highlight different parts of it. Prior to their introduction the only way to do this was to build multiple static diagrams showing a subset. (Which sounds like what you are now trying to do using filters)

[RoyC]

EDIT: Yeah - Simon got in first!

Well, on the other hand, the Diagram Filters are also called Dynamic Filters, and are designed to help you quickly (and temporarily) observe changes, trends, special aspects and alternatives in your model. You open a 'standard' diagram and apply a filter or several filters, and see what the diagram looks like when only the aspects you want are highlighted.

I don't see the point of applying a dynamic facility outside the boundaries of a user ID. If the filter were to be applied across the model, it would be very annoying if you were looking at a diagram and someone else's filtering hid parts of it. Even more annoying if you are filtering for something for another user to see, and someone else then applies another filter.

Perhaps a more practical answer is, if you want to 'fix' a diagram to only show one aspect for the longer term and for other users to see, copy the diagram and edit it to reflect that aspect. Perhaps use the filtering to indicate which model elements to remove to get the effect you want. Diagrams are, after all, abstract reflections of how you see elements interacting under whatever conditions you impose, and you can quickly create any number of diagrams to 'permanently' show what happens as you change those conditions.

[Graham_Moir]

Thanks for the feedback guys.  I agree that dynamic filters could be useful in the way described but their use is limited if it's restricted to the current user only.  I would also maintain that being able to clone a diagram multiple times, apply different filters to each clone AND have the filters persist, i.e. be static basically would help productivity and communication.   This is because:
- the whole context of the original diagram is maintained in each clone, but different aspects are emphasized
- I wouldn't have to spend time rebuilding each additional diagram, either by removing unwanted elements or building a new diagram from scratch with the elements I want to emphasize.   Basically, yes it's "always been possible by building the diagrams to express the points that you want."  but I would like to save time from needing to do that.

[qwerty]

It would be nice if a diagram filter would be sort of a diagram clone. So it would appear in the browser like a diagram (maybe adorned with some icon) and one could set its filters individually.

q.

[Uffe]

I'll throw my hat in this ring and say that I would not like to see qwerty's suggestion of filters in the browser implemented - I don't even like seeing the current semi-diagrams in there (diagram frames etc). But perhaps a new type of Model View, a "Diagram View" which contains a diagram and a filter?

Returning to the OP, I agree insofar as I think the ability to reuse filters between users would be useful. The key point is productivity.

In mid-to-large teams, typically only a few individuals get into the guts of EA and only these enthusiasts tend to even know about diagram filters (all dependent, of course, on how enthusiastic the team is in general). But filters do provide a useful function, and there are situations where using filters is preferable to creating (and maintaining!) multiple diagrams with minute differences -- indeed, that's the reasoning behind having filters in the first place.

In such teams, distributing filters between users would be a productivity-enhancer (yes I do speak managerese, but I'm not a native). The obvious place to put them in order to achieve this would be an MDG Technology.

So, cruelly disregarding all other aspects of the OP, I would very much like to see the MDG Technology Wizard augmented with the ability to include diagram filters.

Cheers,


/Uffe

[Eve]

Uffe, I think you missed the point of what is being requested. You can already share diagram filters between users. What is being requested is to be able to apply the filter to a diagram and have all users see it. The specific use case given was duplicating diagrams and applying a different set of filters to each copy.

[skiwi]

I, for one, do see the point of applying a dynamic facility outside the bounds of a UserId,
and of having the filter setting sticky (i.e. preserved over closing diagram or closing EA), and being set per diagram.
I do like the idea of having the filter being able to be applied to a diagram frame (or diagram view).

[RoyC]

A diagram filter stays on until you specifically turn it off, so in that respect it is already 'sticky'. I suspect that many users would find having the filters specific to a diagram would be as tedious as what you perceive to be the current restrictions - they would not want to have to keep turning the filters on (or, subsequently, having to turn them off) for each diagram they looked at.

So, Andrew, Brian and Chris are working on the same team. Andrew develops a diagram filter that hides all elements other than Class, turns it on, and tells Brian to look at diagram xx on his own workstation. Andrew and Brian are content analyzing that diagram, but because the filters apply, as per your request, across all users, Chris now finds his review of diagram xx is disrupted. He is upset, until he realizes that a diagram filter must be applied, so he goes and turns it off. Andrew and Brian now find that diagram xx shows a number of other elements that obscure the effect they were trying to examine.

What do you guys propose that serves your purposes but does not interfere with other people's work on the model?

Simon didn't directly say so, but he gave you a solution: Andrew sends Brian the filter he has developed, and tells him to turn it on and look at diagram xx. If they wish, they can leave the filter on on their respective systems and look at other diagrams, or turn the filter off after they have reviewed the diagram. They could put a note on the diagram reminding them to use the filter. Chris continues to work on his own stuff entirely unaffected by the activities of Andrew and Brian.

[skiwi]

OK, trying to lift this up a level.

here's what I know:

In EA 1107 (and all previous version I can remember), when I apply a filter to a diagram - greying out some aspect. CLose EA, then re-open it again, the filter is no longer applied to the diagram (no greyed out elements). To me this is not 'sticky'.

Filters don't work the way I "expect" them to.
This means to me that there is more than one use case for them, and these may be conflicting - as evinced by this thread.
This also means that Sparx have developed to one paradigm, perhaps trying to 'guess' what is best for us Sparx users.
I'd suggest this is a fraught approach.

There may be a way around this though, and that is to provide more configurability to filters, to let them meet several differing use cases.

To me a filter should be a global resource, available to, and shared by all model users.

A filter is applied to a specific diagram, by the user who has the diagram locked for editing. That filtered view of the diagram sticks with the diagram, every time it is opened (and over EA closing and opening) until another user locks the diagram and changes the filter application.

However I see no reason why a filter cannot be applied to a locked diagram that is being viewed, but the filter setting is not saved with the diagram when the diagram is closed.

So for example filters could be provided with a setting that configures for use in different scopes.

[RoyC]

Yes, you are right. The filter does not survive EA being closed. Still mulling over the rest of your discourse.

[Graham_Moir]

"There may be a way around this though, and that is to provide more configurability to filters, to let them meet several differing use cases."

I agree with Skiwi that this would be the best way to go.

[AndyJ]

Hmm...

I worry about the direction of this conversation.

In another system, with a shared repository (shared by all ICT personnel) I've had work corrupted, through inappropriate re-use and modification of entities...

I'm not sure that I could cope with diagrams changing display behaviour because another user is applying filters to understand some aspect of the system being developed.

I can image revert wars taking place in those circumstances.

 

[qwerty]

I guess that the "global resource" skiwi mentioned is not meant as a global filter.

q.

[skiwi]

I guess that the "global resource" skiwi mentioned is not meant as a global filter.

q.

Correct, I was envisaging a diagram filter as being globally available for use by any model user, but applied to individual diagrams,
or perhaps (subject to deciding on how configuration or options might work for a specific filter) applicable globally, or to all diagrams in a package, or all diagrams in a package and all its descendants, for example.

I'm not sure, but it could also be that diagram filters could be applied (override) as part of documentation generation.

See also
diagram filters
 context filters