See short note inline On Mon, Jun 30, 2008 at 3:19 PM, Erik Sundvall <erisu at imt.liu.se> 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 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> > 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 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 > implementations. > > On Fri, Jun 27, 2008 at 10:57, Andrew Patterson <andrewpatto at gmail.com> > 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 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 > 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 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. > > Yes. > > 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.
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. -Thilo > > 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 > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >
