This is a mock up. I used this opportunity to learn CSS and JS. Of course I will make it better looking, as you can see the colors do not match very well. I just put together a page in a way I thought it wold be best. The hide/show menu is an inspiration from the latest apps from mobile world. You can see the way I wanted to be on this page: https://www.google.com/nexus/. Look at 3 lines button in the upper left. That is my aim.
‘Find Available’ is exactly what you think it is. Hopefully I can have that mocked up soon for a quick review.
I am also looking at a place where I could demo it live.
I could not find a free JS control that displays multiple resources. The only one I could find was this one: http://dhtmlx.com/docs/products/dhtmlxScheduler/index.shtml, but the one for multiple resources costs a cool $500. Just imagine that multiple providers are shown there.
As for patient summary screen, I take that as a challenge. Give me a few weeks and I will come up with something.
This is my third attempt to post a reply to you. Today SourceForge behaves strangely.
The reason you are not seeing the multiple resources there is because I could not find a free JS control to display multiple resources, the only one I could find costs $500 (http://dhtmlx.com/docs/products/dhtmlxScheduler/index.shtml), and I do not have that much money laying around. Just imagine that the functionality is there.
As for Patient Summary Screen, I take that as a challenge. Just give me a few weeks and I can come up with something.
I agree that we should use something to have a clear delimitation between front end, back end, business functionality. MVC is also used in iOS programming. I would like to see a database layer so it would make it easier to switch the back end. I would like to be able to use Postgres instead of MySQL as MySQL’s licensing future under the current master is problematic. I am all for looking at different MVC frameworks. I think we should also look at Yii framework http://www.yiiframework.com/.
We should pick the one that suits us best. I am ready to participate in this.
Hi Cesarus,
Sorry for the messages not getting posted. Sometimes sourceforge makes myself or Rod moderate messages. Have no clue why it does that.
-brady
Just wanted to post an update, as it’s been a while.
I’m putting together the Patient module using Zend Framework and Doctrine 2 as a proposal for where I’d like to see the project move towards. Work has taken away some of my free time to work on this, but I’m still trucking along, when I can.
The code I am working on will be unit tested and have at least 75% code coverage (Hopefully much closer to 100%).
I’d like to take a moment and apologize for the absence of any commits over the last 6 months; I’ve been dealing with a health issue that has made contributing to anything essentially impossible.
That being said, I am trying to continue my work. I’ve noticed a lot of change has happened in the last 6 months, and I think I’ll just stick to UI improvements for now, avoiding any of the back-end things.
My main goals:
1 - Finish the “Modern” theme
2 - Improve the way the left nav functions (Using cleaner fonts, vector-based images, etc.
Slow and steady wins the race - I’ll be taking small bites, I simply cannot afford to overwork myself.
Agreed. I’m working on something that should really help bring the UI up to par. I should have something to present soon (Although I’m moving Saturday, so my spare time is a bit tied up this week)
Do we have any metrics on the various navigation usage? I feel like sliding navigation is probably the most used type, not sure who is using radio buttons. I think dropping everything but the sliding navigation. Makes the codebase a little smaller, cleaner, and easier to maintain.
2nd question, what exactly does the concurrent_layout $GLOBAL do?
Just checked out your repo; looks like your plugging away. Agree sliding navigation is likely most used (if anybody disagrees, suggest posting that). Would anybody disagree to going to sliding navigation only as goal in future?
The concurrent_layout global holds the setting set in Adminsitration->GLobals->Appearance->Layout Style
Many users/developers with more updated OS’s will not be able to test your repo/branches, since you haven’t updated to most recent OpenEMR codebase (install breaks since your code still has the “PHP Fatal error: Cannot redeclare password_hash() in /var/www/openemr/library/authentication/password_hashing.php on line 104” bug which happens in more modern php versions).
I prefer the tree view because it’s more compact. If I cannot remember the location of a module, the tree gives a bird’s eye view and thus faster navigation.
The organization of radio buttons seems chaotic and unrelated to the other views. Modules are harder to locate.
I would vote for ditching the old style layout as well as the radio buttons, keeping the tree view and sliding menu. The last two have much in common and share much of the same code, and I agree with fsgl that the tree view has its advantages (and no disadvantages that I can see; surely it would be more popular if it were the default).
OpenEMR has outgrown the others - I’d be surprised if anyone uses them.
BTW any code supporting SQL-Ledger could also be excised.
Thanks for the feedback - I’ll work on pulling the old layouts from the code (while keeping the sliding layout and treeview).
I’ll also update my repo later tonight so it can be tested.
As I researched the best approach to revamping the UI, it looks like the best thing to do is utilize SASS. SASS is a pre-processor for CSS that adds a lot of flexibility to CSS. For instance, SASS allows the use of variables - which provides a great platform for allowing new themes to be created. We can build 1 css file with all the variables and instruct developers to just copy/paste that 1 file and make changes to the variables. When SASS gets compiled it puts everything into one nice tiny css file.
Also, it doesn’t look like I’ll be able to maintain total backwards-compatibility as I clean up the UI. A lot of the code is just written in ways of the old web (using tables for layouts instead of DIV’s, etc.).
I suggest we maybe agree on a large UI shift in perhaps Version 5? This way I (and anyone else who wants) can work on these changes while updates can continue to the 4.x branch.
