UI Update

wakie87 wrote on Thursday, April 25, 2013:

There has been a lot of talk on the forums recently regarding updating the UI for OpenEMR. This is a very large task, so I have started with updating the login page. I have included twitter bootstrap and updated the login page by removing all the frames.

Because it is based on the twitter bootstrap, depending on the device you use, it should all look the same ie: iPhone, iPad, Android, Desktop. The login page should also change depending on the orientation of the device.

I would love your feedback and hopefully get this merged into the next release

julialongtin wrote on Thursday, April 25, 2013:

Scott,

I have completed a modification of the default view of OpenEMR so that no
popups occur. This is mixed in with one of my other trees (so needs to be
sorted out), but really helps both fullscreen mode on a desltop PC, and
portable usage (ipad, ipod, android, etc). This was required to use my
default web browser (midori), which opens popups inside of new tabs,
without the ability to close them, vastly breaking the UI.

its mixed up with a bunch of stuff i’m pretty sure mainline doesn’t want,
but i’m slowly unravelling the mix.

In order to accomplish this work, i had to be really abusive with the
frames interface, doing things such as making the left navigation bar load
jquery and fancybox into the right hand frames, and forcing a fancybox to
open. I’d like to keep a very close eye on anything to do with touching the
frames interface, because while i hate them (security nightmare), i am now
trying to get code into our upstream to remove one evil (popup windows) by
leaning harder on another evil (frames).

Julia Longtin

On Thu, Apr 25, 2013 at 3:43 AM, Scott W. wakie87@users.sf.net wrote:

There has been a lot of talk on the forums recently regarding updating the
UI for OpenEMR. This is a very large task, so I have started with updating
the login page. I have included twitter bootstrap and updated the login
page by removing all the frames.

Because it is based on the twitter bootstrap, depending on the device you
use, it should all look the same ie: iPhone, iPad, Android, Desktop. The
login page should also change depending on the orientation of the device.

I would love your feedback and hopefully get this merged into the next
release

https://github.com/Wakie87/openemr/tree/bootstrapV4

UI Updatehttps://sourceforge.net/p/openemr/discussion/202506/thread/7c43fef7/?limit=25#03bc

Sent from sourceforge.net because you indicated interest in
OpenEMR / Discussion / Developers

To unsubscribe from further messages, please visit
SourceForge.net: Log In to SourceForge.net

wakie87 wrote on Thursday, April 25, 2013:

Hi Julia,

Thanks for your reply. I totally agree with you regarding the frames. Everyone I have ever shown OpenEMR too their first response is about the outdated UI including the frames and popups.

There is a lot of talk on the forums regarding the UI and removing frames but not much progress. If you compare it to other products eg. Dr Chrono, the simplicity of their UI design and the ability to use it on tablets wins hands down. I thought I would provide a starting point to help get people motivated.

Scott

yehster wrote on Thursday, April 25, 2013:

Julia,
My understanding is that you are changing on a page by page basis the popups to use fancybox instead. Is this correct?
Another approach to consider is to modify the existing library/dialog.js code to create a new iframe (what a fancybox is) instead of a popup. It might be possible to take care of all them with a single simpler change.

julialongtin wrote on Thursday, April 25, 2013:

Kevin,

short answer: I’ve done what you think, and it required much deeper changes
to how some pages call one another.

I’ve started breaking patches out of my master branch, into a ‘nopopups’
branch, on gitorious.
https://gitorious.org/~juri/openemr/juris-openemr

Julia Longtin

On Thu, Apr 25, 2013 at 1:50 PM, Kevin Yeh yehster@users.sf.net wrote:

Julia,
My understanding is that you are changing on a page by page basis the
popups to use fancybox instead. Is this correct?
Another approach to consider is to modify the existing library/dialog.js
code to create a new iframe (what a fancybox is) instead of a popup. It
might be possible to take care of all them with a single simpler change.

UI Updatehttps://sourceforge.net/p/openemr/discussion/202506/thread/7c43fef7/?limit=25#03bc/0185/2083

Sent from sourceforge.net because you indicated interest in
OpenEMR / Discussion / Developers

To unsubscribe from further messages, please visit
SourceForge.net: Log In to SourceForge.net

sunsetsystems wrote on Thursday, April 25, 2013:

That’s a good point – in any case it’s good to use a level of abstraction so that when a better tool comes along it can be more easily implemented. Or in other words: if you find yourself putting in the same code over and over, something is probably wrong.

Rod
http://www.sunsetsystems.com/

sunsetsystems wrote on Thursday, April 25, 2013:

Julia, where’s the “nopopups” branch?

deschel wrote on Thursday, April 25, 2013:

Dr Chrono is too simple.

Frames has some benefits. Although it is not the “in thing” right now, they achieve something that would be too difficult to achieve without them.

Frames allows OpenEMR to do what few other EMRs are able to do–that is to view multiple pieces of different information at the same time. For example, being able to view the progress note while looking at a message. Or, to edit a progress note while reviewing a radiology document. These are important features from the user perspective. I’ve heard other people complaining about their commercial EMRs because they could not do this.

I agree that the interface is outdated. However, it needs to be replaced with a system that keeps the same functionality (i.e. the functionality that I described).

Any thoughts about how this could be done?

Also, how about changing the left nav to a vertical menu type system?

Although appearance is important, functionality trumps appearance.

David Eschelbacher MD

yehster wrote on Thursday, April 25, 2013:

Before attempting any significant UI update of left_nav, what should happen first is better abstractions for defining the menu elements in the first place: making them data driven rather than the hard coded PHP they are today. This would be helpful not only for UI improvements/tweaks but also for customization.

mdsupport wrote on Thursday, April 25, 2013:

Would it not be better to choose from one of the open-source UI frameworks? As one walks through the code base, UI preferences of the developer/sponsor are seen rather than project standards. As the user base grows, this will become more complex for limited nbr of gatekeepers to manage. Sure, no framework will be perfect but any one of them would represent efforts of 100s of additional UI developers that are not part of this project.

The developer community for this project should concentrate on functionality - better integration and more importantly upcoming mandates for more collaboration - rather than how to build/maintain sliding menus implemented 10 different ways.

sunsetsystems wrote on Thursday, April 25, 2013:

The “should we use a framework and if so which one” debate has come up a few times before, and it gets pretty exhausting. I’ll participate in one again if someone is seriously prepared to do or sponsor the conversion effort, and fully understands what they are getting into.

Rod
http://www.sunsetsystems.com/

mdsupport wrote on Thursday, April 25, 2013:

Could not agree with Rod more regarding ‘debates’. Speaking for us, we are close to rolling out our first POC to get a feel for difference in efforts vs benefits.

yehster wrote on Thursday, April 25, 2013:

I suspect a significant problem is that the “opener” property that a popup uses to refer to it’s parent window doesn’t work with fancybox.

I’ve spent some time thinking about the popup issue too and I’m confident that there is a solution that isn’t “abusive”. I have other priorities right now, but will try to present my solution in the near future.

julialongtin wrote on Thursday, April 25, 2013:

kevin/rod:

please look through the ‘master’ branch off of my gitorious link posted
earlier.

the ‘nopopups’ branch aparently is still local, my apologies. i’ll try to
get it out as soon as possible.

‘master’ on my gtorious tree has some 18,000 lines of patch
yet-to-be-reviewed or comitted. i’m still breaking it into pieces.

I did successfully remove all of the popups on the default interface. i
haven’t gone through for the old interface, used by the athletic team code.

Julia Longtin

On Thu, Apr 25, 2013 at 8:34 PM, Kevin Yeh yehster@users.sf.net wrote:

I suspect a significant problem is that the “opener” property that a popup
uses to refer to it’s parent window doesn’t work with fancybox.

I’ve spent some time thinking about the popup issue too and I’m confident
that there is a solution that isn’t “abusive”. I have other priorities
right now, but will try to present my solution in the near future.

UI Updatehttps://sourceforge.net/p/openemr/discussion/202506/thread/7c43fef7/?limit=25#03bc/0185/2083/1845/3a5d

Sent from sourceforge.net because you indicated interest in
OpenEMR / Discussion / Developers

To unsubscribe from further messages, please visit
SourceForge.net: Log In to SourceForge.net

deschel wrote on Friday, April 26, 2013:

Creating a database table to store the menu items in left nav, and removing them from php code, would be a great start! I don’t think it would be that difficult/complicated.

That would have been a great starter project for that Google Summer of code intern that we got denied funding for.

As far as a UI framework, css already supports a lot of ability for UI customization, I’m not sure how necessary a framework is, and I think that rather than making things easier, it tends to make things more complicated.

The programmer that I had hired used twitter bootstrap, a popular UI framework, to create a couple of web pages. I liked certain elements, and others I though were no good. It was really difficult to stay with the framwork and change the simple things that I did not like. Plus, it became too complicated. In the end, it was just easier to take out the css and jquery objects of what I liked and get rid of the framework and all the useless stuff that came with it.

In the end, we just need someone to take the time to improve the UI. A framework can create ideas, and code can be borrowed from it, but in the end, its just about spending the time to improve the interface.

Unfortunately, there is so much to work on and there are other things that people put a higher priority on, and rightly so.

So, MD Support, is UI a high priority for you?

By the way, what are some of the UI frameworks that you like?

bradymiller wrote on Friday, April 26, 2013:

Hi,

Regarding migrating the menu items into the database, it’s not very tough to migrate things like this into the database. For example, we just committed code to bring the issue types settings into the codebase. But, not sure if this is actually a very good idea. Once you bring it into the database, it is not very easy to modify it to bring in new menu items by developers; for example, here’s a scenario:

  1. A developer adds a new menu item to link to a new page (such as a new report).
  2. To add this, the developer then adds the menu item via the database upgrade script.
    So, you may say, great, things are well.
    But then what happens when a user decides they don’t want they menu item any longer, so they remove it.
    But then guess what happens when a user runs the upgrade script; it then gets added back…

This same issue came up with the gacl items upgrade script and I ended up placing a mechanism that did not allow re-running previous upgrade items (works via the v_acl item in the version.php script and version sql table).

So it may make sense to create a similar type mechanism for upgrading (meaning to not allow the running of previous upgrade items); this would then also mean that a user would not even need to set a version number in the sql_upgrade script.

-brady
OpenEMR

apmuthu wrote on Friday, April 26, 2013:

Have a bool/tinyint(1) field to make the menu active / inactive.
Hence no deletion would be needed.

yehster wrote on Friday, April 26, 2013:

There are at least two reasons why I don’t think it would be better to “choose a framework” at this point

  1. Migration to a data driven menu is a task with clearly defined scope and goal. The same can’t be said for migration to a framework.

  2. The requirements gathering and analysis that results from this task will likely be useful in the process of migration to framework.

There are two requirements(A,B) of the menu system that I am certain no framework is going to support out of box, and one other© which some frameworks do support but may need some tweaking to work with how OpenEMR deals with things.
A. Different behavior based on whether a patient has been selected.
B. Different behavior based on whether an encounter has been selected.
C. Different behavior based on ACL/Permissions

We can only solve big problems by breaking them down in to smaller manageable chunks.

Please tell us more about your POC/plan. Have you chosen a particular framework? and if so, why that one?

mdsupport wrote on Friday, April 26, 2013:

Our POC deals with data access/capture in facilities and batch updates. It is client-side using Sencha’s Extjs. The choice was driven purely based on availability of licenses, support and skillset. It does not affect the server side framework needed by this project- though if this project were to choose a framework - it could potentially affect our choice…

Regarding menu, probably most frameworks will handle data/acl driven menus - Zend_navigation does. But without that debate, how about adding a variant/type flag to the menu records? Type 0 can be ‘Standard Release’ that can be changed by this project in patches/upgrades and type 1 as ‘Working Menu’ - never touched by sql scripts except at installation. The menu system uses only the working copy. Local Admin has to ability to add/change/delete working entries and copy standard records selectively or reset all working entries to standard.

tmccormi wrote on Friday, April 26, 2013:

I’ve used a similar model which is basically an override.

The base record released has ‘0’ level menu items, but the local table
can have higher versions of the same base menu item and the menu
builder uses the highest version number.

This can also make for some fancy ‘user preferences’ allowing a the
version to be a ‘menu set’ instead and some users see a different set
than others.

A higher version or set number could also include a ‘Hide Me’ flag.

Tony