openEHR Transition: Web-based tools?
Hi all, Both approaches have their pros and cons. I would suggest a hybrid approach. Have a desktop app with a local Db that updates itself from a web based repository, as per need. This way you could have the security and speed of a desktop app with the 'updatability' of a web model. With warm regards, Dr D Lavanian MBBS,MD CEO and MD HCIT Consultant www.hcitconsultant.com Visit www.medhelp247.com for a life saving medical service Certified HL7 Specialist Executive Member - IAMI Co-Chair, Memberships - HL7 India Member- American Medical Informatics Association Member HIMSS Senior Consultant and Domain Expert - Healthcare Informatics and TeleHealth Former Vice President - Healthcare Products, Bilcare Ltd Former Vice President - Software Division, AxSys Healthtech Ltd Former Co-convener Sub committee on Standards , Governmental Task force for Telemedicine Former Vice President - Telemedicine (Technical), Apollo Hospitals Group Former Deputy Director Medical Services, Indian Air Force Office: +91 20 32345045 Mobile: +91-9970921266 - Original Message - From: pablo pazos To: openehr technical Sent: Saturday, September 10, 2011 11:01 PM Subject: RE: openEHR Transition: Web-based tools? Hi Ian, We develop web based systems because we are web developers. In my case I have started my programming skills on web based systems, and now I have learned a lot of tools, frameworks and web standards and I have very little experience on desktop based tools. Said that, I think desktop based tools have the same value and usability as the web based ones. There are tools that by nature have to be web based, but other tools like the template editor is ok on desktop. I have the dream that one day I open just one program (a web browser) and get free access to all the archetypes and templates available in the cloud (multiple CKMs), and may create, edit and share those artefacts also online. Sometimes I think about something like an openEHR facebook, where archetypes are people, templates are groups, and all are related by slots (friend relationships). This is just a dream... -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos > From: Ian.McNicoll at oceaninformatics.com > Date: Fri, 9 Sep 2011 16:10:10 +0100 > Subject: openEHR Transition: Web-based tools? > To: openehr-technical at openehr.org > > Hi all, > > One of the suggestions in the White Paper which appears to have > universal support is a move to support much more open-source tools > development. Clearly some tooling must be web-based e.g repository > management and associated formal and informal discussion e.g. CKM and > any new community repository. > > However, I am much less clear on why we might need web-based primary > authoring tools for archetypes and templates. Diego, Pablo and Sam are > all keen on this approach but I remain unconvinced that this is really > a key requirement, given that archetype authoring is in essence a > solitary activity much like any other code development. By all means > build in much better integration with repositories and other > mechanisms to allow joint working, but even with modern javascript > libraries and Flex-style components, HTML-based tooling just feels > like it adds a layer of development complexity and probably some > usability-clunkiness which is not offset by the benefits. > > Maybe I am just an old-timer but having waited for may years to get > the kind of development environment that Visual Studio, Eclipse and > equivalents bring, and that I think is equally required for archetype > development, I am loathe for us to get slowed-down by insisting on a > 'web-based'. > > What do others think? > > Ian > > Dr Ian McNicoll > office +44 (0)1536 414 994 > fax +44 (0)1536 516317 > mobile +44 (0)775 209 7859 > skype ianmcnicoll > ian.mcnicoll at oceaninformatics.com > > Clinical Modelling Consultant, Ocean Informatics, UK > openEHR Clinical Knowledge Editor www.openehr.org/knowledge > Honorary Senior Research Associate, CHIME, UCL > BCS Primary Health Care www.phcsg.org -- ___ 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/20110911/00920c18/attachment.html>
openEHR Transition: Web-based tools?
Hi Tom My interest is the pain we get as the tools get developed and tweaked as does ADL and multiple versions. well, changes to formalisms are different from changes to tools. All these things are already or can be version managed, so this is just a question of release management. [Sam Heard] No, it is people from the installed base working on current archetypes. It is always unclear when current users HAVE to upgrade to continue working..the web means we can do this organically. The Foundation is planning a move to ADL 1.5 and clearly this should be the environment that the tools support. There will be tweeks to the specifications during the early years. Also, if we are to use Thomas' engine it should tip the balance a bit further as installing and updating numerous layers gets even more painful. Sam, I am not sure what you mean by this. [Sam Heard] Supporting services through DLLs, RPCs and other technologies is difficult as it requires a local installation. The Brosphorus (Seref/Beale) service will require further implementation locally. Just as we see that the Eiffel library finds it difficult to keep up with the Mac except by going to the BSD environment (let alone iOS and Android), we will see a lot of locally supported applications move to web based tools when the GUI support is sufficient. Finally, web tools are easier to access on multiple devices including mobile. that's one advantage for sure. But we don't see any 'heavy' tools being used over the web yet, e.g. Eclipse, Visual Studio. [Sam Heard] These are for building the applications that we want - they will build web-based tools as well. I agree that development environments are likely to be local for some time - though GIThub and others provide a lot of that support via the web now. Cheers,. Sam -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110911/ce6767ab/attachment.html>
openEHR Transition: Web-based tools?
Hi Dr Lavinian, That was what I had in mind, absolutely integrate with repositories via web-services. I could be persuaded by a full web-based tool if someone could convince that me that difficulties of developing a complex UI are offset by other advantages, that it can operate off-line, that it can quickly implement no-cost, multiple temporary working areas, fully integrate with my other desktop applications and not get mangled by browser updates. I am not at all convinced by the deployment/update argument for web-based tools. It really is not at all difficult to manage packaged downloadable installs, including slip-streamed updates with notifications. I have done this myself with as one developer, 3000 users and a decent install program Perhaps the java environment is harder but my consumer experience of Eclipse and other java apps is not one of horrible complexity. Whilst seamless automatic updating of a web-app is generally helpful, there are situations where such updating conflicts with user wishes, so you end up having to replicate an upgrade only on-demand facility as per Google mail, or 'revert to older version'. But for me the UI issue is critical. I know that javascript and HTML5 developments are improving things all the time but web-based apps are still always more clunky and prone to weirdnesses that you simply do not see with desktop apps. As Seref says this is not the place to document actual UI requirements but I think it is fair to position an archetype/template tool with the UI demands of an Eclipse/VS type application, and as THomas says, no-one is using web apps for this kind of scenario. Pablo - is your web-based template tool visible anywhere? Perhaps you could persuade me that I ma wrong :-) Ian Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical Modelling Consultant,?Ocean Informatics, UK openEHR Clinical Knowledge Editor www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care ?www.phcsg.org On 11 September 2011 02:25, Dr Lavanian wrote: > Hi all, > Both approaches have their pros and cons. I would suggest a hybrid approach. > Have a desktop app with a local Db that updates itself from a web? based > repository, as per need. This way you could have the security and speed of a > desktop app with the?'updatability' of a web model. > > With warm regards, > > Dr D Lavanian > MBBS,MD > CEO and MD > HCIT Consultant > www.hcitconsultant.com > > Visit www.medhelp247.com for a life saving medical service > > Certified HL7 Specialist > Executive Member - IAMI > Co-Chair, Memberships - HL7 India > Member- American Medical Informatics Association > Member HIMSS > Senior Consultant and Domain Expert - Healthcare Informatics and TeleHealth > Former Vice President - Healthcare Products, Bilcare Ltd > Former Vice President - Software Division, AxSys Healthtech Ltd > Former Co-convener Sub committee on Standards , Governmental Task force for > Telemedicine > Former Vice President - Telemedicine (Technical), Apollo Hospitals Group > Former Deputy Director Medical Services, Indian Air Force > Office: +91 20 32345045 > Mobile: +91-9970921266 > > - Original Message - > From: pablo pazos > To: openehr technical > Sent: Saturday, September 10, 2011 11:01 PM > Subject: RE: openEHR Transition: Web-based tools? > Hi Ian, > > We develop web based systems because we are web developers. In my case I > have started my programming skills on web based systems, and now I have > learned a lot of tools, frameworks and web standards and I have very little > experience on desktop based tools. > > Said that, I think desktop based tools have the same value and usability as > the web based ones. There are tools that by nature have to be web based, but > other tools like the template editor is ok on desktop. > > I have the dream that one day I open just one program (a web browser) and > get free access to all the archetypes and templates available in the cloud > (multiple CKMs), and may create, edit and share those artefacts also online. > Sometimes I think about something like an openEHR facebook, where archetypes > are people, templates are groups, and all are related by slots (friend > relationships). This is just a dream... > > -- > Kind regards, > Ing. Pablo Pazos Guti?rrez > LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez > Blog: http://informatica-medica.blogspot.com/ > Twitter: http://twitter.com/ppazos > >> From: Ian.McNicoll at oceaninformatics.com >> Date: Fri, 9 Sep 2011 16:10:10 +0100 >> Subject: openEHR Transition: Web-based tools? >> To: openehr-technical at openehr.org >> >> Hi all, >> >> One of the suggestions in the White Paper which appears to have >> universal support is a move to support much more open-source tools >> development. Clearly some tooling must be web-based e.g repository >> management and associated formal and infor
openEHR Transition: Web-based tools?
Peter, The problem is not necessarily about the capability of frameworks to manage updates or side by side execution. 90% of the time problem is about the IT policies of the institutions. If you develop with .NET 4.0, which would require a .net framework 4.0 runtime, you assume that the people using the software would be able to install the runtime, and install the software. many corporate/institutional machines do not allow their users install software. Most of the corporate/institutional IT is running on horribly old software. IT policy is the real issue I was referring to. I don't want to go into a long description of things that went wrong for me in the past, but let me just say that I've personally had enough issues with both Java and .NET deployment and upgrades that makes web based apps a much better option when it comes to this particular aspect of software life cycle. Regards Seref On Sat, Sep 10, 2011 at 2:18 PM, Peter Gummer wrote: > Seref Arikan wrote: > >> ... ?Unfortunately, most modern >> software development technologies arrive with their own runtimes, >> (.net framework, jre etc) and it quickly becomes a nightmare to deploy >> and update software. > > I'm not aware of any such deployment problems with .NET. I'm sure > there must be some, somewhere, but they must be edge cases. In ten > years of .NET development I haven't bumped into them. Different > versions of .NET sit side-by-side on the same machine just fine; ditto > for DLLs targeted towards different .NET versions. My daily work > involves a .NET 4.0 application that has dependencies on a lot of .NET > 2.0 DLLs; it just works seamlessly. > > - Peter > ___ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >
openEHR Transition: Web-based tools?
Hi Seref, I accept that , but you can say exactly the same thing about browsers and web connectivity generally. Until very recently the NHS in the UK mandated IE6 - go figure. How long before we see snazzy new HTML5 browsers in these environments? Ian Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical Modelling Consultant,?Ocean Informatics, UK openEHR Clinical Knowledge Editor www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care ?www.phcsg.org On 11 September 2011 11:21, Seref Arikan wrote: > Peter, > The problem is not necessarily about the capability of frameworks to > manage updates or side by side execution. > 90% of the time problem is about the IT policies of the institutions. > If you develop with .NET 4.0, which would require a .net framework 4.0 > runtime, you assume that the people using the software would be able > to install the runtime, and install the software. > many corporate/institutional machines do not allow their users install > software. Most of the corporate/institutional IT is running on > horribly old software. IT policy is the real issue I was referring to. > I don't want to go into a long description of things that went wrong > for me in the past, but let me just say that I've personally had > enough issues with both Java and .NET deployment and upgrades that > makes web based apps a much better option when it comes to this > particular aspect of software life cycle. > > Regards > Seref > > > On Sat, Sep 10, 2011 at 2:18 PM, Peter Gummer > wrote: >> Seref Arikan wrote: >> >>> ... ?Unfortunately, most modern >>> software development technologies arrive with their own runtimes, >>> (.net framework, jre etc) and it quickly becomes a nightmare to deploy >>> and update software. >> >> I'm not aware of any such deployment problems with .NET. I'm sure >> there must be some, somewhere, but they must be edge cases. In ten >> years of .NET development I haven't bumped into them. Different >> versions of .NET sit side-by-side on the same machine just fine; ditto >> for DLLs targeted towards different .NET versions. My daily work >> involves a .NET 4.0 application that has dependencies on a lot of .NET >> 2.0 DLLs; it just works seamlessly. >> >> - Peter >> ___ >> openEHR-technical mailing list >> openEHR-technical at openehr.org >> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >> > > ___ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >
openEHR Transition: Web-based tools?
Seref Arikan wrote: > 90% of the time problem is about the IT policies of the institutions. > If you develop with .NET 4.0, which would require a .net framework 4.0 > runtime, you assume that the people using the software would be able > to install the runtime, and install the software. Yes, that's a problem I have run into once or twice. It's the perfect argument for developing Eiffel native executables. The problem then, of course, is that support may be less than perfect for the system that you want to run the application on. Getting behind the effort to get Eiffel running better on those platforms would be the quickest and most effective way to go, in my opinion. > ... web based apps a much better option when it comes to this > particular aspect of software life cycle. But web based apps bring their own set of problems that desktop apps don't have. Ian has been talking about poor usability. * How do you do keyboard shortcuts in a web application? How do you set keyboard focus to the appropriate widget to maximise ease of use? Both of those can be achieved in a web app, but it's extremely difficult. * How do you recover gracefully when the user's session times out? Imagine you're in the middle of working on an archetype, you spend 20 minutes talking to a colleague or answering emails, and your web session times out. All of your work is gone. There are ways to handle this gracefully, but they are are horribly difficult to program. This problem simply doesn't exist with desktop apps. * How do you design your application so that it performs well without putting half of your business logic into Javascript that is riddled with hacks for handling old browsers? - Peter
openEHR Transition: Web-based tools?
Hi! I agree with Seref. Web based apps nowadays can use local storage in modern web clients and even be run perfectly offline and sync when they get back online. If effort is put into new tools it might be good idea to do at least the GUI in HTML5 etc. The server could be any technology you want, including Eiffel ;-), as long as it speaks http, if "normal" users (including ones under IT policies of the institutions) don't need to do a server install. Regarding editing power and repository integration have a look at some examples like http://c9.io/ http://ace.ajax.org/ By the way, using Git as archetype repository sync backend at least for non-CKM work (as hinted by Shinji) seems to be a really nice idea the nore you look at it. The Git collaboration patterns and mentality seem to fit the use-case of distributed multi-branched archetype development. Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733 On Sun, Sep 11, 2011 at 12:21, Seref Arikan wrote: > Peter, > The problem is not necessarily about the capability of frameworks to > manage updates or side by side execution. > 90% of the time problem is about the IT policies of the institutions. > If you develop with .NET 4.0, which would require a .net framework 4.0 > runtime, you assume that the people using the software would be able > to install the runtime, and install the software. > many corporate/institutional machines do not allow their users install > software. Most of the corporate/institutional IT is running on > horribly old software. IT policy is the real issue I was referring to. > I don't want to go into a long description of things that went wrong > for me in the past, but let me just say that I've personally had > enough issues with both Java and .NET deployment and upgrades that > makes web based apps a much better option when it comes to this > particular aspect of software life cycle. > > Regards > Seref > > > On Sat, Sep 10, 2011 at 2:18 PM, Peter Gummer > wrote: >> Seref Arikan wrote: >> >>> ... ?Unfortunately, most modern >>> software development technologies arrive with their own runtimes, >>> (.net framework, jre etc) and it quickly becomes a nightmare to deploy >>> and update software. >> >> I'm not aware of any such deployment problems with .NET. I'm sure >> there must be some, somewhere, but they must be edge cases. In ten >> years of .NET development I haven't bumped into them. Different >> versions of .NET sit side-by-side on the same machine just fine; ditto >> for DLLs targeted towards different .NET versions. My daily work >> involves a .NET 4.0 application that has dependencies on a lot of .NET >> 2.0 DLLs; it just works seamlessly. >> >> - Peter
openEHR Transition: Web-based tools?
Erik Sundvall wrote: > I agree with Seref. ... > > If effort is put into new tools it might be good idea to do at least > the GUI in HTML5 etc. That rules out all of those corporate users that Seref and Ian mentioned who are stuck on IE6, doesn't it? - Peter
openEHR Transition: Web-based tools?
I have still not seen anything that looks remotely like a modern IDE This looks like state of the art ... A look at Eclipse' new browser-based web development tool, Orion http://www.youtube.com/watch?v=yA_lsvKfv4I I remain unimpressed (in terms of what we might require) but happy to be pointed to a real, working example of a web-development tool which might replace and considerably augment current archetype editor, template designer functionality, without requiring some really arcane web-developer skills. What we should really do now is to establish the requirements for this second generation of tools. I am certain web-services will play a big part in repository integration and e.g validation/comparison services but still not convinced that the kind of rich GUI we require is deliverable quickly with HTML. Thanks all. Interesting discussion :-) Ian Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical Modelling Consultant,?Ocean Informatics, UK openEHR Clinical Knowledge Editor www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care ?www.phcsg.org On 11 September 2011 14:23, Erik Sundvall wrote: > Hi! > > I agree with Seref. Web based apps nowadays can use local storage in > modern web clients and even be run perfectly offline and sync when > they get back online. > > If effort is put into new tools it might be good idea to do at least > the GUI in HTML5 etc. The server could be any technology you want, > including Eiffel ;-), as long as it speaks http, if "normal" users > (including ones under IT policies of the institutions) don't need to > do a server install. > > Regarding editing power and repository integration have a look at some > examples like > http://c9.io/ > http://ace.ajax.org/ > > By the way, using Git as archetype repository sync backend at least > for non-CKM work (as hinted by Shinji) seems to be a really nice idea > the nore you look at it. The Git collaboration patterns and mentality > seem to fit the use-case of distributed multi-branched archetype > development. > > Best regards, > Erik Sundvall > erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733 > > > > On Sun, Sep 11, 2011 at 12:21, Seref Arikan > wrote: >> Peter, >> The problem is not necessarily about the capability of frameworks to >> manage updates or side by side execution. >> 90% of the time problem is about the IT policies of the institutions. >> If you develop with .NET 4.0, which would require a .net framework 4.0 >> runtime, you assume that the people using the software would be able >> to install the runtime, and install the software. >> many corporate/institutional machines do not allow their users install >> software. Most of the corporate/institutional IT is running on >> horribly old software. IT policy is the real issue I was referring to. >> I don't want to go into a long description of things that went wrong >> for me in the past, but let me just say that I've personally had >> enough issues with both Java and .NET deployment and upgrades that >> makes web based apps a much better option when it comes to this >> particular aspect of software life cycle. >> >> Regards >> Seref >> >> >> On Sat, Sep 10, 2011 at 2:18 PM, Peter Gummer >> wrote: >>> Seref Arikan wrote: >>> ... ?Unfortunately, most modern software development technologies arrive with their own runtimes, (.net framework, jre etc) and it quickly becomes a nightmare to deploy and update software. >>> >>> I'm not aware of any such deployment problems with .NET. I'm sure >>> there must be some, somewhere, but they must be edge cases. In ten >>> years of .NET development I haven't bumped into them. Different >>> versions of .NET sit side-by-side on the same machine just fine; ditto >>> for DLLs targeted towards different .NET versions. My daily work >>> involves a .NET 4.0 application that has dependencies on a lot of .NET >>> 2.0 DLLs; it just works seamlessly. >>> >>> - Peter > > ___ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >
openEHR Transition: Web-based tools?
Deputy Director Medical Services, Indian Air Force > > Office: +91 20 32345045 > > Mobile: +91-9970921266 > > > > - Original Message - > > From: pablo pazos > > To: openehr technical > > Sent: Saturday, September 10, 2011 11:01 PM > > Subject: RE: openEHR Transition: Web-based tools? > > Hi Ian, > > > > We develop web based systems because we are web developers. In my case I > > have started my programming skills on web based systems, and now I have > > learned a lot of tools, frameworks and web standards and I have very little > > experience on desktop based tools. > > > > Said that, I think desktop based tools have the same value and usability as > > the web based ones. There are tools that by nature have to be web based, but > > other tools like the template editor is ok on desktop. > > > > I have the dream that one day I open just one program (a web browser) and > > get free access to all the archetypes and templates available in the cloud > > (multiple CKMs), and may create, edit and share those artefacts also online. > > Sometimes I think about something like an openEHR facebook, where archetypes > > are people, templates are groups, and all are related by slots (friend > > relationships). This is just a dream... > > > > -- > > Kind regards, > > Ing. Pablo Pazos Guti?rrez > > LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez > > Blog: http://informatica-medica.blogspot.com/ > > Twitter: http://twitter.com/ppazos > > > >> From: Ian.McNicoll at oceaninformatics.com > >> Date: Fri, 9 Sep 2011 16:10:10 +0100 > >> Subject: openEHR Transition: Web-based tools? > >> To: openehr-technical at openehr.org > >> > >> Hi all, > >> > >> One of the suggestions in the White Paper which appears to have > >> universal support is a move to support much more open-source tools > >> development. Clearly some tooling must be web-based e.g repository > >> management and associated formal and informal discussion e.g. CKM and > >> any new community repository. > >> > >> However, I am much less clear on why we might need web-based primary > >> authoring tools for archetypes and templates. Diego, Pablo and Sam are > >> all keen on this approach but I remain unconvinced that this is really > >> a key requirement, given that archetype authoring is in essence a > >> solitary activity much like any other code development. By all means > >> build in much better integration with repositories and other > >> mechanisms to allow joint working, but even with modern javascript > >> libraries and Flex-style components, HTML-based tooling just feels > >> like it adds a layer of development complexity and probably some > >> usability-clunkiness which is not offset by the benefits. > >> > >> Maybe I am just an old-timer but having waited for may years to get > >> the kind of development environment that Visual Studio, Eclipse and > >> equivalents bring, and that I think is equally required for archetype > >> development, I am loathe for us to get slowed-down by insisting on a > >> 'web-based'. > >> > >> What do others think? > >> > >> Ian > >> > >> Dr Ian McNicoll > >> office +44 (0)1536 414 994 > >> fax +44 (0)1536 516317 > >> mobile +44 (0)775 209 7859 > >> skype ianmcnicoll > >> ian.mcnicoll at oceaninformatics.com > >> > >> Clinical Modelling Consultant, Ocean Informatics, UK > >> openEHR Clinical Knowledge Editor www.openehr.org/knowledge > >> Honorary Senior Research Associate, CHIME, UCL > >> BCS Primary Health Care www.phcsg.org > > > > > > > > ___ > > openEHR-technical mailing list > > openEHR-technical at openehr.org > > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > > > ___ > > openEHR-technical mailing list > > openEHR-technical at openehr.org > > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > > > > > ___ > 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/20110911/f53a7f89/attachment.html>
openEHR Transition: Web-based tools?
Hi Peter, Web developers can easily tackle those problems, see below: > But web based apps bring their own set of problems that desktop apps > don't have. Ian has been talking about poor usability. > > * How do you do keyboard shortcuts in a web application? How do you > set keyboard focus to the appropriate widget to maximise ease of use? > Both of those can be achieved in a web app, but it's extremely > difficult. > Just use HTML: http://en.wikipedia.org/wiki/Access_key > * How do you recover gracefully when the user's session times out? > Imagine you're in the middle of working on an archetype, you spend 20 > minutes talking to a colleague or answering emails, and your web > session times out. All of your work is gone. There are ways to handle > this gracefully, but they are are horribly difficult to program. This > problem simply doesn't exist with desktop apps. > One way to maintain a session open is to send heartbeats using AJAX: http://en.wikipedia.org/wiki/Ajax_%28programming%29 > * How do you design your application so that it performs well without > putting half of your business logic into Javascript that is riddled > with hacks for handling old browsers? > For performance and rich user interaction we have to use AJAX. For compatibility, use standards: http://www.w3.org/ -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110911/c173aafd/attachment.html>
EN/ISO 13606 & openEHR - harmonisation possibilities
-Original Message- From: Diego Bosc? Sender: "openehr-technical-bounces at openehr.org" Date: Sat, 10 Sep 2011 09:45:17 To: For openEHR technical discussions Reply-To: For openEHR technical discussions Subject: Re: EN/ISO 13606 & openEHR - harmonisation possibilities yes, what I mean is attributes like ID or even invalid characters in the names (like ':'). This is a problem with the parser (and also with classes identifiers) 2011/9/10 Thomas Beale : > On 10/09/2011 12:59, Diego Bosc? wrote: >> >> This kind of problems has given us a lot of problems when using ADL to >> work with other models like HL7 CDA or CDISC ODM, where there isn't >> any kind of rule (for example, in ADL CLASSES must be upercase and the >> attributes lowercase, and in CDA this is not true) > > actually there is no rule in ADL. You can use CamelCase, and it has been > working for the entire lifetime of the tools. Indeed you will see it in > the 13606 and 21090 schemas, which are processed by the ADL Workbench. > It's just that the documents use a particular convention which happens > to be the underscore convention, for better readability. My view is that > any given model should stick to one or the or the convention > consistently, whatever convention that may be. > > - thomas >___ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical La informaci?n contenida en el presente correo es privada y confidencial entre las partes y su uso, copia, reproducci?n o distribuci?n est? expresamente prohibida.
openEHR Transition: Web-based tools?
Hi Peter! > > > Web developers can easily tackle those problems ... > > I'm afraid the word "easily" is wrong, Pablo. I've been doing mostly > web development for the last few years. I specifically mentioned those > things because they are _hard_ to do in in web development, whereas in > desktop applications they are extremely easy to do or, in the case of > session time-outs, the problem doesn't exist at all. > Of course, your point is right. I just tried to show that there are many solutions, known solutions and patterns we can use to tackle those problems down. That web is more dificult than desktop, no doubt about it. The main problem is not on those usability issues, is on that in web we have to deal with lots of levels of abstraction to reach the application level, and in desktop we only have the operating system, maybe a virtual machine, and the application above. On web based we have to deal with a server (OS, VM, application server, web server, database server, etc), we have to deal with the client (web browsers, javascript, xml, json, html, css, etc), and with all in between (sockets, http, ajax calls, soap web services, security, ...). Yeah! thats complex and dificult :D > > Just use HTML: http://en.wikipedia.org/wiki/Access_key > > This doesn't address keyboard shortcuts. Access keys are not keyboard > shortcuts. I'm sure there must be some way to do keyboard shortcuts in > a web application, because googling for "cloud9 keyboard shortcuts" > comes up with some relevant-looking results, but I really have no idea > how to achieve it. > Maybe I misunderstood the keyboard shortcuts term, I thought of a combination of keys to make focus on something on the GUI (a label or a form input). > It also doesn't address at all my question about setting focus to the > appropriate control automatically. When I open a page, I want keyboard > focus set to a sensible place, probably the top-left entry control. If > I select an item from a drop-down list, I probably want focus to > remain on that drop-down list. If there's an OK or Save button on the > page, then I should be able to click it without being forced to reach > for the mouse. Simple usability stuff that is programmed routinely > with almost no effort into a desktop app, and that is essential for me > personally, if I am to spend hours on end, day after day, using that > application. My experience of trying to get basic stuff like this > working properly in a web app is that it's doable, but with a huge > amount of effort. > > > > One way to maintain a session open is to send heartbeats using > > AJAX ... > > That's interesting. When I have a whole day free to investigate, I > might work out a way to implement this for my current project. > Hopefully that day won't turn into a week, as such things have a > tendency of doing :-( > Yep, that was a good one when I learn the concept from a networking course in my university. It's the same idea used for server monitoring: send small packets to know if something is still alive. > Anyway, this pretty well proves my point. The problem simply doesn't > exist in desktop apps, but in developing a web app you have to devote > significant time to this problem instead of working on real > functionality. These are just a few examples of the many things that I > take for granted when programming desktop apps that suddenly become > very difficult for web apps ... > I agree with you. Cheers, Pablo. > - Peter -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110911/24fd00bc/attachment.html>
