I have been asked to do some UI work on the procedure order form.
I wanted to know has there been a bootstrap UI standard documented yet?
Hi @juggernautsei ,
This is something we need to work out and now is a good time. If we include
the user selected style sheet first, then followed by the bootstrap style,
does it look good? Another thing need to do when include the bootstrap
style is to include the bootstrapRTL(right to left), if needed. Here’s an
example of how to bring in the bootstrap stylesheet(s):
-brady
Bootstrap needs to be included before the user style. The Radiant theme is built using SCSS and bootstrap. The goal is to be bootstrap standard, however, because of the power of SCSS it’s possible to use any framework (Would just have to map the proper classes and ids to the framework).
Currently there is a fairly broken standard throughout the UI. Suggest checking out the SCSS file that the default theme is built upon https://en.wikipedia.org/wiki/Cross-origin_resource_sharing
@robert.down ,
I think when I’ve tried that in the past (bootstrap, then the custom
style), it has looked really bad, though(for example, the font-sizes were
not consistent with the style).
-brady
Was it with the Radiant theme or an old one?
Definitely was a non-Radiant theme. We should probably test to confirm this
and try both before and after to see which looks right. As themes develop
and we migrate to bootstrap “compliant” themes, then can always flip-flop
them all when ready in the future. Just don’t want to delay Sherwin’s work
too much on this.
-brady
Would love to begin deprecating the old themes
1 Like
We really need to leverage “cascade” part of css. Is there any specific benefit in requiring each script to have multiple css includes? When we made the switch to bootstrap, there were surprises but that is part of testing. We just keep adding local flavor at the end to override strange stuff.
Here is start of our standard theme based on style_light :
@import “style_light.css”;
@import “…/…/public/assets/bootstrap-3-3-4/dist/css/bootstrap.min.css”;
@import “…/…/public/assets/font-awesome-4-6-3/css/font-awesome.min.css”;
.color-primary-1 { color: #FFC4C4 } /* Lighter /
.color-primary-2 { color: #FFD9D9 } / : /
.color-primary-0 { color: #FFF6F6 } / Main Primary color /
.color-primary-3 { color: #FFECEC } / : /
.color-primary-4 { color: #E9D3D3 } / Darker */
body {
font-size: 12px; !important;
}
.css_button_small, ul.tabNav a {
font-weight: 800;
margin-right: 1px;
/* sliding doors padding */
padding: 0px 5px;
font-size: 12px;
}
…
That is helpful. So you are doing the custom spreadsheet followed by the
bootstrap stylesheet. The problem with hard-coding into a stylesheet like
that is can’t bring in the RTL(right-to-left) bootstrap when needed.
@robert.down’s approach works if style_light did not use elements basic to bootstrap. But it does and that clobbers bootstrap badly. So we start with existing stylesheet, let bootstrap override what it needs and then apply our lipstick on resulting pig.
Our objective was get away with standard stylesheet coming from globals/user preference. For standard codebase, it may be worth replacing
<link rel="stylesheet" href="<?php echo $css_header; ?>" type="text/css">
by a php include that provides a standardized way to manage css. That will give more flexibility to act on user preferences as well as vendor package changes etc.
On selfish note, it will give us a central place to add extra code to every script if needed.
In any case, for a casual developer css should be a single line somewhere before start of body tag.
The goal of the new theme was to include all the works in 1 file. I use gulp and bower to bring in bootstrap in before making changes. I have a custom variables SCSS file which override the default bootstrap variables (not uncommon when using SCSS/LESS and bootstrap).
When I build the theme, bootstrap gets put in at the top of the finished CSS (Except where I’ve overridden variables).
Instead of replacing the link tag, we should be utilizing a header template which allows us to do all the repetitive HTML only once. There should be only 1 CSS file, a fully compiled and minified file. We then offer specific hooks for vendors to manipulate the header file. Users can already select their theme.
Overall, we need to tear apart the view layer and get up to the proper HTML5 standards and get bootstrap-based class names throughout the UI.
1 Like
At the risk of sounding inept, it seems that the bootstrap should be pushed out in the link above. I think that is what MDSupport is implying. For the casual developer, it would take the burden off of having to include all of the bootstrap links manually. It would be great if the bootstrap was a one liner.
Because for me the UI is a byproduct of the code behind the UI. The UI is not my main focus although I am forced to think about it from time to time.
While the discussion of style sheets here is very interesting and I do understand what is being suggested. I do hope this leads to a standard being set in place to push out the bootstrap in a one-liner.
Since we can’t upload files here to put some visual context to this topic. I have a before and after shot of the procedure order form.
Before bootstrap:
http://www.openmedpractice.com/os/sites/default/files/procedure_order_old_ui.png
After adding bootstrap:
http://www.openmedpractice.com/os/sites/default/files/procedure_order_new_ui.png
It was a chore to find all the pieces to the code that made up the UI. I got 90% of it changed out.
I will post the code next week so I can be told what is the incorrect with the methodology use to achieve the frontend view.
We’re aware of the uploading issue (working on it right now actually).
What theme are you using? Can you try the Radiant theme and see how that goes?
Apologies, meant no offense by the comment about uploading
Sherwin
757-328-2736
Open Med Practice
www.openmedpractice.com
OpenEMR Simplicity at its best in cloud based EMR’s
“For those who believe, no proof is necessary. For those who don’t believe,
no proof is possible http://beingsaved.org/innercoc.va.”
No offense taken! Just making a note so people know we are in fact trying to fix 
Image uploads are working again! Drag and drop into the reply box
What about something like this to standardize the headers:
Note there are 2 example. The first was where Matthew already converted a script to boostrap(disregard the jquery error, that was from a prior script) and the second is how it looks in a script that has not yet been converted(ie. it didn’t screw anything up). The nice thing about this mechanism is we can change it as the ui project progresses (could even add custom parameters if for example, needed to use a lower jquery version). thoughts?
-brady
OpenEMR
It also just hit me that the following would solve the issue where forms can have broken jquery libraries as we upgrade to newer jquery version, since they will now just simply bring in this header and use the standard jquery library.
-brady
Best practice is to make css available as page is built and load scripts at the end.
To @juggernautsei’s point, just like globals.php simplifies developer’s life by taking care of database stuff, there should be a single line to bring in user’s choice of css and another line in the footer to bring in scripts.
To be clear, for starters end users require pleasant basic look and feel. Then they want “their” colors and font sizes etc. - which is what legacy style_xxx copies provided. So even after a single css file, we should provide for localization.
jquery provides for a way to handle multiple version using noConflict.
var ejQ = $.noConflict(true);
If you want openemr’s version to be always isolated, use ejQ instead of $ in all openemr’s standard javascript code. Or let scripts needing a specific version of jQ take this approach.