Placement of Calendar link in tree menu

OpenEMR Development
1

fred0 wrote on Tuesday, June 02, 2009:

As I continue to test, one UI thing that jumped out at me was that the placement of the Calendar link in the tree menu inside Patient/Client>Visits was very inconvenient. In particular, for our small staff who are often doing many things at once as well as taking new appointment calls, having to dig through 2 levels of menus to get to the calendar to see appointments and add/manage them is a time waster. Ad such, I am suggesting moving it to be its own link at the very top of the tree above all other items so that it is always there and fast to get to. Here’s a diff output (diff left_nav.php left_nav.php.new) of the changes:

659a660
>   <?php genTreeLink(‘RTop’,‘cal’,xl(‘Calendar View’)); ?>
695d695
<           <?php genTreeLink(‘RTop’,‘cal’,xl(‘Calendar View’)); ?>
775a776
>   <?php genTreeLink(‘RTop’,‘cal’,xl(‘Calendar View’)); ?>
787d787
<           <?php genTreeLink(‘RTop’,‘cal’,xl(‘Calendar’)); ?>

2

bradymiller wrote on Wednesday, June 03, 2009:

hey,
Sounds good.  To make even easier for us do this command ‘diff -u left_nav.php left_nav.php.new’ which provides better context, and we can then use the patch command to place it into our code.  Email it as attachment to brady@sparmy.com and I’ll put it in if nobody disagrees.
-brady

3

fred0 wrote on Wednesday, June 03, 2009:

Will do.
And for anyone else reading this and wondering how patches work, here is a good explanation:


also

4

cfapress wrote on Thursday, June 04, 2009:

I’m going to start trouble here…

What about designing the whole tree vs. radio vs. top-menu thing?

Yeah, a big job but here’s my idea.

Pull out the structure into a XML/database-table/text-file and then have it parsed by the program in order to display the chosen menu style. This would allow each menu style to have identical contents but through different display styles.

Let me try to explain a little more clearly. Say we have this as a config file for the menu structure (JSON style)

{ menus:
   {
     Patient: { "Add New", "Search" }
     Admin: { "Database", "Forms", "Users" }
   }
}

Then each menu-style (tree, radio, top-menu) would parse the config file and present the menu structure. There-by separating the style from the content.

One of our troubles with the menus is the inconsistency between the various styles.

What do you think?

Jason

5

sunsetsystems wrote on Thursday, June 04, 2009:

Dunno, that may become overly complex, a bit like inventing a new programming language.  For example many menu items are conditional, depending on permissions or custom requirements.  When in doubt, I vote for simplicity.

Rod
www.sunsetsystems.com

6

bradymiller wrote on Thursday, June 04, 2009:

hey,

Sounds complicated if need fine granular access (ie. the acl access controls, "sports team") and support of internationalization.  Then what if somebody comes and and makes a "better" navigation menu without this system.  Seems like time would be better spent just making them consistent and improving on usability of the tree menu (unless somebody comes up with a better menu, I think majority of users will be using the tree menu):
http://www.oemr.org/modules/wiwimod/index.php?page=MenuSelectionMapping

Since you bring up such a large project it makes me think you’ve got some developer time. At this point a subconscious voice is telling you “make outlook calendar default”, “make outlook calendar default”.

-brady

7

cfapress wrote on Friday, June 05, 2009:

Oh, I certainly don’t have any extra time for developing new stuff. It was just an idea. I’ve spent hours correcting the inconsistencies between the various menu styles. This idea was just to help alleviate that problem in the future.

In fact, I’m pretty certain there are some items in the tree-style that are missing from the top-menu-style. But nobody has brought them to our attention.

As for the Outlook-style calendar becoming the default, that sounds great to me. I’ll have to look back to see if there are any outstanding issues around that other than just flipping a few config file variables.

Jason

8

bradymiller wrote on Saturday, June 13, 2009:

hey,
Still unsure if community wants to move the calendar link out of patients section. This seems to work well; (note i didn’t touch the sports team stuff). Let me know if this would be useful in cvs:
<ul id=“navigation”>
+  <li><?php genTreeLink(‘RTop’,‘cal’,xl(‘Calendar’)); ?></li>
   <li class=“open”><span><?php xl(‘Patient/Client’,‘e’) ?></span>
     <ul>
       <li><span><?php xl(‘Management’,‘e’) ?></span>
@@ -784,7 +785,6 @@
       </li>
       <li class=“open”><span><?php xl(‘Visits’,‘e’) ?></span>
         <ul>
-          <?php genTreeLink(‘RTop’,‘cal’,xl(‘Calendar’)); ?>
           <?php if ($GLOBALS[‘athletic_team’]) genTreeLink(‘RTop’,‘ros’,xl(‘Roster’)); ?>
           <?php genTreeLink(‘RBot’,‘nen’,xl(‘New Visit’)); ?>
           <?php genTreeLink(‘RBot’,‘enc’,xl(‘Current’)); ?>

-brady

9

bradymiller wrote on Saturday, June 13, 2009:

above is a diff from file openemr/interface/main/left_nav.php

10

ideaman911 wrote on Sunday, June 14, 2009:

Brady et al;

"I think the majority of users will be using the tree menu" ?

Because that is the default in the distribution (at least it is conceivable) ?  But it is not YET the distribution.

But if the MAJORITY have been using the previous default radio button, why do you believe that?  Have you ASKED?  How Many?

I think this proves mostly that we have eyes only in the front of our heads.

As to my opinion on the calendar view; having to click on an icon of a bust in order to see who I am to see is a needless tedium which makes the Outlook view less desirable than the Fancy.  So if you are going to default to the Outlook, PLEASE assure the Pt Name and Visit Type (with color code) are displayed for all as well.

And as you have already noticed, I believe it is imperative that ANY function available to SOME user of OpenEMR must be available to ALL irrespective of chosen style.  That we choose to change our default style before that is a fact is shameful.

Joe Holzer    Idea Man
http://www.holzerent.com

11

bradymiller wrote on Sunday, June 14, 2009:

Joe,

It’s simply what I think from the following observations:
1. Most people here seem to prefer it.
2. Several have stated their clients prefer it.
3. I prefer it from a developer and practitioner viewpoint.
4. Also the newbie test (“If I was using the demo, which would be most inuitive”), I’d argue, would go to the tree view.

I agree, though, we all do only have eyes in the front of our heads.

I just tried out the outlook calendar. It does show the patient name and you can see the visit type by hovering over the time of appt.  However, agree that it should also show a color coded visit type.  Shameful, sheesh, this is minimal resource open source progress.

Here’s a previous thread regarding going to the outlook calendar. If issues and or suggestions for improvement, then lets post there; I’m predicting it will get long:
https://sourceforge.net/forum/forum.php?thread_id=3085314&forum_id=202506

-brady

12

blankev wrote on Sunday, June 14, 2009:

If we only have eyes in the front of our head, how will we be able to see what happens behind our backs?

Because we have information!!!!!! We have knowledge!!!! We can have feedback!!!!!!

One of the many things that makes OpenEMR different and useful is the many possibilities! This is right away also the weakest point of OpenEMR. The manual for users of OpenEMR is a great piece of work, but it is only a starter.

It is all about the same:

“How do …“I”… know what is BEST, if I don’t even try what it could be in a different activated setting.”

And there is again that little snake creeping up. I want to have a working OpenPatient electronics file that delivers…

POINT
STOP, because that is all I want… or is it?

"Delivers", … what I think is needed in my daily practice work facility,

and no more. All other extra’s are great, but as a starting OpenEMR User I want it to work. Later on, it would be great if I know how I could make a change without ruining all former input.

So we need manuals. Much more manuals explaining what is behind the scene and what could be implemented if wanted to. It is there, but what does it do, and how can it be activated.

One of the many good things of OpenEMR is the translation effort. It is there to make a choice. What do you what and how do you implement it. You want Greek? OK no problem. Start as a Greek user. You want Spanish? You start with the Spanish User option. No hassle. If you don’t like it? OK continue in English original language. But wothout any manual you can explore and see if it is useful.

Another way to go, might be that we all have to fill some kind of questionnaire:

Who is using OpenEMR and what parts of OpenEMR are activated? Where and how long did it take you to find you way towards this activation and why didn’t you like the default…

Or you could start OpenEMR as a patient SOAP system and slowly add everything you want, just like XOOPS and JOOMLA give this possibility and make OpenEMR a CMS with add-possibilities-ons.

ADD-on for IPPF, ADD-on for Football teams, ADD_on for General Physicians, ADD-on for financial support, ADD-on for Multi Clinic use, ADD-on for Medication dispensary or other Dispensing things.

All and every separate ADD-on must have his/her own manual that explains what and how it is supposed to be used.

My thoughts are, after this long exposure of brainteasing of the future of OpenEMR as a user, and knowing that I am still finding my way around in OpenEMR after three year of active following hte different FORUMS, and knowing that every day of exploration I see so many flaws and good things that it keeps me running to my e-mail box, to see what is new for OpenEMR and actually want to have an new MAJOR RELEASE every morning!

Some advise: Keep up the good work of improvement, but also try to find some scientific insight of what is needed and what can be accomplished and how do we get these renewals to work for any user, future, past or just any user trying to comprehend the possibilities of OpenEMR.

Have a nice weekend all of you, Pimm

13

cfapress wrote on Monday, June 15, 2009:

Hi All,

Here are some pointers to use the Outlook calendar effectively:

* Hover your mouse pointer over an event, or patient, for details
* Events are color coded based on their category
* Category colors can be changed with the Admin->Calendar->Categories tool

The Outlook calendar has been designed for 800x600 screen resolution. To optimize screen space the design relies upon extra features, such as a hovering mouse pointer.

An improved Outlook calendar could include additional event/patient information in the hovering pop-up.

Jason

14

bradymiller wrote on Tuesday, June 16, 2009:

hey,
Committed the tree view calendar link change (moved it out of the patients section to the top) since nobody has seemed to disagree with this. It’ll show up in the cvs demo tomorrow AM; let me know if you don’t like it. Also, didn’t touch the sports team menu; Rod, let me know if you’d want this for those clients since it would be very easy for me to change that menu.
-brady