I’m new to the project, and you’ll likely [hopefully] be hearing more from myself and my developers. We’re working with a client on OpenEMR, and so-far, so-good.
Our major gripe at the moment [I’m sorry if this affects / offends anyone] is the GUI. It feels … thrown together. I stuck a new user in front of it today, and they were totally lost. Links don’t always behave like links (often they behave like buttons), pages have forms on them that have different submit buttons that have nothing to do with each other [ie, the add user page has about 5 different forms], and it’s possible to run yourself into a corner where the only option (other than closing the browser window) is to press back … and then you get a lovely message about re-POSTing your page.
Another thing (we quit counting the GUI “quirks”) that was very interesting was adding codes from the SuperBill to an encounter. You can click on a code, but it doesn’t show you any confirmation that it worked, or not.
I’m no GUI wizard, but I would think that some significant revisions to the GUI would be in order. Anything currently planned?
Regarding the SuperBill: look for the flicker of the screen that indicates the page reloaded as a result of successfully clicking on a code
Seriously, I don’t really have a problem with most of the interface, but that’s probably just because I’m used to it now.
Maybe we need a formal bug reporting system so specific bugs can be documented and addressed.
Also, as we have discussed before, alternative interfaces that have only the database and program structure in common with OpenEMR would be good, possibly using a modern web framework.
We agree that the GUI has short comings. The guidance committee (Rod Roark, Andres Paglayan, Tekkno Genius, Peter Walter and myself) have been dicussing this for some time. While it is easy to use after some training it doesn’t always come across that way to untrained/new users. This has interfered with the adoption of OpenEMR by new users/clients/practices.
We are planning a rewrite of the GUI at this time and these troublesome issues for new users need to smoothed out.
Your input is very welcome.
Do you have the resources and desire to help work on a new GUI?
I potentially have resources and/or desire to help work on the GUI. As everyone’s aware, it’s easier if a client funds some of the work. We’ve currently got one clinic that we’ll be hosting their OpenEMR at our facilities, and are looking at possibilities to acquire one or two clients in this vertical.
That may provide enough income in this industry / vertical (for my company) to warrant moving a developer to work on the GUI / other features. (We’ve used this tactic in the past to get code into some other OS projects, like OSWorkflow and Sequoia).
Not to be a language purist – but we’re traditionally a Javascript/AJAX/Java/Ruby shop. I quit developing (and enforced this company-wide) in PHP when PHP4 came out in 2000, and Java jumped miles ahead of them (whether or not that’s still true is a matter of debate).
I’m not sure how excited I am about working on the GUI in a language that we prefer to stay away from :-) [Cross-training developers in multiple languages usually means incurring significant costs.]
I can only assume that PHP is here to stay?
What would the guidance committee think about any kind of a Java / Ruby “fork”? Note – I haven’t given this a lot of thought, but my partner and I have discussed “significant development” on this project as a possibility, given that we acquire about four more clinics / docs to support.
Can someone enlighten me about Project Phoenix / ADC? I’ll readily admit that I don’t [yet] know enough about the existing “players” to make any sort of grand sweeping decisions yet.
Many, perhaps most developers have strong feelings about programming languages. In my view that’s not a very good reason to fork a project. The current team has decided to stick with PHP.
That said, open source is all about scratching your own itch. If using Java and/or Ruby inspires you to reach great heights, I’d say go for it. Passion is what drives exceptional projects!
I know this is a super old post, but I have some suggestions about the GUI too.
I had downloaded the OpenEMR v3.2, well done guys, impressive software.
Now, I don’t know how flexible you are about integrating other Open Source software into your code. I had used ExtJS Gui Framework for other projects, this framework has a Open Source license and Commercial license , since this project is Open Source the developers can use this framework to do all the GUI job, is like adding more developers to the project.
The license says, if the project is Open Source you can use the software for free as long the project stays Open Source.
Like you, I’am a software developer I would like to contribute to the project.
jQuery is a JavaScript Library to handle HTML transversing. ExtJS is a complete framework of GUI tools like:
* Data Grid
* Tabs
* Charts
* Toolbox
ect…
ExtJS takes care of the GUI and you take care of the logic of the OpenEMR.
This kind of discussion is good. But we’re going to need more convincing than this to switch to another javascript library. There are GUI tools built on jquery, such as the tab control and tree menus already in OpenEMR. Maybe Ext JS is better, but a quick Google search of “Ext JS vs jQuery” did not tell me that the world is beating a path to its door. Let’s continue to evaluate and experiment with various alternatives.
All I say is that jQuery is a very complete library, if you want to do dynamic content and other nice HTML, CCS transitions. In jQuery you have to create your own layout, ExtJS already has all this layouts (Tabs, Grids, ComboBox, ect).
I think by comparing them, is a mistake. The two libraries are for different purposes, maybe reading the documentation of the libraries you will notice the difference
I understand that Ext JS is a GUI framework and jQuery is just a javascript library. The point is that jQuery is also used as a foundation for higher level GUI tools (some of which we already use), and in that sense comparison is valid.
Understood, but I think is much wiser working on a GUI Framework already created and tested.
The OpenEMR developers can concentrate on the logic of the product, not on the GUI itself, with that in mind
the development could be much faster.
And of course the application will turn into a EYE Candy.
FUNNY, I’m working on that right now.
I just downloaded the 4.0 branch, and looking on how will be the best way to incorporate ExtJS into the code,
without messing the original code.
When I have something nice show, I will post-it here.
For the demo remember to use the most recent cvs(devel tip)/github(master branch) version of code (this is gonna be our 4.0 release). The daily development tip demo can be found here: http://www.openmedsoftware.org/wiki/Development_Demo
IIf you know git, I’d suggest using our official mirror on github to create your software branch off. Then it’s very easy for us to test/review it. Or can put the patch in our code review tracker here.
I’d suggest picking a simple page that hasn’t been “touched” by the new gui refactoring to make it more simple for your demo script(s); such as the immunization page.
From that, we can get an idea of how feasible it would be and how well it would work with other features (internationalization etc.).
I have some screen shots, working with OpenEMR v4.0 Dev and Sansha Framework (formerly Ext JS).
Not everyone is an expert in JavaScript so, I had to find some Wrapper for Sansha, so I had found one. The library has a very small foot print and is compatible with all versions of Sansha. The purpose of using this wrapper, was to keep the all development in PHP, not JavaScript.
