Hi Gavin, Thanks for the input, Now, to see a little bit more, please visit http://www.mscui.net/PatientJourneyDemonstrator/ Omer Hotomaroglu notified me of this some time ago, and I guess everyting here is not in CUI specs yet, but this is a much better demonstration of how GUI specialization can end up. Of course I'm not a clinician, but assuming MS has someone telling them that clinicians would be happy with this, I'm focusing on the functionality. As you've said it is about interactions between UI controls, and if you check this page you'll see that layout related capabilities are also important, I'll write about the in the wiki in detail, but the link above shows that making use of every UI capability is useful, actually, I've written about this in my blog some time ago : http://www.serefarikan.com/?p=42 The problem, especialy with these specific controls is, what will we do when a widget binds to multiple models? or there is an overlap between two models, which are used by two widgets on the same UI? I have reason to believe that our binding approaches are a little bit naive at this point, and I'd be satisfied when I can bind GUIs like in the Patient Journey Demonstrator to openEHR back end.
Now about UI - model relationship, my view is the GUI layer is way too complex and diverse to include in openEHR specifications, even a subset of the UI related stuff would be enough to introduce more problems than it solves. IF there emerges a cross platform AND cross technology declerative markup for GUI and GUI interactions and bindings, and this is a big if, then it may be considered, otherwise, my personal opinion is to simply leave certain things out of the specifications. Templates may have some space in them where you can act naughty? Like the Z segment of HL7 V2, a redlight district where everyone visits every once in a while, but does not mention so much.. I've never heard about Orbeon, and I'll be taking a good look at it, if it looks handy, I can simply add a link to it from Opereffa, to see how things will shape up. Thanks again for the input, and the useful discussion. Kind regards Seref On Tue, Jul 21, 2009 at 6:05 PM, gjb <gjb at crs4.it> wrote: > Hi Seref, > > Seref Arikan wrote: > > I've written an initial set of things here : > > > http://www.openehr.org/wiki/display/projects/Technology+and+architecture+challenges+in+UI+implementation > . > > based on Opereffa, but I'd really like to hear how others are tackling UI > > layer. > > I'm a little bit worried since I can see MS CUI ... > I had a look at these Silverlight "controls" - such as > http://www.mscui.net/Components/SingleConceptMatching.aspx > etc - perhaps I missed something, but > I can't see anything greatly different from what a Luddite > like me might achieve with XHTML-like select, check-boxes etc. > > Complexity grows, in any case, when one considers screens where > one data-value (e.g. drop-down list) should vary in accordance with > another control's value (e.g. another list's item). > I am not even sure how openEHR archetypes fully allow such co-occurrence > constraints to be defined - I guess I'd try using invariant rules. > This isn't just a case of panels/containers being present/visible or not > - as archetype-slot toggling ought to be able to handle. > > If we assume that detailed co-occurrence variations can be declared as > ASL invariant rules then - IMHO - it makes sense to take that > declarative approach down to the GUI level and interpret such rules at > data entry. > This is what xForms was supposed to be designed to do (using it's bind > declarations) - but the majority opinion of openEHR developer is that > xForms are dead in the water - and we should instead instantiate > object-oriented widgets to implement our GUIs. > > I am not so convinced - I've played with the Orbeon xForms server > http://www.orbeon.com/ > which embeds the eXist xml-db an I am quite impressed just how far > you can get in modern browsers without writing javascript or > requiring plugins. XML in XML out. It's nice to be web-based/RESTful > since it gives you so much for free. > It would be nice to implement a demo that compiles-down ADL to a form > Orbeon can serve - but, as I noted earlier, this is not a main-line > idea here: for one thing it mostly throws out the "O" from the "AOM". > > Good work with Opereffa > > > Gavin Brelstaff > CRS4 Sardinia Italy. > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090722/f11abdbc/attachment.html>
