bradymiller wrote on Wednesday, April 08, 2015:
hi,
This is rather awesome.
This can be tested in following “up for grabs” demo:
http://www.open-emr.org/wiki/index.php/Development_Demo#192.168.1.132
-brady
OpenEMR
mdsupport wrote on Thursday, April 09, 2015:
Could not figure out how font-awesome and style-light directories are used. Based on font-awesome’s examples, it may be an overkill for this textual application. Is style_light.css only relevant file in that commit?
ad848 wrote on Wednesday, April 15, 2015:
Hello Robert!
I want to see the demo of your work. Can you please tell me where can I get one. I have tried the link you have provided but the page shows me the link is broken.
Thank you!
robertdown wrote on Saturday, May 09, 2015:
Here’s a commit showing everything I’ve changed so far. It’s basically just a diff of all of my work versus the master branch. Working on the updated light theme · robertdown/openemr@7714901 · GitHub (Don’t fork this commit)
MD Support - The new theme utilizes CSS3. To be honest, I couldn’t even distinguish CSS2 anymore, I’ve been using CSS3 for years.
Also, the style-light folder is needed as I’m using SASS and Foundation. SASS is a CSS preprocess which does all kinds of awesome things like adding variables to CSS so we can reference colors 1 time and allow it to be updated throughout the file. Foundation is a CSS Framework (using SASS as well) that standardizes lots of common UI elements. You can read up on it here (http://foundation.zurb.com/). So the style_light folder contains all the required files to build the theme. I then run those files through a preprocess that converts it all to one file (style_light.css)
As for font-awesome - checkout the up for grabs IP tomorrow (Saturday, 5/9) to see an implementation of font-awesome in the left nav bar. Or see the attached screen shot.
Creating variables for fonts, colors, etc is something I’ve thought a lot about. I still haven’t figured out how to best implement that
robertdown wrote on Saturday, May 09, 2015:
To avoid some of the steps required to get to a new theme going, I’m gonna move all the preprocessing stuff to a new repo. Then the only change that will be introduced is the actual CSS file and any structural changes throughout the app.
This will actually help for future themes. It can serve as a good template for developing new themes under the improved workflow.
bradymiller wrote on Tuesday, May 12, 2015:
Hi,
Wow, pretty impressive and code is not intrusive(ie. styling is showing up everywhere nicely). I noted the links on top frame aren’t there (home,manual,logout). Also looks like the icons aren’t showing in left_nav.
When you have the main theme ready, is there a way to produce several other themes that can include as choices.
-brady
OpenEMR
bradymiller wrote on Tuesday, May 12, 2015:
BTW,
As reminder, this can be demo’d here:
http://www.open-emr.org/wiki/index.php/Development_Demo#192.168.1.132
mdsupport wrote on Wednesday, May 13, 2015:
Earlier suggestion about making variable colors related to need for personalization of colors and font sizes.
is there a way to produce several other themes that can include as choices
We currently use themes based on project provided css using directive like:
@import "style_metal.css";
...
...
background-color: PaleGoldenRod;
font-size: 0.9em;
...
...
Since many tags already specify colors and fonts, they end up requiring overrides thus defeating the advantages of cascades. A well designed theme will allow personalization by specifying few colors and base font size specifications. Currently adding a new css element involves updating several copies…
robertdown wrote on Wednesday, May 13, 2015:
The top frame links and left nav icons will be fixed in a commit later today.
Expanding on this theme - I’m currently putting together a “openemr.scss” file that will hold all sorts of variables including font’s, sizes, colors, etc, etc. This will allow someone to copy that skeleton file, customize it, process it into css and then they’d have the new theme.
Inline styling needs to go away. There’s little room for discussion on that. Centralized styling is absolutely key for future development.
mdsupport wrote on Wednesday, May 13, 2015:
Since the UI properties have been hard coded with various techniques, testing/implementing UI changes becomes tedious. You may want to consider a jQuery based approach we use to try out and in many case keep custom changes with minimal impact :
- Provide a hook in the standard code at the end
<?php
// mdsupport - include site specific changes by jQuery
$mytoks = explode('/',substr(\_\_FILE\_\_, strlen($GLOBALS['webserver_root'])));
$libLocal = $GLOBALS['webserver_root']."/custom/zutil.sfx.".implode('.', $mytoks);
include_once("$libLocal");
?>
- Put change logic in the /custom/zutil.sfx.<base file>. As an example, our zutil.sfx.interface.main.left_nav.php contains following lines:
// Rearrange menu layout
var d = $("form hr").last();
$("form table").first().insertAfter(d);
$("form center").first().insertAfter(d);
You can also apply new css - e.g. suppresses menu icons without getting into the left_nav.php logic with the following lines.
.nav-menu-img{
display:none;
}
#navigation-slide {
margin: 0;
padding: 0;
}
robertdown wrote on Wednesday, May 13, 2015:
I really think we need to begin cleaning up the UI structure, despite the challenges it may present. I suggest working towards a fully compliant HTML5/CSS3 based system. This will allow better long-term support and expand our abilities to really improve mobile and tablet UI
tmccormi wrote on Wednesday, May 13, 2015:
I agree with you 100% on this Robert. That has to include getting rid of the frames… 
–Tony
robertdown wrote on Wednesday, May 13, 2015:
I had a local branch going for a while, trying to build a single index page. The main content would be loaded via ajax… I shelved it to get this new UI done first. Getting rid of the frames is going to be quite the adventure.
tmccormi wrote on Wednesday, May 13, 2015:
Yes, yehster had a early shot at that, said the same thing, one beast at at time.
I think the thing to do is create a micro service that could be used to manage and communicate the ‘states’ and have ajax that updates the “divs” instead of the frames… but I’m just thinking out loud.
mdsupport wrote on Thursday, May 14, 2015:
While nobody would object to CSS3 driven HTML5 code, risk of creating unforeseen problems due to modifications of legacy code is only justified by adding new functionality. Users do not care how a page is constructed as long as it renders and responds as expected.
Our use of post-processing of standard pages allows us easy way to revert to standard. Also if necessary, a less skilled resource can work on the base code by using post-processor as a check list and do much more rigorous testing as time permits while users continue to benefit from efficiency of new UI.
In any case, looking forward to Robert’s project as the product really needs new lipstick.
tmccormi wrote on Thursday, May 14, 2015:
It’s a discussion I end up in all the time. With people that won’t look at OpenEMR because it’s ugly… but I have never had a actual user in a doctors complain or hardly even mention it.
It’s would be sweet not have new, potential user turned away at first look, however.
tmccormi wrote on Friday, May 15, 2015:
Here’s a UI and billing improvement I’m going to push up for review with some new reports. Let me know if this attached video works…
It adds the ability to use drag and drop to rearrange/re-order entries on the fee sheet to optimize billing. I’m told this is a critical feature by the billing folks…
teryhill wrote on Friday, May 15, 2015:
I can’t get it to play. Using quick time or windows media player wound up using VLC to play it on windows. Looks good
Terry
mdsupport wrote on Friday, May 15, 2015:
If you want to listen to complains of long term users and doctors, you have to watch them in action. Every ingenious workaround they have developed is a loud complaint that is being ignored by technology professionals who know ways to fix that problem…
sunsetsystems wrote on Friday, May 15, 2015:
It seems that if we ever support inpatient use it will be necessary to specify the time that each service is performed. Then it would be natural to order the line items by that. So I’m not sure this drag-and-drop feature will have lasting value.
What is the critical billing issue anyway?