Vertical Split Screen Mod

aethelwulffe wrote on Friday, February 17, 2012:

http://www.oemr.org/phpBB3/viewtopic.php?f=5&t=115

Vertical vs. Horizontal split screen mod for OpenEMR.  Just a file update, no set-up, database update or any other complications.  Instructions, download, and screenshots on the OEMR forum thread above.

cbezuidenhout wrote on Friday, February 17, 2012:

looks good, going to give it a try and I will give you feedback.

  - Craig
    Tajemo Enterprises

yehster wrote on Friday, February 17, 2012:

https://github.com/yehster/openemr/tree/vertNav
https://github.com/yehster/openemr/commit/f68367d12b65d761b99f1d2aa71cafd9f675a5a3

For easy reference as to what is changed.

On a large monitor, this is definitely a better use of real estate than top/bottom.

aethelwulffe wrote on Friday, February 17, 2012:

Any suggestions on using java resolution detection to set between one mode or the other as default (as I pop top-bottom vs. left-right toggles in)?

yehster wrote on Friday, February 17, 2012:

new branch
https://github.com/yehster/openemr/tree/framesOrientation
https://github.com/yehster/openemr/commit/7d7adbef41f5682b1988157caa37261e453f56ab

Added a toggle button which lets you select orientation at runtime.

yehster wrote on Friday, February 17, 2012:

Rebased the code, so the commit in my previous message is invalid
https://github.com/yehster/openemr/commit/03a4e147ddcfc1d0f6bd9c61c7a82cfa8f0cdf2a
Link to the tree is still good.

aethelwulffe wrote on Friday, February 17, 2012:

OK, so am I correct in assuming that we throw out the initial changes I made to main_screen, and we only need to diff against https://github.com/yehster/openemr/commit/03a4e147ddcfc1d0f6bd9c61c7a82cfa8f0cdf2a for changes to left_nav.php and frame_format.php?

I already got 3 PM’s and 5 emails from the board on the mod package I posted.  There were a lot of exclamation marks involved, and beneficent noise-making, so I think this is a pretty well desired format option that a lot of folks would like >now<.  I would like to immediately remove my zip file and provide revision instructions to revert to vanilla, and use a separate set of files to install your version of this for those that have already tried it.  It’s getting downloaded about once every 20 minutes, so now would be a great time to pop this out for tests, opinions, as well as getting something to those users that looks a good bit more like what may go into the master.

yehster wrote on Saturday, February 18, 2012:

https://github.com/yehster/openemr/commit/ea3c3b06c9047b3baa70a9bb29cd133dbbb0cc68
Art,
This commit is probably what will go into master. I addressed Brady’s comment about spacing on the commit you linked to and also fixed a bug with the select list for picking a frame not accurately reflecting the window states.

There is and always will only be one change to left nav for functionality.  (the new include once line).  Any additional changes will be in the frame_format.php.

I’m not using any frame work, or any fancy object oriented patterns, but this IMHO *is* a modular design.  The functions relating to this feature are contained with in a single new file, and the change to existing code is but a single line.

aethelwulffe wrote on Saturday, February 18, 2012:

I’m not quite sure we could call it a “commit” I linked to :slight_smile:
I never saw the comment on spacing.  I have become aware that again and again I am seeing extra spaces at line endings cropping up as differences in other folks code.

I am very grateful that you used an include to handle all the frame display functions, yes, that is very much modular design, and even re-usable up to the point of positioning.  I wanna look into it better and see what arguments can be passed to it.

Here is kinda where I was headed (before the professional preempted my b.s.):  http://arsponline.org/menu/

aethelwulffe wrote on Saturday, February 18, 2012:

….DANG….
You can click the “view” and “freeze” buttons in the above HTML5 example, but the menu item buttons on the left are just for showing left_nav position on the screen.
There is a lot of useful space in the top menu, and the shorter you can make the left navbar, the better as far as the laptop folks are concerned.  This style (probably with smaller buttons or icons of course) would be easier to understand, and make good use of available space.  One of the hardest things for folks to get when using the emr is the function of the frame selection stuff.  I figured out that once people understand that a selection can also pick which one they want to open a new item in, they STILL think of the one they are selecting as the one they wish to stay static, not the one they want to change.  I figured reversing the logic with a “freeze” button might be more intuitive.

yehster wrote on Sunday, February 19, 2012:

Art,
All of that looks terribly complicated.  How about something which uses the KISS principle.  Maybe left click and it opens in the left frame, right click and it opens in the right frame.
As far as useful real estate. Although not glitzy, I think using the tree menu instead of the sliding animations is a good option.

aethelwulffe wrote on Sunday, February 19, 2012:

Hey, I’m just one of those ergonomics freaks.  I round off all the cabinet corners, and simplify the boat rigging to the point where no lines snag, and friction is minimal.  I find it’s a lot more fun to sail than to fight the boat.
  I made that menu mock-up to test the performance difference in switching view modes.  With lots of experience, in the EMR takes about 8 seconds for me to switch from a single view/default loading with top-bottom, to a left-right view with one panel locked.  In the mock-up, it takes less than a second.  That means it will not be more of a pain to switch modes than to just “live with” however it is at the moment.  I feel the four lines of code would be well worth it.
Warning:  I am using speech recognition, so my posts tend to wax loquacious.
I’m not sure I agree about that mock-up being complicated, but I agree that there are any number of possible arrangements.  I personally would also prefer a left/right click option, and I do CAD in a program that is almost entirely controlled by a three button mouse.  Way faster than menus or tool tip buttons for everything.  The EMR tree menu is also preferred by many.  The sliding menu is the vanilla default though.  This means it is going to be the one that gets used in most cases.

Despite my preferences/opinions, you can never underestimate the public.
I find that fully graphical tool buttons are better for many people, and you don’t have to worry about label verbiage in 16 languages.  The other problems are the whole two-button issue with our end users.  I am not saying that it is acceptable for a professional that does ANY kind of documentation in the present day to not have a extensive experience with typical basic keyboarding interfaces, but that isn’t the real world.  many (ok, almost all) of the office workers I have attempted to train are not even aware of the typical “left click execute, right click context menu” bit.  Then there is the damn Mac crowd who got one (One!) button with their mouse or touch pad.  Stylus users and touchscreen users would also benefit from a button interface.
  When I have demonstrated OpenEMR to doctors, I always run into the “Tor” syndrome.  That is a Doctor that isn’t into the .doc part.  They whine about every last little click.  Literally, I hear "I don’t like having to click so many times to do a note! *whine* ".  Yes, they are prima donna aristocrats, and they make me puke.  That’s the way it is though, and I don’t like having to start explaining how to use the interface in terms of “Well, first click here, then click down here if you want it the other way, then pick this from the drop down, unless you have opened a new patient, then of course you need to do it all over again….”

  (There are already six (depending on how you count them).  There is a css button way at the bottom of the nav bar that talks about frame orientation (Betty black would need that one pointed out to her, and explained a few times), then you have the drop down menu with three options and no clear (from the eyes of an uninformed, non-curious, non-experimentalist type) explanation of what it does, and then the two top-bottom (or left-right) buttons.  I see that as “terribly complicated” and dispersed (or I wouldn’t be worried about it, -ja?).  To most users, they are essentially hidden features.  I’m not bashing it, but if I made a video game with controls arranged like that, the high scores would suffer, and not very many folks would want to try playing it twice.
  Simplicity is sometimes terribly complicated to achieve.

  Not bitching about how things are, but it’s just something I want to see worked out, at least for me.  No-one has tinkered with this stuff for a while (despite a lot of interest over the years), so I figured no-one would mind me doing things how I saw fit for my own edification.  Just throwing the ideas out there.
>Personally<, I would like a multi-mode button that lets me pick what layouts and menus I see.  Click a button to cycle through the Admin, Provider, Financial, Scheduler “modes”.  If you are in “Biller” mode, you always get the billing widgets, billing history etc… You don’t default to the calender when you pick a patient, you don’t get clinical forms, or any of that stuff.  It could pare everything down to the financial functions.  By default, that means that anything you CAN see, is stuff the user should probably tinker with.  Same benefit for the doctor.  Yeah, you can achieve this with the ACL to a limited extent, but that is “include or not include”, and doesn’t have an option to pare down just for efficiency.   Data entry time is a real concern for clinics, and not just because of their lazy-butt whining.  repeat($years*$hours*$minutes){$A_tiny_efficiency_boots+=$chump_change;}

yehster wrote on Wednesday, February 22, 2012:

I’ve been thinking about this problem more, and think that I have a idea to change the interface for the better by using iFrames (inline frames) instead of old school frames.  I didn’t realize it, but iframes are part of the HTML5 standard, and in fact gmail makes use of iframes.

This would allow for a “tabbed” interface of sections instead of being restricted to just the two frames we have right now
What I’m thinking is I’m going to add a button to create new tabs, and when you click in left nav, it just opens in the current active tab.  I might create a couple of tabs (calendar, messages, patient) by default to start with.

Anyway, this will be simple enough and similar to something folks are already used to (e.g. tabs in the browser). To start, only one tab will be visible at a time, but the ability to split the screen into more than one tab is a possibility.

It’s a complicated problem, but I do see a path to a solution.

sunsetsystems wrote on Wednesday, February 22, 2012:

Iframes have much in common with normal frames, so that’s definitely a workable idea. I’ve always thought we should do more with tabs.

Rod
www.sunsetsystems.com

aethelwulffe wrote on Wednesday, February 22, 2012:

I second that.
  I personally love the utility of iframes.  The first (and then, really quickly supplanted with good) code) submission to OpenEMR I made was a revision of the scanned documents form using iframes and including a bunch more MIME types than we could before.  They are kinda like nifty little includes that you can use to grab anything from anywhere for display:  which is part of the problem with them I suppose.
  Users are really used to using tabs these days.  I used to not like them so much, but they became ubiquitous and thus the general public learned to use them.  This is an interface option that no-one can argue against.  It’s already like…out there, and everything uses it.
  I am really getting into HTML5, and I might be able to provide some input somewhere on this sort of thing (seamless for split screen, cascade tiles, sandbox frames for allowing access to restricted data, window.frame,  etc…).  As usual, I’ll jump on any new thing and help beat on it until it breaks.

yehster wrote on Wednesday, February 22, 2012:

The approach I’m thinking of taking initially is to duplicate a few of the files (left_nav.php, main_screen.php) and create copies (left_nav_tabs.php, main_screen_tabs.php) so that they can coexist with an existing installation so folks can potentially try things out on a live system without much fear.

aethelwulffe wrote on Wednesday, February 22, 2012:

I’m also a big fan of a side-by-side approach.
I have heard of the “smart form installation” or something like that going around which I have not taken a look at.  How about I look into that and see if it is relevant in any way, and then look into a globals.php include that can detect add-on stuff like this.  I imagine I could create some functions (and a plain-language API guide) that we can use with new features, and have their toggle magically appear in a globals admin tab.  That way, future dev testing can be done more easily by running installs.  Operating installs (and users) seem to be the only wash-test that ultimately brings the evil critters to light.

In you guys opinions, what are the “core” OpenEMR files?  Not really counting the ACL and any other engines that have been brought into the app, just the “these files make the central decision engine”.  Do we have a nifty list on the dev wiki pages anywhere?

sunsetsystems wrote on Wednesday, February 22, 2012:

The approach I’m thinking of taking initially is to duplicate a few of the files (left_nav.php, main_screen.php) and create copies (left_nav_tabs.php, main_screen_tabs.php) so that they can coexist with an existing installation so folks can potentially try things out on a live system without much fear.

You might create a Global setting called something like “experimental tabbed interface” and then add conditional logic in the existing modules.  I’m thinking that might be cleaner, but not sure offhand.  Just a thought.

Rod
www.sunsetsystems.com

aethelwulffe wrote on Thursday, February 23, 2012:

That’s pretty much what I am thinking…and obviously it isn’t gonna be as simple as it sounds.
I figure a whole new dynamically created tab/section of the globals admin, and the modules themselves initialize the appropriate globals, working off that “use experimental” setting you are talking about.  I don’t see any way around not using the database to initialize the “catalyst” globals that make all that work, at least between runs.  It doesn’t need to be drawn out of the globals table though.  I am sure some new table, or wherever the personal preferences get their mojo from would do for that.  I would not like junking up the vanilla globals.

  I figure it would be best to have a naming convention for add-on globals.  Should be prefixed by the contributor, then the add-on name abbreviation, and then the meaningful descriptor.  Something like $_Sunset_godmodule_lightning or $_MI2_thememod_purple.  In my spaceflight simulator dev team, we always  name global variables for the module, and local variables for the object, even when they are completely private.  It helps.

bradymiller wrote on Thursday, February 23, 2012:

Hi,

Agree with Rod. It would be ideal to keep it in existing modules with global(s) and clear conditional logic. Thus, the code won’t stray (a feature added in one module, but not the other). That being said, I’m speaking a bit superficially since I don’t know to what extent the code modifications will be.

-brady