Re: [Gnumed-devel] GNUmed web interface - when easy is not so easy after all

[Dave Cramer]

On Fri, Jun 25, 2010 at 1:14 PM, Sebastian Hilbert
<address@hidden> wrote:
> There is two sorts of user interfaces for FOSS EMR. There are the fat client
> applications and the web client applications.
>
> GNUmed is a fat client application. It uses wxpython and has an interface
> like many traditional software applications. That means it needs to be
> installed on a user's computer. This has pros and cons. On the positive side
> developers need to code exactly one interface. The actual rendering is left
> to the operating system and underlying GUI toolkit. However providing the
> underlying toolkit on many operating systems and window managers is no
> easy task.
>
> Then the internet era came along and brought the browser. There was one
> rendering application (the browser) and one user interface language (html).
> It turned out that was not reality. There are dozens of browsers and because
> html alone is limited along came CSS and JavaScript. But there was one very
> important detail that makes the web attractive for delivering applications.
> All you need is a browser. You do not need to install the application
> on your computer and you don't need to mess with dependencies such as
> special libraries. In the ideal world you make your application run on on
> computer (the server) and the clients (the browser) will only display the
> output and collect input to feed back to the server.
>
> Web clients have their own share of problems. Browsers are not fully
> standard compliant. For security reasons you cannot access local peripheral
> devices such as scanners, printers, files easily. That severly breaks a
> input-oriented application like an electronic medical record.
>
> People came up with all sorts of clever solutions. Thin client are fat
> clients whose output is displayed at a remote location. This does not sound
> too bad. However the data that needs to be transfered is too much for
> today's internet lines and even broadband. VNC is only usable when run in a
> highspeed local network of 100MBit/s or more. And people tried to solve that
> problem as well. They came up with the NX protocol. Pretty much a heavily
> optimized remote
> display solution. It works and it works well but the web is so prominent
> that it does not penetrate the mass market.
>
> NX solves the problems for the user. Well kind of. You still need to install
> a NX client on your computer. Then NX married the solution with the browser.
> They built the nx browser plugin. This is one solution to the problem.
> However the nx client needs to be available for every
> platform and every device (ARM, x86, your favorite operating system here).
> It is not. But the web is. Virtually every device that looks like an
> electronic device can run a browser. Even the washing machine and the
> microwave oven have Android installed. Anywhere there is a browser
> there is chance to deliver the application.
>
> Does GNUmed need a webinterface. I don't think so. However people are made
> to believe that the personal computer will go away in 2-5 years. Along with
> it there is a chance that fat clients will go away. That would make the
> GNUmed client we have today go away. The doctor does not care. She just
> wants it to work not matter what technology. Lets just say GNUmed needs a
> web interface. Apart from the fact that then GNUmed team does not yet have
> anyone with the skills needed to make this a success it is always a good
> idea to look at what others have done so far.
>
> Web interface definition
> There is two types of web interfaces. One is the traditional mix of HMTL
> pages maybe with a bit of CSS for beatification and some Javascript to make
> it look. The other one is a so called RIA (rich internet application). This
> is what Gmail and friends think a web application should work and look like.
> Because the mix of browsers and OSs is such as PITA frameworks have been
> created.
> Those frameworks try to abstract the pitfalls from the developer and try to
> offer a cross-browser and cross-platform user interface developement
> solution. This has been benefical but developers tend to push the boundries.
> This lead to countless approaches and frameworks. Many of those target
> Javascript developers (extJS, dojo, qooxdoo, YUI, jQuery). Then Google came
> along and
> brought GWT which let developers develop in JAVA instead of pure JavaScript.
> This however means you need to program in JAVA or at least php.
>
> Choosing the right tools
> Over the years it became evident that developers seldomly have design
> skills.
> Application design was pushed down on the agenda and a few webpages were
> created to for the EMR user interface. Pretty soon everyone noticed that
> those "applications" are a  nightmare to develop, maintain, translate and
> debug. Users broke them all the time. Not because users are stupid but
> because they are busy and impatient. The result is what openEMR, Oscar and
> Freemed (up to 0.8.4) look like today. Design says little about how well an
> application works but users tend to associate the quality of an application
> with its design.
>
> Road to redesign
> Nearly all projects I followed over the years have either done a complete
> user rewrite or plan to do so. Freemed has been picked up but even the
> rewrite is under rewrite. They tried Dojo but that did not work so they
> switched to GWT. The web application now works as a mix of three languages
> (php, javascript, JAVA). The interface looks promising and I hope they will
> pull this off. OpenEMR is currently getting certified in the US. I wonder
> how long it takes before the UI will be rewritten.
>
> Back to GNUmed.
> While the appearance of openEMR and freemed might be lacking GNUmed
> is not there yet. It has recently been demonstrated that the GNUmed backend
> and middleware (connection to the database etc.) can be reused without much
> effort in a webbrowser. The only thing missing it the graphical user
> interface. It is not as easy as it soundy. Careful planning is indicated to
> avoid starting over a few months down the road. A python based
> web application usually uses a python web framework anlong with some
> template manager. For python there is at least pylons, django, turbogears,
> cherrypy. These frameworks try to be complete solutions. They bring
> everything to the table including database access. But we don't want that.
> So the question arises do we need a python framework ? Given my little
> knowledge I am not sure about that. Next question is on the user interface
> framework. Do we
> need a Javascript framework like extJS , GWT , qooxdoo and friends. I am
> starting to believe we could use one of those although I am not sure how to
> marry this to our middleware. The point is unless you have a very
> experienced web application developer in the team chances are this gets
> screwed up and wastes time.
>
> Pyjamas to the rescue.
> A group of people thought what GWT is to JAVA GWT can be to Python as well.
> They came up with pyjamas. The ideas is to develop in python and the
> python-to-javascript compiler will translate this to well JavaScript.
> JavaScript is the only language browsers understand. There is documentation
> on this and it is supposedly relatively compatible to GWT. I lack the
> insight to judge how well this works. The potential benefit is a closer tie
> to the python middleware. A potential drawback is that you need a python
> coder to do the job. This will leave out all web developers which are only
> fluent in JavaScript. And those are the majority I would guess.
>
> Performance considerations
> While reading up a lot on web application developement I noticed there are a
> number of ways to solve the problem. There is no best of practice and
> depending on what you wanna do opinions differ. It boils down to where to do
> the heavy lifting. One end of the rope is creating all (x)HTML on the server
> and serving that to the client. The other end is letting the client to all
> the HTML,JS,DOM work.  Since I know too little on this here is an article
> which talks about it.
>
> Long story short
> Doing a web interface is easy. Just start and learn along the way. The same
> attitude is inherent in some of the FOSS EMR both with web clients and fat
> clients. While it works it certainly is a pain if you ever want to hand over
> the code to another developer.
>
> What are the options.
> One could look into pyjamas and try to make the most of it. Or one could
> just learn JS and go for extJS and friends. I guess no option would be to
> use pure GWT since there needs to be a bridge between python and JAVA
> (Jython maybe?). One could also just do away with the RIA as a whole and
> serve a few static or partly dynamic webpages.
>
> I would really welcome some comments here. As I said I am totally new to
> this. However if this is not properly planned it is better to leave this
> out. And who knows how the internet will develop. There might just be
> wxwidgets to javascript mapping appearing.
>
> Best regards,
>
> Sebastian
>


Since GWT is really only the java->javascript part, you can still use
GWT on top of a python backend. It communicates via JSON to the
backend.

I'd strongly suggest using GWT, or some other javascript framework.
GWT gets around all those nasty javascript incompatibilities between
browsers

Dave
> _______________________________________________
> Gnumed-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnumed-devel
>
>