This is still a work in progress, the fundamentals are all there, but some details are still left.
One general goal was to get this working with as few changes to existing files as possible. However, there was one place where many old files needed to get updated in order for this to work.
Instead of opening a new separate browser window for dialog boxes, the "dlgopen" function has been modified to use an iframe. (This fixes a display issue that happens a lot on tablet/mobile, and also on multi screen...) However, in order to accomplish this, all the php files which are the target of dlgopen need some additional code to handle "opener" and "window.close"
The mechanism to restrict menu items based on ACL and global settings is present, but all the "data" as to which items have which restrictions hasn't been transfered to the new model yet.
Speaking of which, the menu in addition to being at the top of the screen, is also data driven.
This is currently a hard coded JSON string (built up programatically with some javascript code based on the existing left_nav.php).
The menu will move to the database in the future, which will allow for the ability to better present different versions of the menu for different roles.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Interesting! I see a lot of promise here. Could you write up something about the framework/methods used and how the code is organized? It will be important for other developers to grasp it quickly. For example the git tutorials that Brady wrote up are an ongoing valuable resource.
Rod
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I will provide more formal details once the code is closer to finalized.
In the near term, almost all of the relevant code is organized in the subdirectory interface/main/tabs
One key design component is a javascript object on the top window named left_nav which handles things the old left nav frame used to. Rather than directly updating html elements, javascript objects in the view model are updated when the existing calls like setpatient, setencounter are called from existing pages.
knockoutjs is used for the presentation layer.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Forgot to mention a new very subtle, but potentially quite useful new feature.
When looking at the past encounters list at the top, clicking the review button for an encounter will show the forms for that encounter in a new tab read-only. If there is already a selected encounter it won't be changed. This way one can review old notes easier while working on the current encounter.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is great evolutionary approach without rocking the current codebase.
We have struggled to make effective use of browser real estate. From that perspective, can you consider an UI approach where :
Menu becomes single button like Windows or mobile devices. Clicking on menu provides a full page pop up that shows one-click access to most of the menu items. Objective of navigation in two clicks is still maintained but during normal work, menu does not consume the real estate on screen.
Tabs move to current top line (used by menu).
Tab can be considered to be collection of frames. For example, top frame (active patient+encounter information) a report tab has little utility when viewing a report. So in tab construction we can either exclude or add "display:none;" since with this layout, user can go to patient related tab with a single click.
It would be awesome if clinicians can work on several forms in multiple tabs at the same time. Currently providers spend lot of time in "open a form (form1), need to look up forrm2 (e.g. vitals) so save form1, open form2, close form2 and open form1 or form3" type of cycles - all because of frame limitation..
Thank you for sharing.
Last edit: MD Support 2016-02-12
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The menu appearance is driven primarily by CSS, so a mobile specifc version would not be too difficult. It's probably possible to leverage an existing mobile menu framework.
Item 4 is something that was always in mind. The appropriate UI for when to open in an existing tab vs in a new tab is not immediately obvious, also need to make sure that the same form doesn't get opened in multiple tabs. If a read-only view of other forms is sufficient, the "encounter review" feature can be used to review the current encounter too.
There are lots of potential ways to group tabs for item 3, and the possible combinations could get big and unmanagable very quickly. The "lock display" feature requires a lot more effort on the users' part, but at least it's possible to do what you want manually for now.
There is obviously a lot more that can be done with this. It's just the beginning.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Another potential when moving to database driven menus would be enhance 'registry' and expand its use to be single source of active components within application. This will let installations have menus responsive to feature activation status. Then we could have 1000 reports but a practice show only some to specific roles.
Last edit: MD Support 2016-02-12
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Updated version of the code.
Merged with current development tip
Bug fix for when the menu data isn't loaded into the database (falls back to hard coded options).
Menu option to return to old frames based interface (Click on user name).
Also, although being able to go back to frames is neat, would it make sense to do this in a way to avoid redundant menu structures (ie. have left_nave use the json menu) or just completely removes the old frames view altogether?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Removing the old frames view is the ultimate goal. However, the intention with having both in the meantime is that if there are bugs in the new menu and items are unreachable, the old menu is available as fallback.
It's a temporary solution to ease issues during a transition.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
A couple things that throw me off when using it; how does it decide when to make a new tab or overwrite an existing tab. Also, it appears the Calendar and Patient Flow tab always overwrite each other(ie. they can not coexist as separate tabs).
-brady
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Every entry has a target, since calendar and flow board have the same target, they both go to the same tab. Could be overriden in the database if desired.
There's a fixed set of "defined" targets. Not all of them neccessarily exist from the start.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The above commits should be ready to go into the codebase now and since it's easy to switch between the tabs and old layout, we can then work out bugs etc. in tabs layout as it gets more use over time. I placed information on the Active Projects page with the plan: http://www.open-emr.org/wiki/index.php/Active_Projects#Frame_Removal
It is quite unprofessional that the commits only have attribution to me in the comments and not the commits themselves and also for you to add a copyright and licensing statements to the files of mine which are original.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have sent you several emails and github posts regarding this project with no reply(unprofessional??). I was under the assumption that your interest in this had gone stale. Now that you are actually replying, I can easily make you the author of these commits if you wish and I can change the copyrights(do note that all the copyright and author info in all the new files have been assigned to you) to whatever you wish (I pulled it from a GPL repo, so I am safe to assume that it was GPL'd, correct?). I have made changes, but I don't care about attribution; I just care about getting this into proper shape to get it into the codebase before I am using a walker...
Demo Site
http://54.85.131.85/openemr
Code
https://github.com/yehster/openemr/tree/iframe-alpha1
This is still a work in progress, the fundamentals are all there, but some details are still left.
One general goal was to get this working with as few changes to existing files as possible. However, there was one place where many old files needed to get updated in order for this to work.
Instead of opening a new separate browser window for dialog boxes, the "dlgopen" function has been modified to use an iframe. (This fixes a display issue that happens a lot on tablet/mobile, and also on multi screen...) However, in order to accomplish this, all the php files which are the target of dlgopen need some additional code to handle "opener" and "window.close"
The mechanism to restrict menu items based on ACL and global settings is present, but all the "data" as to which items have which restrictions hasn't been transfered to the new model yet.
Speaking of which, the menu in addition to being at the top of the screen, is also data driven.
https://github.com/yehster/openemr/blob/iframe-alpha1/interface/main/tabs/menu/menu_data.php
This is currently a hard coded JSON string (built up programatically with some javascript code based on the existing left_nav.php).
The menu will move to the database in the future, which will allow for the ability to better present different versions of the menu for different roles.
Interesting! I see a lot of promise here. Could you write up something about the framework/methods used and how the code is organized? It will be important for other developers to grasp it quickly. For example the git tutorials that Brady wrote up are an ongoing valuable resource.
Rod
I will provide more formal details once the code is closer to finalized.
In the near term, almost all of the relevant code is organized in the subdirectory interface/main/tabs
One key design component is a javascript object on the top window named left_nav which handles things the old left nav frame used to. Rather than directly updating html elements, javascript objects in the view model are updated when the existing calls like setpatient, setencounter are called from existing pages.
knockoutjs is used for the presentation layer.
Looks good I like the ability to lock a screen and then bring up a second screen vertically. Impresive.
Terry
Once again Kevin, you rock.
Forgot to mention a new very subtle, but potentially quite useful new feature.
When looking at the past encounters list at the top, clicking the review button for an encounter will show the forms for that encounter in a new tab read-only. If there is already a selected encounter it won't be changed. This way one can review old notes easier while working on the current encounter.
This is great evolutionary approach without rocking the current codebase.
We have struggled to make effective use of browser real estate. From that perspective, can you consider an UI approach where :
Thank you for sharing.
Last edit: MD Support 2016-02-12
Pretty sure you can figure out how to do #2 (move the tabs) based on the code here
https://github.com/yehster/openemr/blob/iframe-alpha1/interface/main/tabs/main.php#L77
The menu appearance is driven primarily by CSS, so a mobile specifc version would not be too difficult. It's probably possible to leverage an existing mobile menu framework.
Item 4 is something that was always in mind. The appropriate UI for when to open in an existing tab vs in a new tab is not immediately obvious, also need to make sure that the same form doesn't get opened in multiple tabs. If a read-only view of other forms is sufficient, the "encounter review" feature can be used to review the current encounter too.
There are lots of potential ways to group tabs for item 3, and the possible combinations could get big and unmanagable very quickly. The "lock display" feature requires a lot more effort on the users' part, but at least it's possible to do what you want manually for now.
There is obviously a lot more that can be done with this. It's just the beginning.
Another potential when moving to database driven menus would be enhance 'registry' and expand its use to be single source of active components within application. This will let installations have menus responsive to feature activation status. Then we could have 1000 reports but a practice show only some to specific roles.
Last edit: MD Support 2016-02-12
Updated version of the code.
Merged with current development tip
Bug fix for when the menu data isn't loaded into the database (falls back to hard coded options).
Menu option to return to old frames based interface (Click on user name).
https://github.com/yehster/openemr/tree/iframe-alpha4
Looks promising. IFRAMES + Bootstrap classes is promising.
just a big wow on the testing; amazing that can go back to the frames also.
I set up demo from your branch here, so everybody can be wowed:
http://www.open-emr.org/wiki/index.php/Development_Demo#192.168.1.134
I guess a big question is which mechanism of menu data to mainly support. The hard-coded one or the database?
-brady
OpenEMR
Database only eventually. JSON mechanism is there primarily for development purposes.
Also, although being able to go back to frames is neat, would it make sense to do this in a way to avoid redundant menu structures (ie. have left_nave use the json menu) or just completely removes the old frames view altogether?
Removing the old frames view is the ultimate goal. However, the intention with having both in the meantime is that if there are bugs in the new menu and items are unreachable, the old menu is available as fallback.
It's a temporary solution to ease issues during a transition.
Hi,
A couple things that throw me off when using it; how does it decide when to make a new tab or overwrite an existing tab. Also, it appears the Calendar and Patient Flow tab always overwrite each other(ie. they can not coexist as separate tabs).
-brady
An excerpt from the json:
"label\":\"Calendar\",\"menu_id\":\"cal0\",\"target\":\"lst\",\"url\":\"/interface/main/main_info.php\",\"children\":[],\"requirement\":0},{\"label\":\"Flow Board\",\"menu_id\":\"pfb0\",\"target\":\"lst\",\"url\":\"/interface/patient_tracker/patient_tracker.php?skip_timeout_reset=1\",\"children\":[]
Every entry has a target, since calendar and flow board have the same target, they both go to the same tab. Could be overriden in the database if desired.
There's a fixed set of "defined" targets. Not all of them neccessarily exist from the start.
Also noted several things are missing like the search stuff from left_nav and the popups section.
Wow-wow also. A major change to the look and feel of OpenEMR. I like it and hope it gets support votes from regular users in US.
Kevin, my hat is off to you!
Wow is not near the word we should be using.
Awe struck, dum-founded, knocked my socks off and more.
Hi,
In order to get this project into the codebase as soon as possible, did the following( on branch: https://github.com/bradymiller/openemr/commits/rebase-master-iframe-dev-5 ):
1.Commit to bring in the third party packages via bower:
(removed until sort out copyright/licensing)
2.Commit that modified the code to work with current codebase:
(removed until sort out copyright/licensing)
The Tabs layout can be turned on/off at Adminstration->Appearance->'Tabs Layout Style'.
Demo is here:
http://www.open-emr.org/wiki/index.php/Development_Demo#192.168.1.134
The above commits should be ready to go into the codebase now and since it's easy to switch between the tabs and old layout, we can then work out bugs etc. in tabs layout as it gets more use over time. I placed information on the Active Projects page with the plan:
http://www.open-emr.org/wiki/index.php/Active_Projects#Frame_Removal
-brady
OpenEMR
Last edit: Brady Miller 2016-07-23
It is quite unprofessional that the commits only have attribution to me in the comments and not the commits themselves and also for you to add a copyright and licensing statements to the files of mine which are original.
Hi Kevin,
I have sent you several emails and github posts regarding this project with no reply(unprofessional??). I was under the assumption that your interest in this had gone stale. Now that you are actually replying, I can easily make you the author of these commits if you wish and I can change the copyrights(do note that all the copyright and author info in all the new files have been assigned to you) to whatever you wish (I pulled it from a GPL repo, so I am safe to assume that it was GPL'd, correct?). I have made changes, but I don't care about attribution; I just care about getting this into proper shape to get it into the codebase before I am using a walker...
thanks,
-brady
OpenEMR
Last edit: Brady Miller 2016-07-23
Hi Kevin,
I will delete the above branches from github for now until the copyright/license is to your satisfaction.
(I also removed the commit links above)
thanks,
-brady
OpenEMR
Last edit: Brady Miller 2016-07-23
It may be better to standardize on a single icons library (typicons, font-awesome, ???) to provide uniform look and feel.