Tabs Based interface with IFRAMES

system · February 11, 2016, 10:18pm

yehster wrote on Thursday, February 11, 2016:

Code

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.

github.com

yehster/openemr/blob/iframe-alpha1/interface/main/tabs/menu/menu_data.php

<?php

$menu_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\":[],\"requirement\":0},{\"label\":\"Messages \",\"menu_id\":\"msg0\",\"target\":\"pat\",\"url\":\"/interface/main/messages/messages.php?form_active=1\",\"children\":[],\"requirement\":0},{\"label\":\"Patient/Client\",\"menu_id\":\"patimg\",\"children\":[{\"label\":\"Patients\",\"menu_id\":\"fin0\",\"target\":\"lst\",\"url\":\"/interface/main/finder/dynamic_finder.php\",\"children\":[],\"requirement\":0},{\"label\":\"New/Search\",\"menu_id\":\"new0\",\"target\":\"pat\",\"url\":\"/interface/new/new.php\",\"children\":[],\"requirement\":0},{\"label\":\"Summary\",\"menu_id\":\"dem1\",\"target\":\"pat\",\"url\":\"/interface/patient_file/summary/demographics.php\",\"children\":[],\"requirement\":1},{\"label\":\"Visits\",\"children\":[{\"label\":\"Create Visit\",\"menu_id\":\"nen1\",\"target\":\"enc\",\"url\":\"/interface/forms/newpatient/new.php?autoloaded=1&calenc=\",\"children\":[],\"requirement\":1},{\"label\":\"Current\",\"menu_id\":\"enc2\",\"target\":\"enc\",\"url\":\"/interface/patient_file/encounter/encounter_top.php\",\"children\":[],\"requirement\":2},{\"label\":\"Visit History\",\"menu_id\":\"ens1\",\"target\":\"enc\",\"url\":\"/interface/patient_file/history/encounters.php\",\"children\":[],\"requirement\":1}],\"requirement\":0},{\"label\":\"Records\",\"children\":[{\"label\":\"Patient Record Request\",\"menu_id\":\"prq1\",\"target\":\"enc\",\"url\":\"/interface/patient_file/transaction/record_request.php\",\"children\":[],\"requirement\":1}],\"requirement\":0},{\"label\":\"Visit Forms\",\"children\":[],\"requirement\":0},{\"label\":\"Import\",\"children\":[{\"label\":\"Upload\",\"menu_id\":\"ccr0\",\"target\":\"pat\",\"url\":\"/interface/patient_file/ccr_import.php\",\"children\":[],\"requirement\":0},{\"label\":\"Pending Approval\",\"menu_id\":\"apr0\",\"target\":\"pat\",\"url\":\"/interface/patient_file/ccr_pending_approval.php\",\"children\":[],\"requirement\":0}],\"requirement\":0}],\"requirement\":0},{\"label\":\"Fees\",\"menu_id\":\"feeimg\",\"children\":[{\"label\":\"Fee Sheet\",\"menu_id\":\"cod2\",\"target\":\"enc\",\"url\":\"/interface/patient_file/encounter/load_form.php?formname=fee_sheet\",\"children\":[],\"requirement\":2},{\"label\":\"Payment\",\"menu_id\":\"pay1\",\"target\":\"enc\",\"url\":\"/interface/patient_file/front_payment.php\",\"children\":[],\"requirement\":1},{\"label\":\"Checkout\",\"menu_id\":\"bil1\",\"target\":\"enc\",\"url\":\"/interface/patient_file/pos_checkout.php?framed=1\",\"children\":[],\"requirement\":1},{\"label\":\"Billing\",\"menu_id\":\"bil0\",\"target\":\"pat\",\"url\":\"/interface/billing/billing_report.php\",\"children\":[],\"requirement\":0},{\"label\":\"Batch Payments\",\"menu_id\":\"npa0\",\"target\":\"pat\",\"url\":\"/interface/billing/new_payment.php\",\"children\":[],\"requirement\":0},{\"label\":\"EDI History\",\"menu_id\":\"edi0\",\"target\":\"pat\",\"url\":\"/interface/billing/edih_view.php\",\"children\":[],\"requirement\":0}],\"requirement\":0},{\"label\":\"Modules\",\"menu_id\":\"modimg\",\"children\":[{\"label\":\"Manage Modules\",\"menu_id\":\"adm0\",\"target\":\"pat\",\"url\":\"/interface/modules/zend_modules/public/Installer\",\"children\":[],\"requirement\":0}],\"requirement\":0},{\"label\":\"Inventory\",\"menu_id\":\"invimg\",\"children\":[{\"label\":\"Management\",\"menu_id\":\"adm0\",\"target\":\"pat\",\"url\":\"/interface/drugs/drug_inventory.php\",\"children\":[],\"requirement\":0},{\"label\":\"Destroyed\",\"url\":\"destroyed_drugs_report.php\",\"target\":\"report\",\"children\":[],\"requirement\":0}],\"requirement\":0},{\"label\":\"Procedures\",\"menu_id\":\"proimg\",\"children\":[{\"label\":\"Providers\",\"menu_id\":\"orl0\",\"target\":\"pat\",\"url\":\"/interface/orders/procedure_provider_list.php\",\"children\":[],\"requirement\":0},{\"label\":\"Configuration\",\"menu_id\":\"ort0\",\"target\":\"pat\",\"url\":\"/interface/orders/types.php\",\"children\":[],\"requirement\":0},{\"label\":\"Load Compendium\",\"menu_id\":\"orc0\",\"target\":\"pat\",\"url\":\"/interface/orders/load_compendium.php\",\"children\":[],\"requirement\":0},{\"label\":\"Pending Review\",\"menu_id\":\"orp1\",\"target\":\"enc\",\"url\":\"/interface/orders/orders_results.php?review=1\",\"children\":[],\"requirement\":1},{\"label\":\"Patient Results\",\"menu_id\":\"orr1\",\"target\":\"enc\",\"url\":\"/interface/orders/orders_results.php\",\"children\":[],\"requirement\":1},{\"label\":\"Lab Overview\",\"menu_id\":\"lda1\",\"target\":\"enc\",\"url\":\"/interface/patient_file/summary/labdata.php\",\"children\":[],\"requirement\":1},{\"label\":\"Batch Results\",\"menu_id\":\"orb0\",\"target\":\"pat\",\"url\":\"/interface/orders/orders_results.php?batch=1\

This file has been truncated. show original

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.

system · February 11, 2016, 10:58pm

sunsetsystems wrote on Thursday, February 11, 2016:

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

system · February 11, 2016, 11:40pm

teryhill wrote on Thursday, February 11, 2016:

Looks good I like the ability to lock a screen and then bring up a second screen vertically. Impresive.

Terry

system · February 12, 2016, 2:57pm

aethelwulffe wrote on Friday, February 12, 2016:

Once again Kevin, you rock.

system · February 12, 2016, 5:31pm

yehster wrote on Friday, February 12, 2016:

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.

system · February 12, 2016, 5:36pm

yehster wrote on Friday, February 12, 2016:

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.

system · February 12, 2016, 5:52pm

mdsupport wrote on Friday, February 12, 2016:

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.

system · February 12, 2016, 6:04pm

mdsupport wrote on Friday, February 12, 2016:

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.

system · February 12, 2016, 6:14pm

yehster wrote on Friday, February 12, 2016:

Pretty sure you can figure out how to do #2 (move the tabs) based on the code here

github.com

yehster/openemr/blob/iframe-alpha1/interface/main/tabs/main.php#L77


                                                              .',' . json_encode($userQuery['lname'])
                                                              .',' . json_encode($_SESSION['authGroup']); ?>));
</script>
<div id="mainBox">
<div id="dialogDiv"></div>
<div class="body_top">
    <span id="menu"  data-bind="template: {name: 'menu-template', data: application_data} "> </span>
    <span id="userData" data-bind="template: {name: 'user-data-template', data:application_data} "></span>
</div>
<div id="patientData" class="body_title" data-bind="template: {name: 'patient-data-template', data: application_data} "></div>
<div class="body_title" data-bind="template: {name: 'tabs-controls', data: application_data} "> </div>


<div class="mainFrames">
    <div id="framesDisplay" data-bind="template: {name: 'tabs-frames', data: application_data}"> </div>
</div>
</div>
<script>
$("#dialogDiv").hide();
ko.applyBindings(app_view_model);


</script>

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.

system · April 22, 2016, 10:00am

yehster wrote on Friday, April 22, 2016:

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).

system · April 22, 2016, 10:23am

osverdlov wrote on Friday, April 22, 2016:

Looks promising. IFRAMES + Bootstrap classes is promising.

system · April 24, 2016, 12:04am

bradymiller wrote on Sunday, April 24, 2016:

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

system · April 24, 2016, 12:06am

bradymiller wrote on Sunday, April 24, 2016:

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?

system · April 24, 2016, 12:12am

bradymiller wrote on Sunday, April 24, 2016:

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

system · April 24, 2016, 12:17am

bradymiller wrote on Sunday, April 24, 2016:

Also noted several things are missing like the search stuff from left_nav and the popups section.

system · April 24, 2016, 6:45am

kodusote wrote on Sunday, April 24, 2016:

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.

system · April 24, 2016, 9:55am

yehster wrote on Sunday, April 24, 2016:

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.

system · April 24, 2016, 10:02am

yehster wrote on Sunday, April 24, 2016:

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.

system · April 24, 2016, 10:05am

yehster wrote on Sunday, April 24, 2016:

Database only eventually. JSON mechanism is there primarily for development purposes.

system · April 27, 2016, 8:20pm

juggernautsei wrote on Wednesday, April 27, 2016:

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.