mdsupport wrote on Thursday, August 25, 2016:
Has anyone noticed that the “Fax/Scan” entry is not shown in tab menu?
bradymiller wrote on Friday, August 26, 2016:
Hi MD Support,
I brought in your code on github to add the “Fax/Scan” entry to the menu and also that made the json object human readable (thank you for doing that; developers can now actually look at the json object and see what it is doing).
thanks!
-brady
OpenEMR
medfetch wrote on Sunday, August 28, 2016:
The Tabs functions is quite powerful. I took some liberties with css and shadows and buffed up the menu and tabs for a more uniform look and feel. I also trimmed the new openEMR logo a bit to put it in the menubar. I didn’t mess with its core.
https://github.com/ophthal/openEMR_2.git branch: ophthal-master-iframe-dev-9
This version acts more like a menu and the tabs are more like folder tabs. It looks a lot bettter in some color schemes than others so experiment with the themes…
The data in each menu section and their order is good because it is build off of the left tree menu terminology of the framed version. We should have a discussion about what goes in the menu, submenus, and what they are called. For instance, Procedures to me means actual procedures, like surgeries, but in openEMR it is referring to Testing - “Laboratory” and Radiology at its base. Perhaps ‘Procedures’ makes sense to others but if we are creating a modern GUI web app, we should make the terms as clear as possible. This is just one example and the only one I changed in this branch. Procedures -> Laboratory for discussion.
bradymiller wrote on Sunday, August 28, 2016:
Hi Ray,
Tested it out and it looks really nice.
Set up demo for folks to try out here:
http://www.open-emr.org/wiki/index.php/Development_Demo#192.168.1.134
I rebased your code on top of most recent codebase here to allow a code review:
thanks,
-brady
OpenEMR
bradymiller wrote on Monday, August 29, 2016:
Hi Ray,
I rebased your most recent code and placed a review here:
Only a couple minor things to address. This is really nice work and plan to bring it into the codebase asap after the minor issues are addressed.
thanks,
-brady
OpenEMR
bradymiller wrote on Monday, August 29, 2016:
Hi,
Here are a couple future improvements to think about down the road.
- Make it obvious when an item opens another menu.
- Make it obvious that an item will not work or don’t allow clicking it(for example, trying to click popup item if a patient is not opened).
-brady
medfetch wrote on Monday, August 29, 2016:
Ok. Kevin has built in a “disabled” css rule that we can take advantage of.
I also think we need to let any other page that is in an iframe know we are in the “tabs mode” or “frames mode” so $GLOBALS interface/globals.php would make sense, with the default = “frames” for now…
I am using in the eye form a class=“tabHide” that hides anything we need to hide while in tabs mode. So the bootstrap menu in the eye form does not duplicate anything in Kevin’s main menu; they compliment each other. Yet if you choose to view the Eye Form in Fullscreen mode, the Eye Form menu returns to its “full” menu mode. Currently this “full” menu uses the frames based logic but with a global[‘display’] == “tabs” I can further refine how the menu works while fullscreen with tabs not frames…
medfetch wrote on Monday, August 29, 2016:
The tabs option should be a global option for a site that a user can override. For example a site’s default is on or off (tabs or frames), but a user should have the option to override the site default and be framed or tabbed. Curently the default is framed. If I change the global to tabbed mode, it is tabbed for every user, not just me.
I am not familiar enough with the system to do this. Any pointers on where I would find this?
I found a couple of other issues with appointment scheduling that prevent us from making appointments while in the tabbed mode. I am hunting these down now…
mdsupport wrote on Monday, August 29, 2016:
You are correct in that for an user tabs is just another layout option. Things can get complicated for this. But your plan would be :
- Add an tabs setting toggle on user preferences (Misc > Preferences).
- Modify logon screen to consider user preference as it displays framed or non-framed version.
- Use consolidated version of Kevin’s commit to find all places where tabs are invoked to look for user preference first.
Re. menus - In tabs mode it would be simpler to cosider each menu header to be a tab+iframe combination - frames version was limited to 2 so it did convoluted logic to put a selection in correct frame. The tab row can be completely eliminated. The menu can be something like :
Patient | Encounter | Services | Billing | Reports | Settings | About
If current visible iframe’s menu label is clicked, the menu options appear otherwise clicking on menu will activate that iframe.
By making this generic, a practice can put a new menu item (e.g. One-Click) listing their favorites.
teryhill wrote on Monday, August 29, 2016:
Add this
‘new_tabs_layout’,
after this in globals.inc.php
‘ptkr_pt_list_new_window’,
That will make it a user preference
medfetch wrote on Sunday, September 04, 2016:
The tabbed version can now be set as a global default or on a per user basis. You do need to logout and in again to see the tabbed version. Tabbed is not the right word - maybe web application verison? When massaged a bit I think Kevin’s work will become the preferred way to use openEMR and eventually the default view. You can switch between the framed/app views easily.
I played with the css and had to learn a little knockout.js to begin to understand how Kevin achieved such a remarkable feat (making the framed version a web application). The small changes make the menu bar look more like a modern web application. The menu items are functional but the menu needs to link to a customizable DB based menu generator as Kevin stated above. Kevin has already written the guts to that.
http://demo.open-emr.org:2109/openemr
(with the next reboot)
If the user before you did not put it in tabbed/app mode, go to preferences and selected tabbed version, the logout and login.
bradymiller wrote on Sunday, September 04, 2016:
Hi,
This is very nice work. The menu organization may be tough for folks used to OpenEMR(also requires some dexterity to walk to the reports with all the nested calendars). May make sense to offer two menus (create another file menu_data_2.php and allow a global to select them).
Regarding storage and modification, I’m a bit confused on the best way to go. Should we:
- Store it in the json structure. And when modify it, then just store it again etc. This then keeps a history of changes, so could easily revert to a prior menu. Also makes it easy to assign calendars to user groups. There will still need to be a list_options list that holds each entry itself for being able to build/customize calendars.
- Store it in a more involved database structure. And then create the json from this.
Then need a menu builder gui (the choose of option 1 or 2 doesn’t really impact this, but the decision does need to be made before proceeding with this; thus the above decision will really get to be made by the person whom builds the menu buidler gui).
-brady
OpenEMR
bradymiller wrote on Sunday, September 04, 2016:
Hi,
One bug I noted is that the menu showing when hover over Administrator at top right is being cut off by the browser window. Thus the Changed Password string is getting cut off.
-brady
bradymiller wrote on Sunday, September 04, 2016:
Hi,
These major improvements in the tab view also lend itself to the following question:
Should the OpenEMR 5.0.0 release (likely in several weeks) have the tab layout turned on by default?
Does anybody have any thoughts on this?
-brady
robertdown wrote on Sunday, September 04, 2016:
My thoughts are yes. Given we are bumping from the 4.x series to the 5.x series, it is a good oppurtinity to make such a dramatic shift in the UI. I will work hard on getting the new themes to play nice with the tabs
teryhill wrote on Monday, September 05, 2016:
I think it would be the right time to make the tabs the new normal for the release.
mdsupport wrote on Monday, September 05, 2016:
Agree that this - maybe we should just call it ‘default’ menu - should become standard and left_nav can become “frames” menu. But more than names, nature of menu can change. Here are few suggestions:
- Create a menu.inc.php which will provide a common php array to left_nav and the default menu handler. This will contain merged information from the master list (found at the top of left_nav) and the jason used by Kevin - as a php array.
- Add keys from common array into a standard list that can be modified by local administrators.
- Modify left_nav to map the common array into master list to ensure no impact on rest of left_nav code. Since left_nav has lot of complex logic, it could have the standard mapping except possibly using the list.title for menu text.
- Default menu will be created using the order and the active status from the list. If a site wants to add ‘Favorites’ as a collection of menu items, they will have full control. We should also strongly look at using the notes field to allow control over menu actions - e.g. acl groups, post parameters etc.
- Zend has a very capable menu class. Once the new menu behaviour is stable, we should look at that as a long term solution.
New mechanism is probably not as reliable as left_nav. We did notice random issues when switching the focus. But as it gets put thru the paces those will be resolved.
bradymiller wrote on Thursday, September 08, 2016:
Hi MD Support,
Thanks for your detailed thoughts on this. Check out the ongoing roadmap for this feature (which is obviously in flux). Please post/integrate your ideas there so they get made into more concrete plans(and then can perhaps convince somebody to take this on):
http://www.open-emr.org/wiki/index.php/Active_Projects#Frame_Removal
-brady
OpenEMR