UI Improvements

OpenEMR Development
141

robertdown wrote on Friday, May 15, 2015:

I disagree. At some point we need move towards a clean and strong HTML base and stop building on legacy code. By continuing to build on old code we really make it difficult to create future improvements/new features/etc. The user may not see a difference, but bringing up the HTML/CSS to today’s standards is in fact new functionality.

142

rnagul wrote on Friday, May 15, 2015:

New HTML/CSS sounds like a great idea. Bootstrap is a very popular library
to use.

We need to attack this from the core though. With the data, view and
busines logic married into one, the current design pattern for OpenEMR is
highly limiting to create workflows that a clinic may need. It is very
early 1990s, we need to separate the data layer and the view so the
front-end can be made responsive

Ramesh

On Fri, May 15, 2015 at 11:15 AM, Robert Down robertdown@users.sf.net
wrote:

I disagree. At some point we need move towards a clean and strong HTML
base and stop building on legacy code. By continuing to build on old code
we really make it difficult to create future improvements/new features/etc.
The user may not see a difference, but bringing up the HTML/CSS to today’s
standards is in fact new functionality.

UI Improvements
https://sourceforge.net/p/openemr/discussion/202506/thread/5ddd6d1e/?limit=25&page=5#5803/3127

Sent from sourceforge.net because you indicated interest in
OpenEMR / Discussion / Developers

To unsubscribe from further messages, please visit
SourceForge.net: Log In to SourceForge.net

–

[image: >] http://www.audioname.com/rameshnagulRamesh Nagul
Hear my name http://www.audioname.com/rameshnagul

143

sunsetsystems wrote on Friday, May 15, 2015:

To restate something I’ve said a few times before: It would work best to first create and use an object oriented PHP data model that is invoked as appropriate wherever database access is currently done. That can be done in small pieces that are easily reviewed and brought into the project.

Once that is in place it will be much easier to redo the user interface and/or implement different user interfaces for different client platforms.

Rod
http://www.sunsetsystems.com/

144

mdsupport wrote on Friday, May 15, 2015:

I think I am not communicating well. As stated earlier, nobody would object to a shiny interface. But when dealing with large legacy code whose reliability is paramount, if you do not take incremental approach, benefits of your efforts will not be realized by users for several months. At worst if you loose interest after 6 months, your work product will never be released. I realize there is some extra work involved in allowing legacy code to work side by side with new, but that is the price for ensuring business continuity.

145

juggernautsei wrote on Friday, May 15, 2015:

I took the time to read this entire thread from the beginning to now. It is a very positive thing to have an updated UI. It will be appreciated by most and not liked by some but that will happen no matter what.

I do agree that the legacy code needs to be brought up to date. It is a matter of who will under take the extensive re-factoring of the major modules that are the heart of this application.

I know it will get done in the future. I have seen a lot of great things happen in the last 3 years I have been working around this community. The community will breed the right environment for someone to come along and desire to make those extensive rewrites to propel the project into the next decade.

As Rod always say, “piece mill” all the way!

To Robert, my hat is off to you sir!

146

tmccormi wrote on Friday, May 15, 2015:

Rod Wrote:
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?

What I am being told by several of my customers that that the billers can optimize payments and reimbursement if the reorganize the order that charges are listed on the claims. Typically this is highest cost item first, but not always and they want full flexibility.

OpenEMR is not an in-patient tool, but this enhancement is not intrusive if you don’t rearrange the codes they aren’t effected.

147

robertdown wrote on Friday, May 15, 2015:

I’ve been itching to do this! However, I for some reason though this wasn’t something that was wanted by the community. I agree that would make things a LOT easier in the UI realm.

148

robertdown wrote on Saturday, May 16, 2015:

Here’s a squashed tag of my demographics branch. I put together a quick Patient model, not by any means exhaustive, but something that we can work on. Clean demographics syntax, add Patient module · robertdown/openemr@0a9dc61 · GitHub

I make no promises as to how this looks in a UI (I’ve got my style_light.css theme activated on my local instance, I think the old styles are a bit broken. Brady and I discussed a while back that as each page gets modernized we lock that page down (Force the new theme in). Once we’ve gotten all the pages modernized we unlock the themes and users can then develop their own themes based on the new structure. I know it’s not ideal to essentially take away the ability to have custom themes, but it’ll only be temporary, plus it’d be incredibly difficult to attempt to support the old and new structure.

This snapshot is geared more towards the Patient module and the Entity class inside. You can see how it gets implemented in the demographics page - it’s much, much cleaner HTML.

I’m looking at patients.inc and copying/refactoring code that is referenced there into the Entity.php file as I come across it in demographics.php

I hope that all makes sense.

149

robertdown wrote on Sunday, May 17, 2015:

150

robertdown wrote on Monday, May 18, 2015:

Code Review Request:

What’s going on in this commit:

Setup an AutoLoader to begin to ease the use of require statements. For instance, the patient module I’m working on will be located in library/Patient/src/ but instead of managing the path depending on where I’m at in the code, you can now just use

<?php 
use OpenEMR\Patient\<ClassNameHere>;
$patient = new OpenEMR\Patient\ClassNameHere(); // or
$patient = new ClassNameHere();

and it’ll just work

This should be utilized as it:

  1. promotes modularized development
  2. reduces the risk of error by lessening the burden of require_once statements and
  3. falls in line with modern PHP development practice. This is common practice.

There is also a ViewHelper module, where I began transposing various helper function into. For instance, you can now call

<?php 
$formatted = ViewHelper->money($amount, $symbol)

and be given back a proper currency string. This is essentially moving various functions found in .inc files into a central class that makes a bit more sense in terms of nomenclature.

This should be implemented as again it promotes modularization of code, keeping functions out of the global namespace and improving re usability.

I am working on a Patient module that will be the central interaction point for a patient, but I choose to leave it off from this code review as I want this first step to be clear and concise.

151

tmccormi wrote on Monday, May 18, 2015:

I thought I’d play with the theme generator, but I’m not familiar with npm, bower or grunt so I didn’t get very far with the readme.

I installed npm, but could figure out the next step, bower and grunt are not available from apt-get

Not clear what is meant by the “root of the starlight” directory.

I guess it not really necessary of you have posted the openemr_light.css already.

152

robertdown wrote on Wednesday, May 20, 2015:

I wrote that README far too quickly. I’ll update with better documentation.

Edit: From the updated documentation

$ git clone git@github.com:robertdown/openemr-light-theme.git .
$ cd openemr-light-theme
$ npm install // Installs Grunt and Bower from npm via package.json
$ bower install // Grabs the various assets (i.e. Foundation)
$ grunt // Build files and place final output to css/style_light.css
153

robertdown wrote on Tuesday, May 26, 2015:

An interesting read: https://medium.com/tragic-design/how-bad-ux-killed-jenny-ef915419879e

154

robertdown wrote on Tuesday, June 02, 2015:

While waiting for a code review to be processed I began work on the next screen - Add/Edit Event. Here are a couple of screenshots. The form is now responsive, so it will look much nicer on tiny screens, and expand to still look good on larger screens.

155

bradymiller wrote on Thursday, June 11, 2015:

Hi Robert,

Where’s the most recent UI code at? I was hoping to focus on the UI stuff for now.

thanks,
-brady
OpenEMR

156

sapiens110 wrote on Sunday, July 05, 2015:

Hi Robert

We are keeping close look on your work and will be more than happy to have your most recent code to test. Is this something you’re still working on?

157

jayeshcp wrote on Monday, July 27, 2015:

I am new here, however have worked with bootstrap ui enhancements earlier and would like to know if there is any specific section/module where I can contribute ?

If any help is needed ,let me know.

Thanks.

158

robertovasquez wrote on Monday, July 27, 2015:

Hi Jay
You may take a look of the Active Projects page at
http://www.open-emr.org/wiki/index.php/Active_Projects

159

yaronbs wrote on Wednesday, September 02, 2015:

I was wondering what is the status of this project and how can one see the revised code?

160

bradymiller wrote on Friday, September 04, 2015:

Hi,

This UI project isn’t getting the attention it deserves since we have all been focused on MU2 stuff. Robert’s ongoing work can be found in these branches:

-brady
OpenEMR