I just brought in Ray’s work on the tabs layout into the codebase which is quite simply stunning!
A big KUDOS to both:
Ray for this visual piece of art
Kevin Yeh for this structural piece of art
(ok, I am being a bit over dramatic, but wow)
I also made the tabs layout the default setting (for now, at least).
I’ve noted the following issues:
Not all the menu items in the left_nav are represented in the tab layout menu.
The Zend tab and functionality is definitely not quite right in the tab layout menu.
I think we will run out of menu real estate if try to emulate some of the left_nav links (such as portal links). Would it make sense to make a ‘Main’ tab at the left that held the following items:
Calendar
Flow Board
Messages
Offsite Portal link (if on)
CMS Portal link (if on)
Somehow set it up so the Flow Board and the Calendar are on separate tabs so they don’t overwrite each other.
We should have a menu which changes based on the user’s need - like many products have a PM section and clinical section. So no cramming will be needed. I’m not sure this tab layout should be the default until this is worked out, by consensus, but OK, it is. You can always just switch between them.
For #4. Kevin thought of that already - the json in menu_data.php directs which tab holds what. Just change the target for Flow Board from
“target”:“lst”
to
“target”:“new”
Terry is adding a title to the "Flow Board" so it will show up in the tab.
I should of prefaced my above issues with “short-term” goals prior to 5.0.0 release which should happen within next 1-3 weeks.
Fully supporting multiple menu configurations is something that will likely take more time (there have been several posts in the forum discussing ways to do this, but in the end will be up to the person/group that does the work ).
If want something like this in the short term in time for the 5.0.0 release, we could add a global that would allow choosing of a json menu. Essentially, would pick the json menu file:
menu_data.php
menu_data_2.php
…
Then, for example, we could then bring in your menu_data_2.php file(or another of yours or communities choosing):
Regarding making the tab layout the default or not, this is currently a “temporary” measure to see if this is the direction the community wants to go for OpenEMR 5.0.0. (also with an intention to get some momentum going on this).
If you are a member of the community and have an opinion on this, please weigh in on the following question:
Should we use the tabs layout or the frames layout as the default setting for OpenEMR 5.0.0?
(disclaimer: there is still work to do on the tabs layout)
I’m going to try to answer my own question.
Should we use the tabs layout or the frames layout as the default setting for OpenEMR 5.0.0?
I’m a bit conflicted on this. On the one hand the tab layout is very nice and is very likely going to be the future direction of OpenEMR’s main UI. But on the other hand, it’s hasn’t seen much testing and there are still some issues that need to be worked out(ie. may not be ready for primetime).
In the end I suppose it is just a default setting that can be changed, but many new users will likely stick with the default setting and not even know about the “other” option.
I agree that the Tabs interface is not ready as the default if it is missing things - and it has not even been tested it thoroughly.
Regarding the menu_data_2.php file, I added it as an example only - I imagine there should be different menus based on user types, menus that matched the user’s workflows. If a function is “not authorized” why use a pop-up saying this vs. not having it as a menu option at all for that user? So there would be a menu_front_desk.php and menu_physician.php and menu_administrator.php etc. How these menus get generated and how a multi-priviledged user switches between them needs to be worked out. And will an open framed “tab” be able to inject menu items into the top menu? They should be able to.
I don’t have the skills to write such code so it is easy to give my 2 cents…
Using the KISS standards, making one menu work well should be good enough for a release, so if the current menu is missing things, let’s add them in for 5.0. Waiting for the user-based menu option could be a while, unless one of the vendors has already separated out these workflows and wants to share the work with the community.
Another thing that will need to add to the tabs layout is the background service(this is a mechanism to auto-run background services when users are logged into OpenEMR):
I downloaded from Github using the green “Clone or Download” button and I’m running it in MAMP Pro 4.0.2. Is this the tabbed version? It must be since it says OpenEMR Tabs at the top
It looks great. This is the best look OpenEMR has had in years, since the simple top menu. I might finally be ready to upgrade from version 2.
A lot of doctors and health care facility administrators are going to want this.
I just committed some changes to the tab layout:
1.Separated some of the tabs (especially the patient board from the calendar) so they don’t overwrite each other.
2.Made the two initial tabs that are on at start up removable.
This stuff is very flexible and configurable, so let me know your thoughts (ie. is it worse or better).
There are still bugs that need fixing:
For the future(preferably after address above bugs ), I am thinking the following features would be useful(which I also added to the github issues link above):
keyboard short cuts
ability to drag and drop the tabs (ie. reorganize them)
use the ‘Main Top Pane Screen’ setting from admin>globals to populate the first tab when login
(feel free to add to this list)
Not able to pin it but drop down menus close too quickly before focus can shift from menu title to menu items. Has anyone else had simillar experience?
Win 10 / Firefox.
To be sure, the behavior is not limited to your PR. Best guess - it is related to delay setting for closing the menu since click or hover on menu title does not seem to make difference. Worse yet, same item behaves differently after 2-3 tries. It will be extremely frustrating for end users.
@MDSupport, haven’t had a chance to boot up my VM to check on that but running Firefox on OS X hasn’t given me any problems at all–will look tomorrow.
For everyone, here are a couple of screenshots if you haven’t had a chance to check the UFG demo with improved styling.
I still need to test in a couple of browsers and fix up the user menu on the right. Assuming the testing goes well, I think the styling of tabs/menu/pt info is at a place I’d be comfortable releasing. I know other functionality may not be there yet though.
Since this is styling, I am guessing there are going to be divergent tastes here like the current themes. To this end, I added support for multiple tab layout themes:
There is currently the following selections at Administration->Globals->Tabs Layout Theme:
‘Compact’ is Ray’s most recent css styling
‘Full’ is Robert’s most recent css styling
Also combined the tabs and menu css files and placed them in the the standard themes directory. This should also make rtf support more straightforward.
I propose to bring this code in as Robert continues to work on his tab theme(see next post for issues I noted with Robert’s theme).
The Administration menu is running off the screen (since it is so long)
The User menu at right looks like this(Logout is not below Change Password):
Settings
Change Password Logout
And most importantly is the issue when transitioning from one mouseover area to another. When I hover over the top menu item, the submenu shows, but when I drag the mouse down, the submenu goes away. As you can imagine, it is very frustrating. Ray has explained this to me via email in the past when I noted it on his tabs theme. Notably Ray did not note the bad behavior on OS-X, which is why Robert is probably not seeing it. And it was fixed with this code: improve the transitioning from one mouseover area to another · openemr/openemr@aab007d · GitHub
On a side note, does this mean that we can remove the typicons-2-0-7/src/font/typicons.min.css library?
