sön 18 feb. 2018 kl. 23:10 skrev GF <[email protected]>: > Is it an idea to annotate nodes with instructions for display. >
Yes, using (mostly shared/standardised) annotations for GUI-rendering hints in templates (or layers of templates) has been a major idea in previous GUI-related discussions in openEHR mailing lists. //Erik (We should link to some old list posts on the topic in that wiki page Tom created) > > Gerard Freriks > +31 620347088 > [email protected] > > Kattensingel 20 > 2801 CA Gouda > the Netherlands > > On 18 Feb 2018, at 15:16, Erik Sundvall <[email protected]> wrote: > > 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 > > > _______________________________________________ > 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
