Default Visual Layout

OpenEMR Development
1

bradymiller wrote on Wednesday, April 08, 2009:

hey,

Since were at beginning of another developement cycle thought it would be a good idea to consider changing our default layout configuration.  We currently use the frames with radio buttons, but also traditional and frames with tree view exist. Heres’ a link with screenshots in case you don’t know what I’m talking about:
http://www.oemr.org/modules/wiwimod/index.php?page=LayoutSelection

So the question is should we move to Frames with tree view as our default?

-brady

2

tmccormi wrote on Wednesday, April 08, 2009:

I think we should default to the tree view, it looks more professional,  but I am with Joe on this:  Each user should be able to set the defaults of both the menu system preferred AND what things show up in the top and bottom frame at first login.

Frankly I like the radio buttons myself because I can control what displays where on the fly.  I haven’t tried the tree view yet, does it have the 'Top/Bot" feature?

Tony

3

ideaman911 wrote on Wednesday, April 08, 2009:

Brady;

As you’ll note elsewhere, Dr Bowen’s Magnificent Machine for Windows has been defaulted to the tree view.  I prefer the radio (what has been the default while I’ve been aware), in part because the Tree does not allow some functions I use, specifically the Receipt (which I also print for billing).

My suggestion as noted elsewhere is to allow the user for each session to select their own via a dropdown on the login page as part of the next release.

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

4

tmccormi wrote on Wednesday, April 08, 2009:

Which brings up the obvious suggestion:
ALL menu options should have the same choices and features regardless of the presentation.

–Tony

5

cfapress wrote on Thursday, April 09, 2009:

I prefer the top-menu style, which is the oldest style and not a default. I’d like to spruce it up a bit and allow the menus to become drop-down styles. Imagine the tree-view but presented horizontally.

Why do I prefer this? Because many of my users run their screens at 800x600. Have you tried the tree view at that resolution? If so, you’ve seen that the patient search, logout, and popup menu all disappear. The constant need to scroll that left-side frame up and down become a barrier to efficient work.

I could force all users to run at 1024x768 but some find the text too small at that resolution. I agree with them that the text size and color choices can make it difficult to work in OpenEMR. As an example, the Demographics screen for a patient. When editing a patient’s demographics there is only the tiny blue text at the bottom labeled ‘Save Patient Demographics’. With the Aqua background the link is very difficult to see.

During my development I’ve been working to get all styling moved out to the ‘themes’ folder and into a CSS file. Also, I’ve been replacing links with buttons where appropriate. Typically when a user fills in a form they expect to see a submit button, not a text link. I understand that the text links were used because the original author was using javascript to submit the form and it was expedient to embed the JS right into the HREF attribute of the link. I’ve been moving away from that and using jQuery for form submissions. Doing so opens up a whole new world for client-side form validation.

But I’m digressing too far.

My point is… Could we move the search, popup, and logout stuff to the top-bar on the screen in the Tree-View navigation?

Logout - place next to the name of the user logged in, instead of the word ‘Default’

Search - place next to the ‘Active Patient’, use Tony’s new “free form” search

Popup list - place next to the ‘Active Patient’, after one has been chosen

Jason

6

bradymiller wrote on Friday, April 10, 2009:

Jason,

Sounds good to me.  So should we just change our default to treeview in cvs to give longest amount of testing/devel time before next release?

Also, as an aside, you up for making your calendar the default, which seems to be the current consensus.  This will maximize time to test/devel and make ‘new appt’ stuff a bit more intuitive before next release?

-brady

7

tmccormi wrote on Friday, April 10, 2009:

I concur :slight_smile:
–Tony

8

ideaman911 wrote on Saturday, April 11, 2009:

Guys;

As usual, I’m the odd man out.  And that’s OK because we need people who can tell the Emperor when he’s naked :wink:

Since we have gone to the trouble of developing code which we have released with other defaults, why do we want to change the defaults?  Why did we make those others the defaults at their respective times?

It’s not a problem per se to do so, but we should not PREVENT former users from continuing to do what they know to do.  One of the MOST infuriating things in Windows versions is the changing of HOW the exact same thing gets done, forcing an expensive learning curve at exactly ZERO benefit.  Put yourselves in the position of Help Desk, which I’ll bet you have been.  What added costs will YOU have to absorb in doing so?

In any case, the one absolute I agree with is that we must make all functions operable in whatever "look" we make available.  We SHOULD also make the selection of those alternative "styles" as easily done by USERS as possible without the need for us "wizards".  If we depend on silly stuff like such changes for our revenue streams we are on life support at best.  Better to charge more for truly beneficial changes - the customers will appreciate you MORE.

That all said, I recognize that sometimes you must cut the umbilical.  I have long realized that Engineers are never "finished" with anything, because they always see another way they can "improve" it.  So there comes a time in every project where you shoot the Engineer and build to the last Rev level :wink:

If SUPPORTING all those varieties of “look” is too costly for all the features we add, and as a means of determining the current user base, perhaps we should post on the login screen of our next release that we intend to eliminate whatever “look” we wish to no longer support, with an effective date at least six months hence, and request comments be emailed to a “whattyathink?” address.  I will be happy to provide mailbox, monitor and compile the results of such “survey”.  I just don’t know how to code it for the screen, and I’ll compile email addresses of senders in an Excel file, so you can all figure how to look at a Windows file, like I’ve had to adapt to yours :wink:

That way we might determine if we techies have totally different opinions on preferred usability from our clients.  Any better ideas?

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

9

aperezcrespo wrote on Monday, April 13, 2009:

Hi
  Well it seems we happen to have three (3) Visual layouts and different users have different preferences.  (I for one like the tree).  Why dont we just move options in Global.php into Mysql and allow these to be end-user options.
Also it seem that the same options should be the same in all three visual layouts.  Shouldn’t these options also endup in the data base (Something like lists and Layouts)?
I’m not much of a developer so I maybe talking nonsense (my wife loves it when I talk nonsense, It gives her the edge on arguments.)

Just a thought.
Thanks

10

cfapress wrote on Monday, April 13, 2009:

I believe it would be best to introduce a new table to the database named ‘user_prefs’. In that table would be all of the things a user can customize such as layout, theme, calendar style, default practicioners, date-time style, currency style, language, etc. Whenever a user logged into OpenEMR these defaults would be loaded into the SESSION variable and applied to each page.

That is merely an extension of what is being done now. Currently a user’s calendar style is loaded into the SESSION from the users table. See <oemr>/library/auth.inc around line 90.

I think would be smarter to separate the user’s preferences from the account data. What does everyone else think?

Jason

11

sunsetsystems wrote on Monday, April 13, 2009:

I would avoid creating a new table that just maps 1:1 with another table.  However if what you have in mind is a separate row for each preference variable (e.g. the unique key would be user ID and preference name), then a separate table is certainly in order.

Rod
www.sunsetsystems.com

12

tmccormi wrote on Monday, April 13, 2009:

I agree with Rod on that.  A table with rows by preference name allows for future flexibility and customization.   I would go a far as including it in the Lists tool least.

Tony

13

bradymiller wrote on Monday, April 13, 2009:

Jason,
  Agree with removing these things that are now hard-coded in globals.php.   This is very pertinent to what I’m doing with the translations stuff:
https://sourceforge.net/forum/forum.php?thread_id=3205507&forum_id=202506

Let me know what you end up doing, since one of the major things I want to set up is a default language per user.

-brady

14

sunsetsystems wrote on Monday, April 13, 2009:

In addition to user-specific preferences, we’re going to want an administrative interface for site-wide preferences that are currently in globals.php.  This latter part is something I was planning to work on soon.

Rod
www.sunsetsystems.com

15

ideaman911 wrote on Tuesday, April 14, 2009:

Folks;

Since we already have a "Users" database, why not put the "prefs" in as a number comprised of the sum of the values generated from the selection of those "preferences".  So, for example, assigning the Tree, radio or original to units digit, the calendar to tens, etc., would allow each user to make their selection at their "preferences" screen, and then anytime THEY login, that workstation session will follow those preferences.  In the example above, my JCH would be 11 since like the fancy calendar and radio button view.

And that way the user ID will be the thread which controls the display even if we have multiple sessions open in a single tabbed browser, as for example the South African multi-lingual needs.

Just thinking out loud.

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