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 plausible.
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 appropriate. Thilo 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 > >
