Hi, Essentially, this problem of generating GUI:s can be said to be a special case of so called model-based user interfaces, a research topic that goes back at least to the 1980s. The idea is that if you have a good model of a system then you should be able to automatically generate a user interface, and this should work for different platforms, e.g., web, desktop, portable devices etc. (the generation part should conation enough knowledge to create good interfaces for different platforms.)
In the openEHR case there is a specific domain and also specifications (archetypes/templates) which you make the task easier than trying to do it generally Here are some random references G. Calvary, J. Coutaz, D. Thevenin, Q. Limbourg, L. Bouillon, and J. Vanderdon- ckt. A unifying reference framework for multi-target user interfaces. Interacting with Computers, 15(3):289?308, 2003. [J. Foley, C. Gibbs, and S. Kovacevic. A knowledge-based user interface management system. In Proceedings of the SIGCHI conference on Human factors in computing sys- tems, pages 67?72. ACM Press, 1988. G. Mori, F. Patern`o, and C. Santoro. Tool support for designing nomadic applications. In Proceedings of the 2003 international conference on Intelligent user interfaces, pages 141?148. ACM Press, 2003. F. Paterno and C. Santoro. A unified method for designing interactive systems adaptable to mobile and stationary platforms. Interacting with Computers, 15(3):349?366, 2003. A. Puerta, H. Eriksson, J. Gennari, and M. Musen. Model-based automated generation of user interfaces. In Proceedings of the National Conference on Artificial Intelligence, pages 471?477. American Association for Artificial Intelligence, 1994. N. Souchon and J. Vanderdonckt. A review of xml-compliant user interface description languages. In J. A. Jorge, N. J. Nunes, and J. F. e Cunha, editors, Interactive Systems. Design, Specification, and Verification, 10th International Workshop, DSV-IS 2003, volume 2844 of Lecture Notes in Computer Science. Springer, 2003. regards Olof 3 dec 2010 kl. 07.19 skrev Hong Yul Yang: Hi everyone, I've been a silent follower of this list for a long time. Nice of Koray to give me that little nudge to ease me into participating in the discussion. Much like pushing one into the dancing ring at a club party. It's comforting to know a lot of us are in the same boat. I haven't yet had the chance to check out what the other folks are doing (so apologies for my ignorance) re: GUI generation/customisation but in the meantime I can offer our (GastrOS) side of the story. It seems like a lot of the discussion has been around "where" the specification of the directives should go in the modeling process. While this is an important discussion, my focus as a pure software guy (i.e. a "heathen" wrt the clinical domain ;) is in the lower-level question of "how" the directives should work after all. It's probably worth noting that GastrOS generates GUI widgets dynamically at run-time: the widgets live and die in machine space, i.e. no code-generation etc. Effectively the heart of the GUI generator is a rule-based engine that processes the archetypes and spits out different GUI forms for different types of RM objects, then binds the forms to the RM object instances that live in the runtime environment. You could think of the generated GUI forms as "faces"/views of the RM object instances. So these rules I mentioned above are programmed into the GUI generator logic, e.g. textbox for DV_TEXT, combobox for DV_CODED_TEXT, a flow panel for CLUSTER, etc. These rules are also "compositional" in that they allow for recursive structures, so CLUSTER containing CLUSTER(s) maps to a panel containing panels, etc. Now I can introduce GUI directives into the picture. Basically the directives are specified as template-level annotations, and the semantics of these directives are also programmed into the GUI generator logic. So the GUI generator has a fixed vocabulary of directives it understands and performs appropriate "alterations" to the way it normally produces widgets. So this approach works sufficiently for our purposes. And Koray & I have tried to define the set of directives to cover as much of the basic GUI customisation needs of the general audience as possible. E.g. organising large structures into multiple columns and tabs, showing/hiding complex concepts, allowing the option to render the same data type as different controls (DV_CODED_TEXT as combobox or radio buttons), etc. But we know this is a very finite set, and if we were to cater for more complex customisations (especially when it comes to customising _behaviour_ on top of just appearance) we would need to keep programming them into the GUI generator. What I have been dreaming up is a way to "dependency inject" the directive semantics such that the power of specifying new GUI directives lies in the user of the GastrOS framework, not the developer. Sort of like how you customise Eclipse through plug-ins. So this is as far as my thought process has gotten to. I hope this all makes sense. Apologies for making it rather long and windy. I know you're all busy people! Would be very happy to hear comments about this, and I guess once you guys have the actual source code to play with, you might be able to shed more pointed insights. Getting GastrOS up on sourceforge is definitely at the top of our priority list and you will hear from us soon ;) all the best, Hong Yul On 2/12/2010 3:34 p.m., Koray Atalag wrote: 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:openehr-technical-bounces at openehr.org> [mailto:openehr-technical-boun...@openehr.org] On Behalf Of Thomas Beale Sent: Thursday, 2 December 2010 2:45 p.m. To: openehr-technical at openehr.org<mailto: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 -- Hong Yul Yang Research Programmer Department of Computer Science The University of Auckland Office (tamaki): 731-339 Phone: +649 373 7599 x88237 http://www.cs.auckland.ac.nz/~hongyul <ATT00001..txt> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101206/a07c6323/attachment.html>
