Make statement properties available/viewable

[kd-ods]

This is a feature request which would really help when supporting people's use of BODS. When helping countries like Latvia and Armenia, who are working towards publishing their BO declarations in BODS json, being able to view (and interact with - e.g. copy text) statement properties would be really helpful.

Suggested functionality:

• Click on a node or edge to reveal a popup with key properties* shown.
• The active/clicked node or edge is highlighted.
• Pop-up is closed only by clicking close (X) icon in popup, or by clicking on another edge or node. (Only one popup can be visible at a time.
• Users can select (and copy) text within a pop-up.

Alternatively, rather than a popup, there could be a 'Details' display area.

* Key properties TBD for each statement type, but ideally these would be easy to configure/change in the back-end.

[kd-ods]

@Lathrisk - When you've got 15mins could you take a look at this and let me know how long it would take to put a feature like this in place?

[openownership-bot]

My main concern with this is that people might have their own tooltip solution in place already (either hand-rolled or using some other library). We need to be flexible enough to allow that as well as providing a working default for the simpler case.

I’m not quite sure how best to do that, but off the top of my head it might be that we could just attach the underlying statement data to the DOM nodes we end up creating. e.g. in a data attribute. Then any lib can bind clicks and read direct from the data attr what it wants to display in the tooltip? Alternatively we provide an api where a caller can give us something taken from the DOM (a statement id perhaps?) and get the BODS data back.

The latter might be preferable as I’m not sure there’s always a 1-1 mapping between “thing you can click on” in the DOM and BODS statement. Better to sprinkle ids everywhere than duplicate the data. Perhaps though there’s a hierarchy of nodes we can take advantage of, putting all the info on a parent node?

I would recommend we use tippy.js for the default implementation, based on experience with it on the register

Steve Day Technical Lead

Based in: Devon, UK [email protected] openownership.org https://www.openownership.org/ | @openownership https://twitter.com/openownership Over 90 countries have committed to beneficial ownership transparency. https://openownership.org

[kd-ods]

Thanks, @stevenday.

My main concern with this is that people might have their own tooltip solution in place already (either hand-rolled or using some other library). We need to be flexible enough to allow that as well as providing a working default for the simpler case.

Yeah - that occurred to me too. Thanks for the implementation thoughts.

The use case for us having something like this is to help analysts when picking through a declaration and trying to understand how the publisher has modelled things. And also - eg - picking out statementIDs to aid modelling work.

[Lathrisk]

I doubt this would be difficult to implement, the main questions would be around which information we want to surface and where. We could possibly implement some sort of toggle to turn off our tooltips and allow people to use their own. The Dagre-D3 documentation provides examples with tipsy.js but I suspect this would be easy enough to swap out for tippy.js if that preserves consistency.

I'd probably give it an optimistic estimate of a day or two, once we're sure what approach we want to take.

[kd-ods]

This ticket will be addressed in the upcoming sprint by:

• Reviewing and testing the currently not-displayed properties
• Selecting and designing how the properties will be displayed. Mock up to agree with @StephenAbbott first and then coding

[kd-ods]

On talking with @codemacabre this morning, we've minimally specced the following:

• a parameter can be passed by users to enable or disable property-viewing in the UI
• the tool will support (via the modelling 'layer') bundling and rendering of:
  • ALL properties per node and per edge (to be available via some element of the UI, e.g a disclosure widget or copy-to-clipboard button), AND
  • a small subset of these (to be rendered in a tooltip). (The tool cannot 'expect' these to exist. They are added to the subset where they exist.)
• Properties will be displayed in UI text as '[property name]: [property value]' pairs
• In the UI, properties text (whether in a tooltip or a disclosure widget) will be selectable (and therefore copiable).

First steps on this are:

• @kd-ods to define the tooltip properties subset for BODS 0.4
• @codemacabre to create a mockup to show how rendering might work.

[kd-ods]

@codemacabre, assuming that it will be easy enough to change the tooltip properties subset in the code, I think this is what we should go for as a first effort:

Subset

• statementDate (appears in all statements, i.e. for nodes and edges).
• recordId (appears in all statements, i.e. for nodes and edges).
• identifiers (both entity statements and person statements have an identifiers array. Not relationships.)
• interests (an array in relationship statements. If it's simple enough only to include a subset of subproperties, then: interest.type, interest.startDate)

[codemacabre]

A quick mock-up of how the tooltip / expandable disclosure widget might look:

I've just used some example data here, and I've blurred the visualisation to reduce it's visual importance in this mock-up. The actual visualisation won't be blurred when the tooltip opens!

[codemacabre]

WIP:

[codemacabre]

@kd-ods I had a few questions:

• Should the [property name]: [property value] pairs just be JSON (as in the WIP preview above)?
• Should there be two parameters to toggle property-viewing in the UI? One for property viewing in general and another for whether to use our tippy.js solution? (EDIT: I've already implemented this)
• Do we need a copy-to-clipboard button? This will involve a lot of extra JavaScript (or another library) which seems like overkill, especially if, like tooltips, the user has their own solution.

[kd-ods]

Should the [property name]: [property value] pairs just be JSON (as in the WIP preview above)?

In the disclosure widget, raw JSON is good. In the tooltip, imo it would be good for the text be more user-friendly. So, using property title, property name pairs eg:

Statement date:    2017-05-31
Record identifier: 22e8a31863ee
Identifier 1:      (GB-COH) 02585514

Do we need a copy-to-clipboard button? This will involve a lot of extra JavaScript (or another library) which seems like overkill, especially if, like tooltips, the user has their own solution.

No, I don't think we need this. Is the text selectable in the disclosure widget, @codemacabre ?

[codemacabre]

Is the text selectable in the disclosure widget

Yes, it's selectable in both the disclosure widget and the tooltip.

[kd-ods]

Great!