User Interface Design Style Guide - The Beginnings

OpenEMR Development
#7

I have done a first pass through the entire UI for v5.0.1-dev and came up with an outline of the global components, navigational elements, icons, forms, buttons, messaging and lists/tables currently in use.

You can find this inventory on google drive: https://docs.google.com/presentation/d/1KEHyAw6KfaVEVKyXxLKjlsU0R_bImCrUgc_Ywr_76ik/edit?usp=sharing

All those who are interested should definitely check out the sheer number of ways we do the same thing in this project and leave comments on those they love (or loathe)!

In addition, I need some help discerning what is modifiable in the code base and what is not. For example, if we have 3rd party components that we cannot modify easily (or do not wish to for copyright/other reasons), then their screenshots should go in the 3rd Party page.

Finally, for those who know the code base better than I do, I’d like to direct your attention to the Image Types, Headings, and Color pages. In these pages, I’d like to capture the different ways that images are represented (both user uploaded and embedded in the code), how headings are used throughout the application (including text elements that look like headings, but are really just cleverly-styled divs), and every single color that is used (including those not necessarily specified within a theme.

With this inventory, I hope we can better understand the variances between implementation of common elements throughout OpenEMR. With just the screenshots that are currently captured, for instance, it’s easy to see that we have way too many types of buttons.

Feel free to add any screenshots I may have missed or leave comments on ones I may have captured incorrectly :slight_smile:

3 Likes
#8

hi @d3sandoval ,

Very nice work! So many buttons to choose from :smile:

-brady

1 Like
#9

hi @d3sandoval

Great to see your effort in getting the UI standardized. I have tried to get a unified look and feel to openEMR. Please look at the result of my efforts at https://three.openemr.io/openemr/interface/login/login.php?site=default. There are several pages where I have tried to make the UI easier to use including easy to access help files.

I am excited and hopeful that the UI will come to reflect the underlying beauty of this amazing open source effort.

3 Likes
#10

Thanks for sharing that! Great to see the direction you’re going - especially regarding table and text/button hierarchy. Do you have a branch/fork anywhere that might hint at what changes you’ve made to achieve the look?

I especially like that you pulled the patient search out of the top header and moved it into its own distinct header.

Given the work that you’ve already done, I’d love to go off and build a style guide around your implementation! This will make it easier to keep the UX consistent as we modify existing features and develop new ones.

#11

Fork: GitHub - zbig01/openemr: Official OpenEMR repository
Current PR: Zbig01 new encounter improvements by bradymiller · Pull Request #1257 · openemr/openemr · GitHub
Old PR: #1076 , #993, #838

Please read comments in previous closed PR

#12

I’ve spent the weekend putting together the first outline of the living style guide here: http://openemr-interface.surge.sh/ - it’s pretty barebones but it shows how most standard web components are affected by our themes :slight_smile:

As a byproduct of having to integrate our css files with fabricator’s build system, I standardized the composition of the three different “theme” types and their “rtl” variants: openemr/interface/themes/src/assets/toolkit/styles at styleguide · d3sandoval/openemr · GitHub

This is all done through gulp and scss. For more info, feel free to dig through the gulpfile or checkout the README!

My current todo list is as follows:

  • Add a lot of documentation on current component usage (including migrating the “buttons at the bottom of form” sections, below)
  • Migrate style dependencies in the php code to use the /dist directory
  • Migrate component css still left in the /themes directory into scss in /src/assets

I think I’m going to need @robert.down’s help to replicate the themeBuilder.php in scss and probably @brady.miller’s assistance in the epic find-and-replace that will have to occur to get the code to look for css files in /interface/themes/dist instead of just in the root /interface/themes directory.

I spent a bit of time attempting to get all the files to end up in their original place but it led to a mess and made it difficult for Fabricator to share nicely. It’s best practice to not commit generated css files if you’re using a preprocessor like scss/less/etc. anyway… since developers should have one source of truth when changing style sheets. This will most likely mean adding a build step to run a prod version of the gulpfile so that servers/containers running openEMR have the generated css files they need to serve up pages :slight_smile:

So I feel like this is off to a great start! I can’t wait to dive into breaking down the interface into navigable pieces for contributors to explore. As always, please do send along any feedback you may have or ideas for how to make this thing better.

1 Like
#13

Hi,
wow, this is some really neat stuff. I ran through the commands above and some really neat stuff happened. So, if I needed to update a style, where would I do this?(I hope this isn’t too stupid of a question :slight_smile: )
-brady

#14

Not a stupid question at all. I’ve filmed a video that shows how you would make changes the style sheets and see those changes propagate across the style guide: https://drive.google.com/file/d/1Zn3DCuZR68YMK73JWCBmVQUiHo4Q9lYH/view?usp=sharing

One thing I did not cover is how to update the src/materials/components .html files to document the styles themselves. This is because I’m still working out a few kinks with the dependencies in the /public folder. I think I’ll have to document a few existing interface components before I get the hang of using all of our external libraries… I’m trying not to move any files I don’t have to…

#15

@d3sandoval, the other week when I visited Google Cloud Platform’s console for the first time, I was so stunned with how modern/polished the UI I was talking to myself (e.g.: “this is amazing!”, “this is from the future…”).

Had a similar moment clicking on your demo just now. Great work!

-m

1 Like
#16

been having a similar question so i am super thankful for answering it! also lots of thanks for the drive link, found some really useful things. can i ask you questions in case i would have some? thanks!

#17

Bring on the questions! This is definitely still a work in progress and I have a feeling I’ll learn a lot when I start integrating demos of our PHP components from the /interface directory :slight_smile:

1 Like
#18

hi @d3sandoval ,

Very nice!

Does it make sense to get this into the codebase soon(would go to 5.0.2-dev and not the 5.0.1 since will be released soon) or is more work needed so it doesn’t break anything. Then would force developers to start learning how to use this.

Also, I know this is against all standard procedures, but would be far easier for a multitude of reasons to actually include the css scripts in the same places they are now (and we would have a hard rule that these css can not be touched unless done the correct way via scss changes).

thanks,
-brady

#19

@brady.miller only a bit more work is needed to get this working. Once I get a basic component working in the Fabricator view, I’ll dive into getting a “production” build working that outputs the files into their original location.

I think one natural deterrent to editing css directly will be to minify the generated css so the only logical place to edit it would be in the scss versions. We can also add a comment to the top of the generated filed that points devs to the right place to edit the styles…

I’ll create a proof-of-concept this weekend and run through the golden paths to verify I didn’t break anything.

#20

I’ll have time to really delve into this over the weekend. School is almost done for the semester, can’t wait to get to work on this. Super exciting times!

#21

@d3sandoval The light theme is built using SCSS - You have no idea how ready I am for everything to be standardized and properly built out with SCSS.

Agree that production CSS will need to be minified and we’d never allow a manually edited CSS file into the codebase.

The theme builder script is going to be tricky. Because we want each user to be able to have their own font size and family, we may end up with a “base” CSS file and then the custom file to allow the user to modify. I’m not sure I see a way to integrate using SCSS w/o re-compiling as a separate theme (style_light–user-.css) which is a bad idea.

#22

Hi Design Team (@robert.down, @d3sandoval, @irakojf, @zbig01, @brady.miller),

Please meet Rachel Ceasar, PhD (@R.Ceasar on the forums). She wishes to join in with your exciting UI/UX efforts!

Here is her background: Rachel is a medical anthropologist and design strategist that uses design thinking and qualitative research to guide health tech professionals to develop more human-centered products and services.

Please welcome her to the team!

@d3sandoval, can you summarize your OpenEMR design research with Rachel?

-m

#23

Great to meet you @R.Ceasar! We are currently conducting a design inventory for OpenEMR and building out a living style guide to make building and updating application interface elements easy for contributors.

These tools will allow us to have the necessary conversations about how to update the platform with a more consistent and usable UI. A lot of good work has already been done by @zbig01 , @robert.down and @brady.miller in moving the UI to more-familiar bootstrap conventions. As we continue to update each set of screens and components, these changes will likely need to be tested with real users and monitored “in the wild”. I’m not sure if there is a plan for this in the works… it’s probably too early to say.

Real world testing will allow us to measure whether these changes are meeting the goals of “Consistency”, “Usability” and any other goals we have yet to agree on :wink:

@R.Ceasar I’m looking forward to hearing what part of this work you find the most interest and/or if you have any other ideas on how we can make an open source project as collaborative and diverse as OpenEMR look and feel familiar to its end-users.

1 Like
#24

Thanks to @brady.miller, the docker setup is significantly easier and has allowed me to test my theme workflow in a working development application.

I filmed a video of a trivial change to show how I will be approaching de-dupeing a lot of our theme files: https://drive.google.com/file/d/1HoGoWNOcO-t7oiwVFzWxlskbhz2oilko/view?usp=sharing

Next step is to get to a consistent set of base themes and overrides (similar to the core.css imports we currently have) so that we don’t have three deviating themes. A PR on this should be on its way this weekend or in the coming week.

2 Likes
Documentation and Codebase
#25

Great work, @d3sandoval!

1 Like
#26

Update! My first massive PR of this effort has been created: Styleguide and theme code de-duplication by d3sandoval · Pull Request #1651 · openemr/openemr · GitHub

Those interested, please have a look :slight_smile:

3 Likes