osverdlov wrote on Wednesday, May 11, 2016:
With Bootstrap we will get unified set of CSS classes and standard UI elements. In our opinion this will help to make UI better and this is super important for development.
bradymiller wrote on Thursday, May 12, 2016:
Hi,
First step will be to bring in bootstrap. No need to wait for Practice Provider to do this. Any thoughts on best way to bring it in?
-brady
OpenEMR
osverdlov wrote on Thursday, May 12, 2016:
I think we’ll need to create unified header for all pages to load jquery and bootstrap JS and CSS files. We’ll need to replace old jquery versions.
We’ll need some automation (bower/gulp, sass) to compile bootstrap and other assets in future. For now, I think we can manually copy compiled versions to wherever folder we want to store them.
To store the bootstrap package itself I suggest to adopt package management with composer. The packages will be stored in vendor/ folder and composer.json will contain a list of packages.
BTW Adopting composer and dependencies management has an added benefit - we can store 3rd party libraries in single place. This way, phpmailer, html2pdf, bootstrap, and any other 3rd party packages can be stored in one place.
robertdown wrote on Thursday, May 12, 2016:
First, we need to agree on a place for front-end 3rd party packages/libraries/anything we didn’t write. I suggest somewhere that is in the webroot.
Second, we need to put in place a dependency manager. I like composer for the PHP stuff and bower for the front end stuff.
Third, put everything in place.
I can handle steps two and three if we can come to a consensus on step one.
mdsupport wrote on Thursday, May 12, 2016:
+1 for package management and vendor/ as the go to directory to see what is already in use.
Re. unified header: We could use global.php to provide js file(s) with a named global instance of jQuery. Currently there are minimal javascript common functions provided by the project resulting in large server pages - a problem for slow connections. Would prefer a minified version of large js files cached on the device.
robertdown wrote on Thursday, May 12, 2016:
Can be remedied by using GulpJS to minify our JS. We keep the fully
expanded code for dev and a minified copy for serving up.
I can do this as well.
This would be a good opportunity to centralize all of our JS into a
local area (interfaces/assets/) for instance. Really need a place to
store JS/CSS/Fonts/images(yuck).
sunsetsystems wrote on Thursday, May 12, 2016:
I’d like to introduce some framework discussion at a higher level. Bootstrap uses a “mobile first” approach, i.e. top priority give to compatibility with mobile devices. Do y’all see that as a desirable direction for OpenEMR? Will the practical effect be to take a step back in the feature set on the desktop?
Consider especially what clinic managers want to see on the screen at the front desk… calendar, demographics page and all the stuff that currently goes along with it, etc. Docs are more likely to want a tablet. Or do many of them also prefer a desktop with a big screen? I expect you’ll find some of each. Would be nice to get some user input here.
I’m concerned about taking an approach that caters to the lowest common denominator. What’s good for public web sites is not necessarily what’s good for us.
Comments?
mdsupport wrote on Friday, May 13, 2016:
We need to add patients as a type of users. That means the UI framework needs to play well with existing components like wordpress, zend etc. on mobile and desktop platforms.
Are there issues with bootstrap 3/4 on desktop that aren’t correctable by @media?
robertdown wrote on Friday, May 13, 2016:
While it is true bootstrap is “mobile first” if you look at what that means, technically speaking, it is still fully compatible with desktop sites. Also, CSS frameworks offer a level of stability and consistency that is desperately needed in this project. The great thing about current framework development is the ease at which we can extend the features if we have a specific need.
Frameworks are not going anywhere. In the past there has been too much reluctancy towards accepting frameworks into OpenEMR. They need to be implemented in order to provide a long-term, viable future. I’m not speaking just about CSS, but PHP frameworks as well.
What is good for public website may not be good for us, but a CSS framework absolutely is.
I have been trying to refactor the UI for years and have become, at times, very disheartened by the resistance of developers on the forums. Speaking frankly for a moment, we may have a great product technically but we do not have a great product overall. Our user interface is not something to be proud of and the underlying code driving the UI (and likely most other components) is outdated, poorly written, and in need of serious improvements. I’ve often heard the phrase “if it’s not broke don’t fix it” used as a defense for not changing the UI, but I argue that the UI itself is broken from a visual standard and a technical standard. Just because we can twist antiquated code into a useable product does not mean we don’t have a problem.
sunsetsystems wrote on Friday, May 13, 2016:
Robert, thanks for your comments. I agree with you and am not trying to slow you down. It’s just that I have not seen much discussion at this level and want to make sure these questions are considered, and that we do things in a way that can easily adapt as frameworks evolve.
By the way are we talking Bootstrap 3 or 4? Big differences there, but it looks like 4 is not yet released.
robertdown wrote on Friday, May 13, 2016:
I would prefer to use Bootstrap 4 as it’s nearing an official release and simplifies a lot of components. I think we could probably wait until 4 is released.
osverdlov wrote on Friday, May 13, 2016:
I would suggest PHP execution should be disabled for that folder.
Both interface/ and library/ contain legacy PHP code.
We can place the files in a new folder, say, /themes.
library/themes/default/js
library/themes/default/images
library/themes/default/css
interface/themes/default/css
interface/themes/default/js
interface/themes/default/etc…
osverdlov wrote on Friday, May 13, 2016:
Rod, Bootstrap fits wonderfully in tablet and desktop as well.
According to this 2014 report, approx. 75% of US physicians own a tablet .
We can think about mobile support later, perhaps, using an application instead of mobile website.
robertdown wrote on Friday, May 13, 2016:
Oleg, what about interface/public? Then we could set the default bower_directory to “interface/public/vendor” and any custom code would be “interface/public/patient/demographics.js”
And any global assets could be “interface/public/assets/css(js, images, etc)”
Then we can load up the assets folder globally without bringing in specific stuff that may not be needed.
osverdlov wrote on Friday, May 13, 2016:
I suggest we look at components support. For v.3 there are datagrids, calendar widgets, RTL support. v.4 is not stable yet and a lot of 3rd party solutions may not have been ported/checked yet.
For our project we need RTL support, and v4 is a no-go for us due to lack of RTL support. We’d rather go with Foundation. The Bootstrap Dev Team plans RTL to be included in 4.2.x… may be not. For 3.x there’s great theme from GitHub - morteza/bootstrap-rtl: RTL Theme for Bootstrap v3.x
robertdown wrote on Friday, May 13, 2016:
A very compelling argument. I was unaware of the lack of RTL support in V4.
That’s a deal breaker indeed. Guess that means we stick with V3 for now.
osverdlov wrote on Friday, May 13, 2016:
Robert, thank you for agreeing on bootstrap version. Once we’ll get Bootstrap integrated into all pages, it will be less work to upgrade to new version.
robertdown wrote on Friday, May 13, 2016:
No problem.
Are you already working on incorporating bootstrap throughout? If not I can start that, shouldn’t be too dificult
mdsupport wrote on Friday, May 13, 2016:
Many contributions for this project are by users who have real world requirements but not much design background for application that has grown increasingly complex. For the sake of those users, would it be too hard to construct a demo/guideline page that provides working samples of widgets and techniques that you would recommend be followed in this project? Best home for this could be index.php of vendor directory or some kind of testing related directory.