Stream: conformance
Topic: highlighting background color in snapshot view
Eric Haas (Jul 20 2016 at 23:57):
@Lloyd McKenzie I've been working with IG publisher and the highlighting of the "must supports" in the snapsho view t is confusing . It gets worse when you have around 50% of the elements as must supports. IMO is visual noise and should be scrapped. Any other opinions.
Grahame Grieve (Jul 20 2016 at 23:59):
I think it's not at all useful for something like DAF where it's not the final word in the implementation
Lloyd McKenzie (Jul 21 2016 at 02:27):
I'm not sure why the 50% would make a difference. Whether what you must support is a large portion of the elements or a small portion, it visually calls out what you need to worry about and what you can reasonably ignore. Obviously how likely you are to ignore the non-must support content depends on the nature of the specification. DAF is going to be seen as an implementable specification by some and not by others, so some will want it and others might not. Can you explain more about how it's confusing?
Eric Haas (Jul 21 2016 at 02:35):
At any thing larger than about 15% of highlight it becomes a random mess. see http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=10388
Grahame Grieve (Jul 21 2016 at 02:45):
Lloyd won't think that's too messy
Lloyd McKenzie (Jul 21 2016 at 04:02):
The random mess is just the reality - must support elements are sprinkled semi-randomly through the snapshot. The problem is it's hard to see where they are - and it's really quite important to see where they are. In my profiles, I've got 70-80% highlight sometimes (not a lot needs to be supported). But it's hugely useful for the implementers because they can clearly see which items they need to care about and which ones they don't.
Lloyd McKenzie (Jul 21 2016 at 04:03):
I can see that it would be distracting if you don't care about "must support", but not caring about mustSupport should be pretty rare . . .
Grahame Grieve (Jul 21 2016 at 04:35):
I think that's the core issue - the more the profile reflects actual implementation, the more that statement is true
Lloyd McKenzie (Jul 21 2016 at 04:39):
Well, even if a profile is designed to be further constrained, knowing what's called out as "must support" vs. not is just as important as what's minOccurs=1 - and we strongly highlight those elements too. The interpretation may shift from "I can ignore those elements" to "downstream profiles might choose to ignore those elements", but there's still a clear difference of "must support this" and "don't have to support this"
Grahame Grieve (Jul 21 2016 at 04:41):
how do we strongly highlight those?
Eric Haas (Jul 21 2016 at 04:43):
I think its a usability thing. If its too confusing it won't be read. I vote for letting the implementation guide editors decide on how they want too display these things.
Grahame Grieve (Jul 21 2016 at 04:43):
I thnk it would better to make the flags stand out more. make the S white on red background, say
Eric Haas (Jul 21 2016 at 04:43):
like little chilis in a chinese restaurant menu
for the spicy stuff
Grahame Grieve (Jul 21 2016 at 04:44):
I vote agaainst letting the IG editors decide these things. Not only to I have support deciding that in the generation, every one has to figure out what they mean in each guide
Eric Haas (Jul 21 2016 at 04:50):
But as an editor you already have a choice of using your own styles if you want anyway. Is this any different?
Grahame Grieve (Jul 21 2016 at 04:53):
yes. it is. For several reasons, we only support using fhir.css, and not changing the styles that affect the generated code.
Grahame Grieve (Jul 21 2016 at 04:53):
we do this for both technical/generation/support reasons, as well as consumer consistency about this
Grahame Grieve (Jul 21 2016 at 04:53):
I expect to bleed on this anyway
Grahame Grieve (Jul 21 2016 at 04:54):
for editor's own content, they can use whatever style they want
Grahame Grieve (Jul 21 2016 at 04:55):
the other thing is that I mostly use inline styling - saves me from having to figure out a precoordinated explosion of named styles, or trying to set up generation of styles as well as styled elements
Eric Haas (Jul 21 2016 at 04:57):
OK that is not how I interpreted it from reading the iG publisher guide. but i wasn't planning to create my own styles. I agree using the hot chili icons :-) for the must supports or at least making the flags more prominent.
Lloyd McKenzie (Jul 21 2016 at 05:50):
Having something in that one column isn't enough The row needs to be highlighted in some way - so when you're reading descriptions you can skip past the ones that don't matter. Or looking at cardinalities or whatever.
Lloyd McKenzie (Jul 21 2016 at 05:51):
The 1..x stuff at least makes the element name bold. And it doesn't influence whether you want to read the description or not. MustSupport does.
Lloyd McKenzie (Jul 21 2016 at 05:52):
Whatever we do needs to be something that impacts the whole line. If background higlighting is too much, we could change the text color perhaps. But it needs to be something so that whichever column I'm scanning, I know what to ignore and what to pay attention to.
Grahame Grieve (Jul 21 2016 at 05:59):
The 1..x makes the element name bold... no
Lloyd McKenzie (Jul 21 2016 at 06:36):
Did it not used to?
Grahame Grieve (Jul 21 2016 at 06:36):
no.
Grahame Grieve (Jul 21 2016 at 06:36):
never has
Grahame Grieve (Jul 21 2016 at 06:37):
I change the current build not to highlight by background color but with Eric's chillies, so we could see what it looks like
Grahame Grieve (Jul 21 2016 at 06:37):
should be built soon
Lloyd McKenzie (Jul 21 2016 at 06:38):
You built DAF? (Because it won't manifest except in profiles where mustUnderstand gets declared)
Grahame Grieve (Jul 21 2016 at 06:39):
wrong. Check http://hl7-fhir.github.io/lipidprofile.html
Lloyd McKenzie (Jul 21 2016 at 08:03):
It doesn't convey the same message. The chillies approach says "these rows are important" but it doesn't say "these rows are unimportant and can be ignored" which is what's wanted. We want to clearly show which rows implementers don't have to worry about and the chillie approach doesn't get us there.
Lloyd McKenzie (Jul 21 2016 at 18:29):
Ran this past the customer who'd requested the original change and they're comfortable with the chillies approach, though they'd prefer that the descriptive text of non-must support rows was a different color or something distinct.
Grahame Grieve (Jul 21 2016 at 19:23):
thanks.
Last updated: Apr 12 2022 at 19:14 UTC
