Hi All, late to respond but here are a few thoughts:
- While having ?another layer? of modelling to handle presentation I think we already have enough of those layers. I believe the common sense of doing this will be to sort out the GUI Directives stuff we all have come up with and do a careful analysis (led by the core team of course). Decide which ones are ?universal? and which ones are data-set specific. Then like annotations in templates invent new optional keywords to accommodate these. The operational template will then contain everything an application would need to function. - I strongly believe that the presentation information should not be separated from data-set definitions ? templates. As archetypes and templates are designed to handle ?change? this means that the model will be on constant change so maintaining two models ? kind of shadows of each other does not make sense to me. Perhaps not so good design from a puristic point of view ;) - I am also pretty sure that with a handful of those GUI directives we can cover %80 of all presentation requirements in any clinical domain ? we?ll worry about the rest later on. So it may well be the case that some of these directives may become concrete and be part of the specifications ? which will boost consistency among different implementations. - I also think while thinking on these issues we should also have a look at other facades of GUI ? such as implementation technologies, Web/client forms and MVC etc. methodologies. These may have an influence on the directives we will likely to come up with. My 4 cents...Cheers, -koray P.S. Our developer Mr. Hong Yul Yang (also an awesome pianist!) now has a good understanding of openEHR and I think he has much to contribute to this community...he gave a good deep thought to the above implementation technologies and MVC approach before going on with GastrOS. Hong Yul I think it is now time to talk for yourself ? don?t be shy! And people don?t hesitate to ask all your hard questions... From: openehr-technical-bounces at openehr.org [mailto:[email protected]] On Behalf Of Thomas Beale Sent: Thursday, 2 December 2010 2:45 p.m. To: openehr-technical at openehr.org Subject: Re: GUI-directives/hints again (Was: Developing usable GUIs) On 02/12/2010 01:33, Tim Cook wrote: On Thu, 2010-12-02 at 00:50 +0000, Thomas Beale wrote: This is one of the most common uses of templates we are finding. So somehow knowing the possible choices somehow affects the actual code in the field you are querying? in theory no, but it could affect what you consider to be correct. If you knew there were only 3 possible codes due to a template that had been used, then you might query directly using those codes, rather than the 20,000 allowed by the archetype. I can imagine other thing, e.g. coding of fields that were just DV_TEXT in the archetype. While I still think that this is a bad idea anyway. After all; it is either free text or coded text. Pick one. I still don't understand how knowing what set was available is meaningful to the code chosen. well the user often picks whether to code or not; a quite common visual control is one that allows either to be entered. So the template might define a preferred value set of codes, while still allowing for plain text. The archetype probably only had the plain text constraint. If you have the template at hand, you could do some querying based on the knowledge of the code subset used by the template. In ADL 1.5-land, a template is just another layer of archetyping, with some extra features. I still fail to see the need. It seems to me to be a useless layer of complexity. But, I am still interested in a use case where templates are 'needed' to 'fully interpret' the data. you mean the need of having the template to interpret the data? You can undoubtedly do it without the template. But since a lot of coding is defined locally, I think it is going to turn out to be useful. This is distinct from any 'visual template' stuff, which I agree should be a distinct artefact and probably formalism. And this level is dependent on implementation choices. Only applications built using the same framework can share these templates. If an entity is going to dictate presentation options and layout then they are likely (IMO) going to do so in the context of the same framework. sure. This would imply yet another technology-independent formalism, if gui directive templates are also going to be portable. - thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101202/d9a7e147/attachment.html>
