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 oceaninformatics.com> 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 gmail.com> 
> 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 oceaninformatics.com> 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

On Fri, Jun 27, 2008 at 10:57, Andrew Patterson <andrewpatto at gmail.com> 
> 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 gmail.com> 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 oceaninformatics.com> 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 oceaninformatics.com> 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

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
- 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.

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 oceaninformatics.com> 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 gmail.com> wrote:
> I am with you on that layers are important and keep the approach more
> simple in the long time.


On Sat, Jun 28, 2008 at 13:38, Thilo Schuler <thilo.schuler at gmail.com> 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.

One last thing...

On Sat, Jun 28, 2008 at 00:18, Thomas Beale
<thomas.beale at oceaninformatics.com> 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 imt.liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-227579

Reply via email to