Consider options to reduce multiple appearances of entities in implementation plan view

ashbowe commented 7 years ago

Hi Timo,

I think we have had this conversation before so please forgive me if we already arrived at a conclusion:

In the implementation plan view clusters can appear multiple times under different human rights issue headings when the actions and recommendations contained within it cover multiple issues. Ideally it should only appear under one heading. Is this possible and if so could it be the human rights issue it is most associated with (ie has the most connections with?)

Thanks

tmfrnz commented 6 years ago

I do not think we had discussed this aspect of the double grouping feature before but am more than happy to do so. Curious to see if and how this can be achieved sensibly.

tmfrnz commented 6 years ago

Generally we would advise against excluding actions from groups they belong to (even if only implicitly by inheritance/connection) as this would be inconsistent, intransparent and thus likely confusing for the user.

Instead we would suggest to consider options that otherwise reduce multiple appearances in different groups that may happen either when actions are explicitly tagged with multiple categories (here thematic clusters) or when actions are implicitly tagged with multiple categories (here HR issues), inherited from recommendations they are connected with. The problem is that as recommendations are often rather broad and belong to many issues, grouping actions by (connected) issue can lead to many duplicate listings of actions with issues, including many unrelated issues.

Therefore we suggest to consider the following options:

Explicitly tag actions with issues, ideally facilitated by a mechanism that offers to take over only a subset of issues from recommendations they are connected with (the same mechanism could also be applied to thematic clusters and other taxonomies). Grouping (and possibly also filtering) by connected category would then no longer be required (and simplify the logic for the public user).
Allow excluding issues inherited by connected recommendations
If grouping by thematic cluster is sufficient, not allow grouping actions by connected categories (HR issues)

ashbowe commented 6 years ago

Thanks Timo. I don't quite follow the first option you have mentioned there. I get the idea of tagging actions with issues but then get lost! What sort of mechanism are you referring to?

Would another possible solution be (and I think this is a combo of the options you have put forward)

For actions to only appear under the one thematic cluster they have been tagged with in the implementation plan view.
For clusters to be assigned a human rights issue, allowing them to still be grouped first by HR issue and then by cluster?

Totally understand the points you have made in your prose above and this is really just for making the implementation plan view neat and tidy, but quite an important feature.

tmfrnz commented 6 years ago

Thanks Timo. I don't quite follow the first option you have mentioned there. I get the idea of tagging actions with issues but then get lost! What sort of mechanism are you referring to?

The mechanism for the first option would have to be developed, but basically what it should do is facilitate to selectively apply issues to an action based on the issues applied to the recommendation an action is connected with.

Currently actions implicitly inherit all issues from its connected recommendations, possibly leading to many inherited issues often relevant only to the connected (often more generic) recommendation but not so relevant to the (often more specific) action, and ultimately leading to multiple listings under different issue groups.

So rather than having actions implicitly inherit all issues from their connected recommendations, the first option (let's call it "opt-in") suggests not to inherit all connected issues, but only those explicitly selected (from the issues applied to the connected recommendations).

The second option (let's call it "opt-out") suggests to inherit all connected issues by default (as per current behaviour) but would allow to explicitly exclude issues from the connected issues.

Would another possible solution be (and I think this is a combo of the options you have put forward)

For actions to only appear under the one thematic cluster they have been tagged with in the implementation plan view.

This should be the case (although in the current version a bug allows grouping both by thematic clusters directly applied to actions and by thematic clusters applied to connected recommendations https://github.com/impactoss/impactoss-client/issues/327 - will be fixed with next release later this week)

For clusters to be assigned a human rights issue, allowing them to still be grouped first by HR issue and then by cluster?

Clusters would effectively become sub-categories of issues, thus introducing sub-categorisation. While worth considering and useful also beyond this example (eg Cycles could become sub-categories of HR bodies), its implementation would require significant effort. Happy to discuss!

tmfrnz commented 6 years ago

To reduce duplication, we suggest the following measures that can be set up immediately and without additional effort

[x] limit grouping options to direct categories (for actions these currently are "Thematic clusters" and "Organisation" (see https://github.com/impactoss/impactoss-client/commit/41f416fba9159177b60aa2924c272e4398d57b67)
[x] primary default grouping for actions will be thematic clusters without any secondary default grouping (changed server configuration 29/9/2017)

To explore actions by issues (inherited from related recommendations), the user will have to filter the action list by issue. Main drawback is that cluster groups are not ordered in any sensible manner (alphabetically) so that neighbouring clusters are likely unrelated and related clusters are far apart

tmfrnz commented 6 years ago

In the meantime we will consider the following options for future enhancements:

Sub-categorisation: connect thematic clusters with issues, thus effectively introducing sub-categorisation (this would also be useful for Human Rights Body and Cycle taxonomies)
Explicit inheritance: no longer implicitly and automatically inherit issues via connected recommendations but instead consider mechanisms to facilitate explicit and manual inheritance (or transfer) of issues (this would also facilitate assigning thematic clusters to actions). Will provide mockups/wireframes to visualise such a mechanism shortly

nmrf / sadata

Consider options to reduce multiple appearances of entities in implementation plan view #9