hi,
Sounds like work needs to be done to make the main tabs layout responsive including the menu. For the menu, we could migrate menu to left on medium screen and show cog on small screen (this is just some quick thoughts). This sounds like a job for super @zbig01 
Regarding removal of frames, I could probably do that when we get to that point (should be straightforward since we have nice global and js settings as hooks to search for).
Hate when a viewport forces a menu to a button. Menu is prob responsive now and we just need to make it more manageable. Maybe @zbig01 will set us straight…
When do ya want to do it, 502 or 503? I’ll help as long as I don’t have to escape anything!
@sjpadgett , the nice thing about code demolishing is it is all about deleting (ie. no escaping ); very therapeutic . Gotta address the reasons why folks are stuck on frames before can remove it. Seems like the following 2 things should get us there (assuming no other reasons are given to keep frames around):
- tab layout and menu fully responsive
- option for placing the menu vertical (left for ltr and right for rtl)
I fully support the removal of frames. I know there may be challenges with end-users learning a new UI/UX but from a technical perspective I think continuing to try to support frames will be unsustainable, espceially as we move towards a modern modern structure for the UI.
I’ve looked at how the menu is driven and honestly it needs to be rebuilt from the ground up. If we had a JS guru this would be a great place to go full Web Components and JS to drive the UI.
As far as the actual mobile usabiliyt, I think a solution could be collapsing a LOT of the Admin menu into just 5-6 submenu links and handling the other options on the actual page using a left-sided menu. Another alternative would be to break items after 5/6 items and float them next to each other.
I’ll put together some mockups of how I think our menu structure should be. One thing that irks me is how disconjointed our UI can be. Thsi may be a good time to identify ways to standardize our user intaface adn improve the overall user experience
I understand the viewport moving a menu to a button but I do think there’s a ton of value in doing this - real estate is precious and menus take up space that could maybe be put to better use
It works okay in portal but I use left menu for that reason. I’m working on portal now to send alerts via messaging api and while there I am going to make the button fixed to follow the page so no scrolling to get back to it. I don’t have a problem with that.
I think if the system could be more optimized for Touch, that would be ideal. Having the EMR on a tab running would be quite beneficial and easy to manage.
1 Like
frames UI -
Users complain for few days and then start liking flexibility of multiple views.
Menu -
Rather than throwing another component, why not remove knockout and just use basic bootstrap 4?
The menu probably could be served up a bit more naturally, but if I recall we are locked in to bootstrap 3 for i18n reasons.
We can replicate the frames concept without using actual frames, can be accomplished with CSS
Hi,
Rather than rebuild or do a bunch of work, what would be the most direct line to the following options in the tabs layout:
Global 1 - Menu Layout:
Horizontal (what we have currently)
Responsive Vertical (this would be horizontal until viewport to medium size, then to vertical)
Vertical (this would be vertical all the time - left for ltr and right for rtl)
Global 2 - Allow Cog Menu:
If true, then allow to reduce menu to cog when viewport small
I think these changes would allow us to then drop frames completely.
-brady
I think a collapsing left menu may work out. I was looking at portal again and it works pretty good on tablets with a fixed header and cog to reveal and hide left as needed.
I think knockout can be handy and tabs seems to be nicely done and uses flex/json and knockout. Moving to bootstrap could get involved. However, BS4 may need to be considered or at least get us to 3.3.8 (last I looked, we’re at 3.3.4).
Bottom line I think we could put this to bed by going to the left. Also need to move the tab scroll to the bottom of screen or style better as it hide most of the tabs height.
If a menu reshaped is in the works, how about going to a File Edit View Function(s) About menu structure? I wrote some menu json files up a way back that based on acl rules. The original structure can always be an option. The stumbling block was to wrap all that up in an engine. If you pick one maybe this would be a goid time to make the menu more noobie friendly.
Another companion idea is short cut macros
I think on desktop we need to stay with a horizontal menu. On a tablet a vertical menu could make sense, this would be hidden by a cog until the user needs the menu; too much screen space is lost by it just sitting open. I want to see vertical menus on the desktop used only within a tab, the Globals page for instance should have a vertical menu instead of a horizontal one…
There is one more problem that needs to be addressed before fading frames. I wrote about it here:
https://community.open-emr.org/t/missing-find-by-section/9105
It is still unresolved but we keep using this function switching back and forth from Tabs to Frames to search values in the custom fields. This is inconvenient but if the frameset goes we will lose this functionality entirely.
If I get a chance i’ll move this feature over before 502 release. If in frames it should come over to tabs and be supported. If you don’t see it done as we approach release, remind me again.
Lack of RTL capability in BS4 seems to be coming up repeatedly in this project. A quick search comes up with this fork.
Since we do not have neither the expertise nor the resources, may be those who are likely to be affected can devote some time towards this?
Our experience shows new features in BS4 are worth the little effort needed towards this.
Did not realize we plan BS4. To what end?
btw @alexvolin, I moved findby Any to v5.0.2 and is code base…