See short note inline

On Mon, Jun 30, 2008 at 3:19 PM, Erik Sundvall <erisu at> wrote:
> Hi!
> Thanks for a lot of interesting response regarding "GUI-hints" and other 
> things.
> Please excuse a little left-to-right analogy below:
> There seems too be a scale or spectrum of detail level and use case
> specificity going from...
> Left: purely semantic (maximum data set) models = archetypes
> ...via the nearby...
> openEHR templates (still purely semantic if we skip the "hide_in_ui"
> to keep the template artifacts)
> ...further far away to...
> Right: actual GUI in an implemented system with specific widgets positioning 
> etc
> Currently openEHR specifications describe artifacts at the "left" side
> of the spectrum. This discussion has interestingly been broadened
> further to the "right" than I was thinking of in my initial questions.
> If we look at a tool like the Template Designer from Ocean Informatics
> there is an immediate jump from templates (close to the left) to
> detailed GUI layout (far right), that jump could be divided into more
> steps (possibly with some steps persisted and reusable) as suggested
> by some in this discussion.
> On Fri, Jun 27, 2008 at 10:03, Hugh Leslie
> <hugh.leslie at> wrote:
>> I don't think that templates should contain GUI rendering hints
>> as they should remain purely about the semantics.
> ...
>> Personally, I think that there should be some other artifact that details
>> GUI specs - if we mix up the two things, then the purpose of the template
>> becomes confused.  Templates can be used for everything from GUI, to data
>> instance, persistance and query.
> On Fri, Jun 27, 2008 at 10:57, Andrew Patterson <andrewpatto at> 
> wrote:
>> I agree with Hugh - I would push back very strongly on the concept of
>> UI hints in the template definitions.
> On Sat, Jun 28, 2008 at 00:18, Thomas Beale
> <thomas.beale at> wrote:
>> *I think it will be one tool that writes two artefacts, one of which is
>> GUI 'hints'.
> These comments seem very reasonable, could we then conclude that the
> "hide_in_ui" and similar GUI-hints should not be in the template spec
> and that we instead can continue discussion regarding other artifacts
> with GUI-related information that might be reusable between
> implementations.
> On Fri, Jun 27, 2008 at 10:57, Andrew Patterson <andrewpatto at> 
> wrote:
>> I'd make the point that everyone always thinks that given enough hints
>> computers will be able to intelligently lay out interface components (not
>> just in openehr world - I have seen this in many UI projects). Invariably,
>> the autogenerated interfaces are the exception rather than the rule - by
>> that, I mean that the autogenerated interfaces can be made useful but
>> most real users end up preferring an interface layout designed explicitly
>> by a human being.
> I agree (except to "everyone always"). In most cases explicitly
> layouted interfaces will be preferred, due to aesthetics, optimal use
> of screen real estate etc. That's why I wrote "automated or
> _semi-automated_ design".
> Consider a use case where you at a national level want to standardize
> parts of the information capture in for example yearly diabetes
> check-up visits in primary care in order to do statistics, data mining
> etc. Also consider that a couple of parts will be added or modified on
> approximately a yearly basis to improve the follow up process and
> incorporate new treatments etc. Add to this that you have five openEHR
> compliant vendors with hundreds of separate system installations
> across the nation.
> The openEHR approach with archetypes and templates facilitate the
> semantic parts of the above scenario very well and the yearly updates
> of archetypes and templates can be loaded into the (purely semantic
> part) system more or less with the push of a button. But what happens
> on the GUI side of things? Will that always have to wait for manual
> layout before the new archetypes and templates can start to be used in
> clinical practice? How fast will that happen? Some vendors and
> customers will certainly have the resources to swiftly incorporate the
> changes but many others will experience considerable delay and would
> in the meantime have to resort to either keep using the old forms and
> semantics (thus loosing ability to capture data using the new national
> standars) or use general GUIs based on templates only (probably not so
> nice and efficient - driving clinicians crazy).
> Maybe this was just a way of restating Sebastians comment...
> On Fri, Jun 27, 2008 at 11:30, Sebastian Garde  wrote:
>> in my opinion it is
>> i) important to have some form of "GUI layout descriptions" that really 
>> enable
>> smart GUI generation in the long run. If not, the whole automatic process
>> stops just before the GUI, which is not really the best we can do in the long
>> run I think.
> When manually designing the GUIs, the designers (from every vendor)
> need to capture the user requirements in discussions with users, this
> is often done in several iterations of discussion and redesign. If we
> could capture at least some the common clinical GUI-related
> requirements in a machine readable form at an early stage we could
> achieve some benefits:
> 1. You could get a better "scaffolding" as a start in design tools
> than you would get from templates only, thus decreasing the manual
> design time needed in the scenario above.
> 2. You might be able to reduce the number of cycles of discussion and
> redesign above.
> 3. For cases where you would need to resort to automated GUI
> generation in the scenario (e.g. awaiting manual design or for very
> unusual things that your organisation does want to pay manual design
> for) you would be able to auto-generate a somewhat better GUI than
> using templates only (thus driving clinicians slightly less crazy).
> Machine readable requirements for some parts of course do not exclude
> usage of narrative forms GUI-requirement documents (or possibly
> included comments in some other artifact as suggested by Josina)
> coordinated at a national level and some of the listed benefits above
> could be achieved with narrative descriptions also. And yes some local
> GUI-adaptation/optimization and workflow integration will still be
> needed and can not all be done at a national level.
> Some good points regarding the risk of confusion when mixing
> discussions about semantics and layout were given:
> On Fri, Jun 27, 2008 at 12:54, Tim Cook <timothywayne.cook at> 
> wrote:
>>The clinicians
>> creating templates (as with archetypes) need to have training and a
>> special understanding of what is at stake.
>> If the clinicians designing archetypes/templates do not care about the
>> difference between semantics and GUI stuff then they are they wrong
>> clinicians to be designing archetypes and templates.
> On Fri, Jun 27, 2008 at 14:40, Heather Leslie
> <heather.leslie at> wrote:
>> In designing a website we know that if you want input about navigation, then
>> don't have any meaningful content or GUI hints available or almost certainly
>> all the feedback will be about the size or color of the button and the font
>> and position of the heading.
> (ES: I believe we mean different things when using the term "GUI hints".)
> On Fri, Jun 27, 2008 at 14:40, Heather Leslie
> <heather.leslie at> wrote:
>> Similarly my concern in designing templates and getting the content reviewed
>> appropriately is that as soon as you add interface/GUI features to make it
>> more 'intuitive' to the clinicians their focus goes immediately to that
>> which is more familiar.  That is, the feedback tends to be related to their
>> user interface experience (naturally gained from their day-to-day use of
>> their current clinical system) rather than actually critiquing which
>> archetypes have been used, which data fields are presented, and all their
>> associated attributes, cardinality, constraints and related metadata etc
>> etc.
>> So my preferred response (and from positive experience) is to spend a
>> relatively small amount of time to educate the clinicians on how to feedback
>> appropriately and meaningfully on the pure archetypes and templates - we
>> have done this successfully, but I suggest it is probably optimal if a
>> clinician involved in the design (perhaps a health informatician with a leg
>> in 'both camps') to walk them thru the models and to make it a sensible
>> conversation.  It is my opinion that the GUI design and review should be
>> completely separate to the content design and review - mixing the two gets
>> very confusing.
> Interesting observations. Is this the same when working with templates
> as with archetypes? When trying to capture the essential semantics of
> a maximum dataset during archetype design I fully understand the above
> reasoning and experiences. Thoughts about GUIs are just distracting
> then.
> I obviously did not explain clearly what I meant by GUI-hints. What I
> was thinking of was a bit more towards the "left" side of the spectrum
> trying to capture some some of the "semantics" of the
> human-computer-interaction when entering the things described by
> templates. I was not thinking of colors, fonts, detailed component
> placement etc. Instead I'm thinking of things like:
> - Greg's suggestion that one could specify whether a text node in a
> template will likely be short (e.g. a name) or if it is more likely to
> be a paragraph that would benefit from a multiline-type of text entry
> widget.
> - In a long template that also includes a section about "tobacco use"
> you might want to specify that the detailed parts regarding amount of
> consumption don't need to be shown if the person has been documented
> with the status "Never used". (I.e. implemented using simple
> conditional statements).
> - In the a particular use case in mind you might want to assign the
> the subtree "Consumption, Amount of substance" a higher priority in
> GUIs than the "Previous attempts to quit smoking" subtree so that the
> latter gets pushed to a normally hidden collapsed/hidden subform if
> there is a lack of space. (I.e. using a detail level mechanism)
> - Mechanisms like "hide_in_ui" to skip intermediate things that are
> meaningful in information modelling but are distracting or unnecessary
> in a GUI.
> As you can see these things have a bit of a semantic touch also, but
> maybe a different kind of semantics than we usually refer to as
> semantics in this community.
> When it comes to template design it would be interesting to know if
> the clinicians always are comfortable only having the on/off (set zero
> occurrence) of templates (or are there more restrictions available)?
> Don't you get a lot of "it depends"-answers whether to include
> something in a template or not? Do you believe that answers what to
> "kill" from (for the use case) overly detailed archetypes templates
> would be different if the clinicians are aware of the possibilities to
> change priorities, set conditional statements etc?
> I don't suggest that these hints necessarily should be created
> simultaneously with the template editing, but I guess that the very
> same clinical experts that design the template would be also good
> candidates to give some GUI-hints after the template creation.
> Thoughts?
> When it comes to what I call GUI-hints above I believe it would be
> useful to specify a model (like the with the AM) and one or many
> serialization formats of it rather than going straight for a markup
> language. Artifacts built using that model could then be used for auto
> generation of GUIs (whenever that is necessary) and as input to other
> steps specifying things more to the "right" in the spectrum like
> dealing with specific widgets, component positioning etc. for example
> as more intelligent scaffolding in manual editing environments than
> pure templates would be. More towards that right side one of the ways
> could be to go for markup-things such as xforms. To dig deper into
> such a more specific layer at the same time as researching a more
> general GUI-hint-layer might be a good idea. (I guess the interrelated
> AM and RM have been researched simultaneously for example in order to
> find good boundaries...)
> On Fri, Jun 27, 2008 at 11:30, Sebastian Garde
> <sebastian.garde at> wrote:
>> ii) However, it is important to keep this separate from templates. For
>> example, to be able to display what is in a template on different devices
>> ranging from normal to computers via PDAs to potentially your mobile phone,
>> different GUI principles may apply. So essentially to me this sound like it 
>> is
>> 1 template to n "GUI layout descriptions".
> The 1 template to n GUI-hint-artifacts principle seems reasonable. (A
> side note regarding different GUI principles: it would be interesting
> to see if/how the GUI-"semantic" hints like the ones above could map
> to different principles/paradigms)
> On Sat, Jun 28, 2008 at 13:38, Thilo Schuler <thilo.schuler at> 
> wrote:
>> I am with you on that layers are important and keep the approach more
>> simple in the long time.
> Yes.
> On Sat, Jun 28, 2008 at 13:38, Thilo Schuler <thilo.schuler at> 
> wrote:
>> Regarding Greg's comment on problems with the visibility of a certain
>> field: IMHO openEHR should not try to standardise GUIs (meaning
>> sharing GUI hints or presentation artefacts). This is a huge task and
>> we have enough problems solving what we are working on right now.
> The value of what to start experiments regarding how to "standardise"
> right now depends on what one happens to be working on right now :-) I
> don't suggest that for example Ocean Informatics would need to be
> pioneering everything if they have other important things to focus on.
> I do believe that there right now might be an interesting time for
> some of us in the community to start investigating the possibilities
> to share some kind(s) of artifacts assisting in GUI creation and
> maintenance across system implementations.
> Something that makes this task less "huge" than it would be in a
> general software setting is that we're dealing with a fixed AM and RM
> and a specific application area.

Great post Erik.

Don't get me wrong, I would love to have standardised rightish
artifacts and you argumented well regarding their advantages.

The reson I was sceptical is that if we want to solve too many things
generically it gets very complicated and not much will happen at all.
Therefore your suggestion: fixed RM and AM plus a specific (relatively
small) application area or set of use cases is a good simplified
starting point.


> One last thing...
> On Sat, Jun 28, 2008 at 00:18, Thomas Beale
> <thomas.beale at> wrote:
>> ... there are more semantic indicators being built
>> into the template designer, some based on the NHS CUI project, that will
>> provide good hints on GUI generation, including some temporal workflow
>> aspects.
> Are these things or the principles behind them something you can and
> would like to like detail a bit more or share with the community when
> time permits?
> Best regards,
> Erik Sundvall
> Link?ping University, Sweden
> erisu at Tel: +46-13-227579
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at

Reply via email to