# openEHR Transition: Web-based tools?
**URL:** https://discourse.openehr.org/t/openehr-transition-web-based-tools/15086
**Category:** Technical (archive)
**Created:** [9 September 2011 15:10 UTC](https://discourse.openehr.org/t/openehr-transition-web-based-tools/15086 "2011-09-09T15:10:10Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@ian.mcnicoll](https://discourse.openehr.org/u/ian.mcnicoll)
#### Post date: [9 September 2011 15:10 UTC](https://discourse.openehr.org/t/openehr-transition-web-based-tools/15086/1 "2011-09-09T15:10:10Z")
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@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
---
### Author:  [@system](https://discourse.openehr.org/u/system)
#### Post date: [9 September 2011 16:53 UTC](https://discourse.openehr.org/t/openehr-transition-web-based-tools/15086/2 "2011-09-09T16:53:15Z")
Hi Ian
My interest is the pain we get as the tools get developed and tweaked as does ADL and multiple versions.
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.
Finally, web tools are easier to access on multiple devices including mobile.
Cheers San
---
### Author:  [@Seref](https://discourse.openehr.org/u/Seref)
#### Post date: [10 September 2011 11:55 UTC](https://discourse.openehr.org/t/openehr-transition-web-based-tools/15086/3 "2011-09-10T11:55:58Z")
Hi Ian,
You are raising concerns from a tool user perspective, and anything
related to your user experience IMHO belongs to another discussion.
Web based applications are not there because they are supposed to be
collaboration hubs. The recent explosion (and in a way, a bubble) of
social networking may give that impression, but web apps are also
about easy deployment and management.
These two key aspects of software become extremely important
especially in small development teams. 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. Even with a limited amount of people doing
something such as developing archetypes, support quickly gets out of
control.
If you can match a desktop application using a web application, you
almost always win the competition (from the supply side of view).
Given the state we are in, I'd still choose web based apps.
Kind regards
Seref
---
### Author:  [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [10 September 2011 12:35 UTC](https://discourse.openehr.org/t/openehr-transition-web-based-tools/15086/4 "2011-09-10T12:35:23Z")
> ```auto
> Hi Ian
>
> 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.
> ```auto
> 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. Which ‘layers’ are you referring to?
> ```auto
>
> 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. The time may well come when this happens, which would in theory be nicer in terms of tool distribution and updating. But it is not as simple as you think:
- the individual workspace / common repository / check-in & check-out model never disappears, it can only be made less obvious
- individuals make choices to do with tools themselves -
- which version to stay on,
- plug-ins,
- tool configuration, e.g. views, colours, accessibility,
- integration with other tools
All of this has to live in some individual-specific place, which could be on the web. Maybe.
So actually while one aspect of distribution is reduced, others get more complicated. Examples of the distribution problem being solved very elegantly and cleanly: Debian apt-get (takes care of all dependency checking and compatiblity) and Mozilla FireFox (remember it’s on your desktop, not on the web - its how you get to the web!).
- thomas
---
### Author:  [@Peter\_Gummer1](https://discourse.openehr.org/u/Peter_Gummer1)
#### Post date: [10 September 2011 13:18 UTC](https://discourse.openehr.org/t/openehr-transition-web-based-tools/15086/5 "2011-09-10T13:18:13Z")
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
---
### Author:  [@pablo](https://discourse.openehr.org/u/pablo)
#### Post date: [10 September 2011 17:31 UTC](https://discourse.openehr.org/t/openehr-transition-web-based-tools/15086/6 "2011-09-10T17:31:39Z")
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…
---
### Author:  [@lavanian](https://discourse.openehr.org/u/lavanian)
#### Post date: [11 September 2011 01:25 UTC](https://discourse.openehr.org/t/openehr-transition-web-based-tools/15086/7 "2011-09-11T01:25:06Z")
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](http://www.hcitconsultant.com)
Visit [www.medhelp247.com](http://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
---
### Author:  [@system](https://discourse.openehr.org/u/system)
#### Post date: [11 September 2011 05:46 UTC](https://discourse.openehr.org/t/openehr-transition-web-based-tools/15086/8 "2011-09-11T05:46:04Z")
Hi Tom
```auto
```
```auto
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._**
```auto
```
```auto
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._**
```auto
```
```auto
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
---
### Author:  [@ian.mcnicoll](https://discourse.openehr.org/u/ian.mcnicoll)
#### Post date: [11 September 2011 08:38 UTC](https://discourse.openehr.org/t/openehr-transition-web-based-tools/15086/9 "2011-09-11T08:38:05Z")
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@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
---
### Author:  [@Seref](https://discourse.openehr.org/u/Seref)
#### Post date: [11 September 2011 10:21 UTC](https://discourse.openehr.org/t/openehr-transition-web-based-tools/15086/10 "2011-09-11T10:21:27Z")
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
---
### Author:  [@ian.mcnicoll](https://discourse.openehr.org/u/ian.mcnicoll)
#### Post date: [11 September 2011 10:45 UTC](https://discourse.openehr.org/t/openehr-transition-web-based-tools/15086/11 "2011-09-11T10:45:28Z")
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@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
---
### Author:  [@Peter\_Gummer1](https://discourse.openehr.org/u/Peter_Gummer1)
#### Post date: [11 September 2011 12:50 UTC](https://discourse.openehr.org/t/openehr-transition-web-based-tools/15086/12 "2011-09-11T12:50:33Z")
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
---
### Author:  [@system](https://discourse.openehr.org/u/system)
#### Post date: [11 September 2011 13:23 UTC](https://discourse.openehr.org/t/openehr-transition-web-based-tools/15086/13 "2011-09-11T13:23:14Z")
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://c9.io/)
[http://ace.ajax.org/](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@liu.se [http://www.imt.liu.se/~erisu/](http://www.imt.liu.se/~erisu/) Tel: +46-13-286733
---
### Author:  [@Peter\_Gummer1](https://discourse.openehr.org/u/Peter_Gummer1)
#### Post date: [11 September 2011 13:41 UTC](https://discourse.openehr.org/t/openehr-transition-web-based-tools/15086/14 "2011-09-11T13:41:54Z")
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
---
### Author:  [@ian.mcnicoll](https://discourse.openehr.org/u/ian.mcnicoll)
#### Post date: [11 September 2011 14:52 UTC](https://discourse.openehr.org/t/openehr-transition-web-based-tools/15086/15 "2011-09-11T14:52:58Z")
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](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@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
---
### Author:  [@pablo](https://discourse.openehr.org/u/pablo)
#### Post date: [11 September 2011 15:23 UTC](https://discourse.openehr.org/t/openehr-transition-web-based-tools/15086/16 "2011-09-11T15:23:42Z")
Hi Ian,
As I said before: we build web apps because we are web developers. That doesn’t mean that web oriented is better than desktop oriented, it depends on the kind of tool you are building.
For an editor, maybe desktop is ok. But if you want an editor on the cloud, is ok too ([http://phpanywhere.net/](http://phpanywhere.net/)). For shared repositores, I think web-based ans with web services (SOAP or REST) is mandatory.
I don’t think this discussion about web based vs desktop is in the right direction, I prefer to pay atention to our tool chain, and see what approach is best for each link, e.g.: we could have a perfectly integrated ecosystem with the best of both approaches:
archetype editor: desktop based
(GUI) template editor: desktop based
artefact repository: web based
EHR backend: desktop based
EHR frontend: web based
I think our (GUI) template editor will be opensourced soon. I’ll let you know.
---
### Author:  [@pablo](https://discourse.openehr.org/u/pablo)
#### Post date: [11 September 2011 16:07 UTC](https://discourse.openehr.org/t/openehr-transition-web-based-tools/15086/17 "2011-09-11T16:07:11Z")
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](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\_(programming)](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/](http://www.w3.org/)
---
### Author:  [@Peter\_Gummer1](https://discourse.openehr.org/u/Peter_Gummer1)
#### Post date: [11 September 2011 23:27 UTC](https://discourse.openehr.org/t/openehr-transition-web-based-tools/15086/18 "2011-09-11T23:27:47Z")
Pablo Pazos wrote:
> 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.
> Just use HTML: [http://en.wikipedia.org/wiki/Access\_key](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.
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 ☹
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 ...
- Peter
---
### Author:  [@pablo](https://discourse.openehr.org/u/pablo)
#### Post date: [12 September 2011 02:40 UTC](https://discourse.openehr.org/t/openehr-transition-web-based-tools/15086/19 "2011-09-12T02:40:57Z")
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 😃
> > Just use HTML: [http://en.wikipedia.org/wiki/Access\_key](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.
---
### Author:  [@Seref](https://discourse.openehr.org/u/Seref)
#### Post date: [12 September 2011 10:30 UTC](https://discourse.openehr.org/t/openehr-transition-web-based-tools/15086/20 "2011-09-12T10:30:47Z")
Ian,
This is exactly the reason I've been using Flex. Flex 3.5 requires
Flash player 9, which is 6 years old. Runs without an issue in IE 6,
gives me more power than the HTML 5 frameworks etc etc.
Naming technologies is dangerous due to possibility of spontaneous
flame wars, but what I've been describing is the reason I've had to
use Flex. (and don't even get me started on HTML 5)
[Next page](https://discourse.openehr.org/t/openehr-transition-web-based-tools/15086.md?page=2)