Very interesting - maybe we could have seperate namespaces for the core tags and extensions. Could be a good compromise! While I see the advantages of keeping GUI stuff out of the template, I also see that this more and more complicated as we add additional abstraction layers.
On Fri, Jun 27, 2008 at 2:26 PM, Rong Chen <rong.acode at gmail.com> wrote: > Hi all, > > My thoughts on this is so far our experience with templates are mostly > related to screen forms and GUI widgets. It's probably easiest to relate to > screens when engage clinicians for templates reviewing, hence the need for > visual presentation of templates from the NHS work. > > We also want to reuse the semantics in templates to generate messages, > reports etc. The question is how much 'generic' semantics can be reused from > the templates built for specific purpose - screen templates, message > templates and report templates. Surely the content for all types of > templates will be quite different and we probably would like to have special > syntax to support GUI hints, but do we need special syntax to support other > uses? How about indicators for decision support, clinical research data and > information lifecycle management? > > I am thinking about an extendable markup language that can be plugged into > the core template language as a way to add extensions to templates if there > is any application specific meta-data required. I am also in favour of the > idea to store these extra meta-data inside the templates to ease the > maintenance. When passing these templates around, the template engines can > ignore the extended markup and only process the standard part if they don't > recognize the extended syntax. > > Something like > > <gui_markup_plugin> > <hide_in_GUI path="..."/> > <hide_in_GUI path="..."/> > </gui_markup_plugin> > > > Cheers, > Rong > > > On Fri, Jun 27, 2008 at 12:30 PM, Thilo Schuler <thilo.schuler at gmail.com> > wrote: >> >> 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 >> > >> > >> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical at openehr.org >> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > >
