The Calendar screen is not used by everybody (note there is a globals option to hide the calendar and use the patient search screen in place of the calendar), so wouldn’t assume that the calendar is the “central” screen. From a workflow perspective, as a physician, in EMRs the main screen generally tends to be the “Message screen”. And I am guessing this is also the case for RN’s, receptionist, billers, etc.
My thoughts are to change the title of the Message screen to “Message Center” and place a Reminders section at the top (your widget) and the Messages section under this (your widget works nicely for this since it is expandable/collapsable). I am willing to bet that this “Message Center” script will become the focal point of OpenEMR when not looking at patients (in that case, the patient summary screen is the focal point); it will also make sense to migrate Authorizations there and then at some point create a UI that actually combines them all (still keeping the backend separate data structures though).
This is just my opinion; very curious what others think
(Jack; also agree click through are needed in the Messages module; suggest a ‘Open Patient’ Button to left of the Send Message button when looking at a message that opens the patient summary screen; this should be pretty easy to do)
IMHO, the a better location for the view button would be to the right of the text field with the patient’s name, or we could even make the label to the left of that text field a hyperlink.
It is far more natural that when you are looking at the patient’s name that you attention would be drawn to a control nearby.
I’m sure that many a person has tried to click on the disabled patient name text field with the hopes of it bringing you to the patient summary.
The “Context” of all the buttons at the bottom have to deal with the current message, so adding a “view patient” button their doesn’t seem consistent.
I’d say use a hover frame menu and put it anywhere that a wide horizontal frame does not jack with the layout…since we are already using frames all over the place
Art,
I have serious objections to adding further dependencies/complexities to frames. Frames are bad.
ATTENTION. Do not expect frames to be supported in future versions of HTML. http://www.w3schools.com/html/html_frames.asp
They already are a source of significant issues for folks trying to use OpenEMR on tablets, and who knows what will happen in future desktop browser versions.
Any new features submitted to the project which introduces additional frames should be rewritten before it can become part of the official code base in my opinion.
I agree…I guess I was just making a dig at the whole frames question…in my usual immature manner.
I just got through implementing a user-preference taggled vertical frame split mod, thinking all the while “Geez, even I know better than this!”
Of course, tablets kinda suck too. Size is not everything, but quantity is a quality of it’s own!
I’m looking forward to getting this reminders system up!
Code is looking good (I realize still some functionality/polishing missing though). I rebased all of your work into one commit here and did another review: http://github.com/bradymiller/openemr/commits/tajemo-dated-reminders_3
(to see my comments, search for ‘bradymiller’ on the commit page)
To get my commit into your local repo, do the following:
You will now have replicate my branch at your local repo on a branch entitled dated-reminder_4 . Suggest that you then continue working from that branch; and if you want, I’d be happy to show you how to rebase your stuff into one commit before then posting it to github.
Also,
for the patient popup, suggest replicating this from elsewhere in the codebase. For example, from the Messages module script (when entering in a new message).
-brady
Craig, http://code.google.com/p/msysgit/
The git command line is IMHO better/faster than the GUI. Git takes time to understand, so no need to apologize.
Brady, besides merging and commenting on Github, “code wise,” your branch is the same, yes? Working off of that branch would make it easier for external folks to review the work, but isn’t really critical, correct? The “merged” branch just makes it so we can see everything that is different from the “baseline” in one commit instead of multiple.
Just wanted to clarify for Craig that working from your merged branch would be helpful from a collaborative stand point, but not an absolute requirement for submission by any means.
-Kevin
Kevin is correct. Craig does not need to work from my merged branch; what he is doing now if perfectly fine. My merged branch with one commit is for the following:
1. Allows a full straightforward review of the code on github
2. Provides a nice way to begin to learn about rebasing and working collaboratively with git
Although it will be nice for Craig to learn how to learn how to work collaboratively with git and rebase code in the future, this is not expected for developers learning how to use git (the learning curve of git is tough). Things will become much less of a black box if you also use the git command line(perhaps after feel comfortable with the GUI).