Stream: IG creation
Topic: Slice rendering
Alexander Henket (May 07 2019 at 16:34):
The rendering of slicing feels uneasy. The pseudo element that defines the slicing could be skipped and the definition could just go onto the real element. For comparison of what I mean please see the way Simplifier renders those e.g. here https://simplifier.net/nictizstu3-zib2017/zib-bloodpressure
Eric Haas (May 07 2019 at 17:20):
(deleted)
Eric Haas (May 07 2019 at 17:24):
@Alexander Henket i see the pseudo element in simplfier too. the one with min-max = 1..*
Eric Haas (May 07 2019 at 17:24):
what are you referring to in the ig build?
Alexander Henket (May 07 2019 at 17:56):
Schermafbeelding-2019-05-07-om-13.54.40.png
Alexander Henket (May 07 2019 at 17:58):
On the left hand side Simplifier, right is build.fhir.org which is the same as the IG Publisher. Note how the right hand side has an extra green cylinder thing and how the slicename is named in Simplifier while in IG Publisher this is a mouseover. Lastly I like the folding option (collapse/expand)
Alexander Henket (May 07 2019 at 18:02):
https://simplifier.net/coreprofilesstu3/bp
http://build.fhir.org/bp.html
In case you wanted to check it out yourself
Grahame Grieve (May 07 2019 at 18:04):
we don't do collapse/expand because it's a standard and our advice is that ANSI would have a problem with standards with hidden text
Grahame Grieve (May 07 2019 at 18:05):
but that's a minor point. How does simplifier display the slicing rules?
Grahame Grieve (May 07 2019 at 18:05):
oh - it makes the slicing the owner - YUCK
Grahame Grieve (May 07 2019 at 18:06):
the definition could just go onto the real element
That's not what Simplifier actually does
Eric Haas (May 07 2019 at 18:09):
as I understand it : can't hide this content due to ANSI rules for HL7 guides so no collapsing on the tree view
the 0..* is missing in the ig pub and I think that is important.
I don't care about the icon, but I think the slicename is a nice feature ( although my slicename are pretty cryptic and I'll have to make them prettier
I prefer it not being a child but a sibling like in the pub.
Alexander Henket (May 07 2019 at 18:09):
The folding part I like in Simplifier, but I'm not married to that feature. Improved rendering of slicing with Simplifier as how I'm used to look those trees, is the main objective.
Giorgio Cangioli (May 07 2019 at 18:13):
Beside expand/collapse i agree with Alexander that it might be useful to improve the way the slices are represented. Some time the repeating elements are misinterpreted by end users (we have received also ballot comments in the IPS due to this misinterpretation ).
Lloyd McKenzie (May 07 2019 at 18:13):
Having folding could be ok - so long as there's another view (and perhaps a default view) that's fully expanded.
Alexander Henket (May 07 2019 at 18:14):
Maybe a button collapse/expand all combined with a css for print that expands is enough?
Lloyd McKenzie (May 07 2019 at 18:15):
Default behavior should be safe for systems that don't have Javascript enabled.
Grahame Grieve (May 07 2019 at 18:17):
I don't know why the cardinality is not appearing
Grahame Grieve (May 07 2019 at 18:17):
I think I showed slicename before and people objected because it's not the actual name in the instance
Alexander Henket (May 07 2019 at 18:25):
So to summarize what I think we have so far:
1. Cardinality on "slice definition element" should occur
2. Slice definition rendered on the owning element is found not persuasive enough
3. Slices as child of "slice definition element" is found not persuasive
4. Slice names instead of element names has received pushback in the past so we should leave status quo
5. Folding taken under consideration
Grahame Grieve (May 07 2019 at 18:28):
err, I think you've overstated things. That would be the summary of the position put so far, but discussion is ongoing (and I reserve the right to change my mind yet)
Alexander Henket (May 07 2019 at 20:14):
I've added "so far" to it. Not sure what I could say or do at this point to move things further forward, so maybe leave it for a later moment?
Grahame Grieve (May 07 2019 at 20:21):
so far - maybe that's a language issue. It could mean either 'ongoing' or 'moved past'. We can wait to see if more people have things to say
Alexander Henket (May 08 2019 at 17:20):
On the topic of ANSI potentially complaining about "hidden text": in the official build there are many tabbed renderings, that could also be perceived as (initially) obscured text. I really hope that ANSI rules are not so rigid that those have to be removed too?
Grahame Grieve (May 08 2019 at 17:51):
no. there is all views on the tabs that matter
Alexander Henket (May 08 2019 at 20:02):
I'd compare folding with tabs. In a collapsed state you have more overview. In an expanded state you have more detail.
Michel Rutten (May 08 2019 at 20:21):
(IMHO ANSI rules are counterproductive, as presenting a huge blob of information can be quite overwhelming and probably does not guarantee that readers do not miss important aspects. Just my 2c)
Grahame Grieve (May 14 2019 at 04:37):
I have been reflecting further on this, and there were some discussions on the side in Montreal. The presentation of extensions as slices and other kinds of slices is inconsistent - see https://build.fhir.org/ig/hl7au/au-fhir-base/StructureDefinition-au-patient.html#profile for an example
Grahame Grieve (May 22 2019 at 00:22):
further reflection on this... looking at http://hl7.org/fhir/bp.html I'd like to change the way slices are presented along the lines Alexander is talking about - a node in the tree for the slicing, and then explicit childen for 'all slices' and each slice by name
Grahame Grieve (May 22 2019 at 00:22):
please vote on this - :+1: or :-1:
Lloyd McKenzie (May 22 2019 at 00:37):
It seems odd for the children of the slicing element and the slices themselves to be siblings...
Grahame Grieve (May 22 2019 at 00:38):
no there would be an introduced node for 'all slices' that would have the children in them
Grahame Grieve (May 22 2019 at 00:39):
(or the parent is the introduced node)
Lloyd McKenzie (May 22 2019 at 00:46):
So a root node for the base element that just says "sliced" or something like that (and defines the slicing rules), with child nodes for:
- "all slices", then nodes for each
- each defined (or inherited?) slice
- and finally (if defined), the "default" slice
Is that accurate?
Grahame Grieve (May 22 2019 at 00:46):
y
Michel Rutten (May 22 2019 at 08:21):
Seems similar to the way slices are visually presented in Forge.
Michel Rutten (May 22 2019 at 08:22):
For clarity, I decided to display a horizontal divider line between regular child elements ("nodes") of the slice introduction node, and any "virtual children" that represent associated named slices.
Josh Mandel (May 23 2019 at 21:51):
Can someone link to (or even send a pencil sketch of) what these presentations look like?
Michel Rutten (May 24 2019 at 12:53):
Here's an example of a slice on Patient.identifier in Forge R4:
pasted image
Michel Rutten (May 24 2019 at 12:54):
(named slices are displayed as "virtual" children of the slicing introduction element)
Michel Rutten (May 24 2019 at 12:55):
And here's an example of a slice on Condition.identifier, as rendered by Simplifier:
pasted image
Michel Rutten (May 24 2019 at 12:56):
And here's an advanced rendering in Forge of the same profile, also allowing access to default child elements of the slice introduction node:
pasted image
Michel Rutten (May 24 2019 at 12:57):
(with horizontal separator between the "regular" child elements and the "virtual" child nodes that represent named slices)
Grahame Grieve (May 24 2019 at 12:58):
I'm proposing to have a single child instead of the line - a 'rules for all slices' child
Michel Rutten (May 24 2019 at 13:02):
Yeah, I thought about that. It would introduce yet another level of indirection, i.e. another "virtual" parent node. Current approach was easy to implement in Forge, this would require a bit of hacking.
Josh Mandel (May 27 2019 at 11:27):
Logically, I feel like named slices belong adjacent to the unsliced elements (but I'm not sure what implications that has for the UX design)
Grahame Grieve (May 27 2019 at 19:31):
that's how I did it - but it gets confusing when there's a lot of sub-elements
Michel Rutten (May 28 2019 at 08:03):
Indeed, especially when slicing e.g. Composition into many sections, users seem to prefer representation of named slices as sub-elements of the slice intro.
Richard Townley-O'Neill (Jun 14 2019 at 06:37):
Currently extensions are rendered in the "name" column of the differential and snapshot tables using the id of the structure definition that defines the extension.
extension-display-name.png
From http://build.fhir.org/ig/hl7au/au-fhir-base/StructureDefinition-au-medlist.html
Richard Townley-O'Neill (Jun 14 2019 at 06:40):
How about showing the slice name instead of the extension id?
The slice name can be a name suitable to the context, not just an identifier of the extension.
Richard Townley-O'Neill (Jun 14 2019 at 06:42):
If the one extension is used in two slices, both will look the same in the differential and snapshot tables, even though they have different slice names.
Grahame Grieve (Jun 14 2019 at 21:10):
the slice name isn't always suitable
Michel Rutten (Jun 18 2019 at 11:23):
Forge displays profile extension elements using the assigned slice name... do you think this is not suitable?
Grahame Grieve (Jun 18 2019 at 12:36):
I don't know about forge but other sources are not always suitable
Michel Rutten (Jun 18 2019 at 14:12):
What do you mean with "not suitable"? Not display-friendly?
Slice names are author-assigned.
Lloyd McKenzie (Jun 18 2019 at 16:48):
Slice names are first and foremost intended to be computable. (They can be used in code generation.) Authors don't necessarily expect them to appear as a primary name or to be user-facing and as a result, the names in IGs won't necessarily be that human-friendly.
Michel Rutten (Jun 20 2019 at 10:04):
I see. Should we define an optional extension for the ElementDefinition.slicing component to specify a user-friendly slice title and/or description, for display purposes?
Last updated: Apr 12 2022 at 19:14 UTC
