Would also want GUI things like "hide_in_GUI" to be in a separate
artifact on top of a template. It is good to hear that Ocean only did
that as quick fix to meet customers requirements, which is very

As mentioned before templates are great to initially SCAFFOLD a GUI,
which has to be further adapted by humans for the best possible
usability results (use-case and device specific). This allows
verification of the templates and archetypes from a user point of view
and is very important as Richard pointed out.

I can understand Josinas comments about clinicians not caring about
the difference between semantics and GUI stuff, so a tool like the
Template Designer should hide this important separation, where


On Fri, Jun 27, 2008 at 10:03 AM, Hugh Leslie
<hugh.leslie at oceaninformatics.com> wrote:
> Hi Erik
> Personally, I don't think that templates should contain GUI rendering hints
> as they should remain purely about the semantics.  There are others that
> don't agree with me.  The "hide on form" function in the Template designer
> was partly to meet requirements for documentation of the templates for some
> groups using this technology.  I am not sure if the hide_in_ui parameter is
> going to make it into the final template spec - Tom will have something to
> say about that.
> 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.  If we add a whole lot of parameters around
> GUI, then we will also probably need to add specific things for these other
> uses and it might get very messy.
> regards Hugh
> Erik Sundvall wrote:
> Hi!
> On Fri, Jun 27, 2008 at 07:08, Greg Caulton <caultonpos at gmail.com> wrote:
> Thanks to the java reference implementation I have a demo of importing
> archetypes to auto generate forms which have the references to the
> archetype.
> Nice. Keep up the good work.
> On Fri, Jun 27, 2008 at 07:08, Greg Caulton <caultonpos at gmail.com> wrote:
> One thing I noticed in the conversion that I don't have any way of
> distinguishing between a line of text and multiline text in the
> archetype (I would generate an appropriate pane in the latter case).
> Perhaps not a big deal.
> This might be a useful requirement for the current template
> specification currently being worked on, or possibly a new kind of
> related specification.
> I first thought that templates so far had been considered as purely
> specifying semantics and that they were not supposed to give hints
> regarding GUI rendering. But now I see a parameter "hide_in_ui" in the
> class T_COMPLEX_OBJECT found in the draft template specification. (A
> similar function is present in the Template Designer tool from Ocean
> Informatics there is an option to "hide" elements instead of
> constraining them to zero occurrence, in the output file this is
> persisted as hide_on_form="true".) Could anybody detail it's intended
> use a bit more?
> I think GUI rendering hints can be appropriate to specify at the same
> point in time as template design is taking place. If the hints are to
> be persisted in the template file or in a separate file I guess could
> be discussed, keeping it in the file could have maintenance
> advantages, but probably has some disadvantages too. Thoughts? (And
> no, GUI hints are not appropriate in Archetypes since they are meant
> to have a wider reuse and the use cases are not known in the same
> detail as for templates.)
> In some of our implementation experiments and in discussions with
> clinicians a possible need for specifying detail levels in templates
> have surfaced. Some elements from archetypes are easy to completely
> dismiss or include for the specific use case in mind when designing a
> template clinicians will say things like "this will always be needed"
> or "this will never be needed". Other things could be conditional and
> trickier "you can't have all these details om the form - users would
> go crazy - let them show up if i click a plus-button or if i tick
> value x was true".
> The requirement to use GUI screen area optimally is even more pressing
> when using small input devices such as PDAs.
> If there was some way of specifying detail level in the template
> perhaps using a simple integer (0=default, 1..n=deeper detail with
> increasing number) then the same template could better support
> automated or semi-automated design of entry forms different screen
> sizes etc. One naive/simple but useful way of using the integer could
> be to add a "plus-button" for things with detail level 1 and within
> that subform have further plus buttons for level 2 and so on.
> The "conditional" requirements are trickier and probably needs  more
> experimentation and evaluation than can be allowed if a first template
> specification should be completed and released within reasonable time
> (we all want that). The conditions might also in some cases better be
> specified in decision support or workflow  than in templates. Also a
> look at the previous work with gradually expanding forms in
> Clinergy/Pen&Pad should be considered, I believe they were partly auto
> generated from ontologies.
> Thoughts?
> Best regards,
> Erik Sundvall
> 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
> --
> ________________________________________________
> Dr Hugh Leslie MBBS, Dip. Obs. RACOG, FRACGP, FACHI
> Clinical Director
> Ocean Informatics Pty Ltd
> M: +61 404 033 767   E: hugh.leslie at oceaninformatics.com  W:
> www.oceaninformatics.com
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

Reply via email to