Hi everybody,
Checking in to see if the community thinks it is time to drop the frames UI support? Please weigh in with your thoughts on this since this is a big decision for the project.
-brady
Hi
Yup it is a big deal…
It won’t be easy for those long time users.
I have users over 65 and upgrading from 4 to 5 was an issue.
My personal peev…have you ever tried opening the Administration menu as administrator on a tablet?
Way too long. It’s the only in which situation (for me) I switch to frames and back.
And finally (and I know it’s not something we can control), lots of videos and screenshots with frames.
That’ll add to the confusion.
Thanks
I get it, but we’re not going to have a choice in the matter much longer. Framesets have been deprecated for a long time now and some user agents flat out say they do not support(though still allow) . We all know how browser teams work these day, there one day, gone the next.
Agee about Amin menu but, that’s a simple fix. Break it down some with either a new main titled menu or sub menus. Also need to fix the focus for selecting sub menu items. Frustrating sometimes trying to move over to submenu.
Also, Frame UI is very tightly integrated in existing code and if it goes, code must be addressed. Will take some knowledgeable dev’s to commit and take this on.
Easiest road is to move the framesets to iframes if we keep. Still problem will remain of maintaining two UIs in code.
Lastly, agree that us 65 and over have attitudes about change. Unless of course, it’s a new fishing lure or an improvement to our golf stroke! 
I wouldn’t add a new main title. Too many main titles wrap around on tablets. Submenú it better.
If frames die with it be in current version or in 6.x?
It would go over easier with the users on a major release than a patch within a current version.
Gone 
ing…
We’ll not go to a major release 6.0 bump until we go after certification on MU3. I don’t see anything happening in 5.0.2 but, we have to address this and get a committed team on it soon.
For me it’s not fishing. It’s an operational mission that would make Patton proud…
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