This is an Interesting topic! Standardised methods for representing application GUI behaviour/appearance in an open vendor neutral way is one of the few still missing pieces in the openEHR ecosystem needed in order to avoid vendor lock in.
Some clever choise of split point is likely fruitful since some parts are closer to openEHR data/query definitions and some will be closer to GUI-implementation/visualisation/layout frameworks (like Angular etc) that should likely not be reinvented by openEHR but that (sometimes at an annoying speed) keep changing versions and popularity faster than the RM/AM/AQL related data definition framework should... When designing this, perhaps some (2-5) existing currently popular GUI frameworks could be initial targets for output from the process, and the selection could be updated over time. Perhaps for example https://angular.io/ and https://reactjs.org/ are two starting candidates for experimentation? (Both have partially declarative design, but other suggestions are of course welcome) Then mechanisms in those platforms could be reused rather than reinvented. Also looking at the things done in the format used/shared by Marand and DIPS is an interesting input for gathering requirements. //Erik Sundvall sön 18 feb. 2018 kl. 11:51 skrev Thomas Beale <[email protected]>: > > > On 17/02/2018 20:11, Pablo Pazos wrote: > > I think SET<LOCATABLE> has a lot of applications, including result > > sets. Of course that should interior from LOCATABLE to be archetypable. > > > > I'm not sure on the types associated with the UI. I have a > > specification for UITenplates that includes some of that, I can share > > it :) > > > > I think any existing UI/template specification / app modelling would be > useful to share - possibly on the wiki - let me know if you need a page > there. > > My aim would be to get closer to an IDE application building tool for > clinical people to at least build a POC application that works, > something like Balsamiq but with real data connections built in. > Marand's EhrExplorer does some of this, and it would also be useful to > extract some of the semantics of that tool into a standard specification > to support this kind of thing. > > - thomas > > > _______________________________________________ > openEHR-technical mailing list > [email protected] > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > -- Sent from mobile.
_______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
