Child pages
  • Summary of meeting minutes
Skip to end of metadata
Go to start of metadata

All Recordings of meetings are stored in a google folder which can be found here : https://drive.google.com/drive/folders/16YDMfHWiFoUpqu61DQxLk9EnZTHhBKSq?usp=sharing

DatePage
8/15/2019

https://notes.openmrs.org/2019-08-15-microfrontend

Agenda for the Meeting:

  1. Demo of login MF application (https://openmrs-spa.org/openmrs/spa/login 2). If interested, please see code at https://github.com/openmrs/openmrs-esm-login)

  2. Discussion of Patient Search Design (https://www.figma.com/file/0bNhP3xm4tB7rMwpMZe51n/Search?node-id=0%3A1 2)

  3. Sprint Planning For Remaining Login Tickets and Patient Search Widget .

  4. Overview of style guide (please take a look as much has been added in past week: https://styleguide.openmrs.org 1). Code available at (https://github.com/openmrs/openmrs-esm-styleguide 1)

Action Items for the Next Meeting:


    1. Review designs and finalize on presentations for today.
    2. Joel , Antony , Bradon to work on creating a  local dev frontend documentation for startup, packaging  into a WAR file
    3. New additional Members from Ampath Donald, Jacinta and Enchil
 Sprint planning:
        Tickets will be created and assigned to team members. Aim to have Demo for Main Nav and Patient Search
        Members are encouraged to PR small amounts of code rather than large batches. 


See blogpost from Greg on responsive breakpoints: https://docs.google.com/document/d/1nk1uWd5UxE1DB1SdeNG4HfChXuB9gqXUEvs7uCwiHQ8/edit#heading=h.rbs2o24gvylu

8/08/2019

The focus of the call will be to shift to work mode and begin actual development work.

Agenda for the call will be 

  1. Updates from Joel who posted a number of slack updates:
  2. Planning meeting on next steps with an aim to have a login and dummy landing page by next week (aug. 15th) This will lay the groundwork on how to add code to the ongoing design work.
  3. Introduction of the design process so far

  1. Presentation by Joel:

I published all our frontend code to npm. See https://www.npmjs.com/search?q=%40openmrs%2Fesm

- I renamed the in-browser js modules from @openmrs/name to @openmrs/esm-name to match the repo’s name.

- The styleguide documentation website is now hosted at https://styleguide.openmrs.org

- I created a PR that adds a primary-navigation and patient-dashboard applications. Please review it at https://github.com/openmrs/openmrs-esm-root-config/pull/16

- I created a PR that starts migrating esm-login to use the styleguide. Please review it at https://github.com/openmrs/openmrs-esm-login/pull/7

- I created a new import map for openmrs-spa.org. The hackathon one still exists in Digital Ocean but is no longer used.

- I created Github releases and release notes for each of the published packages. Example at https://github.com/openmrs/openmrs-esm-styleguide/releases

- I published browserslist-config-openmrs. More details at https://github.com/openmrs/browserslist-config-openmrs about what that is

- I installed fork-ts-checker-webpack-plugin in each of our typescript projects, which will surface typescript errors earlier on before you try to commit.


Style Guide:

Questions were raised on how best to bundle and package the work that has been done so far as well as how to replicate on a local server.? 

Ans: 

We are using CSS Loader and Style loader where its bundled into a javascript module that loads a CSS file. Essentially we are importing all of these CSS files as CSS files. 

This style guide ,(JS file ) is made available through the index.html file. So these are global styles that are available to any module within the project.

Process creating or making addition to the Style Guide:

  1. As features are developed the designer, as they recognize the need for additional let's say atomic elements, they will create issues on JIRA saying what they need and then a link to whatever tool for now FIGMA,  to provide guidance to the developer.
  2.  At that point we will have to identify a developer to create that component added to the style guide.

  3. Once the PR is accepted into the style guide, then  at some point, my guess is through some continuous integration independent deployment that style guide will be the style guide that JS file will get updated with the new feature and become available within any module that's operating under the OpenMRS spa module; When merged into Master, it automatically updates the documentation site and updates OpenMRSspa.org 

If you do face some bottlenecks:

you can override your CSS, you can write your own CSS for your code. Other options for overriding  One of them is simply don't use the CSS class that is in the style guide and use your own CSS class.

The other one is use the CSS class in the style guide, but then add your own CSS class that adds or modifies some of the CSS properties.

And using specific CSS selectors, or even exclamation point important within your CSS to make sure that it overrides what's in the style guide.

The third option is if you really don't like what's in the style guide a lot, then you can override the entire style guide module itself and use one that you maintain

Maybe beyond overriding colors, for instance, because that's something people think of often

Just for simplicity. Right now, the colors which are being used are purely functional like there's an interaction color which is blue, and there’s an alert color red, green success color. There's no brand colors anywhere currently in the style guide.

At a later date when there are more functionalities it may be possible to make edits in one area, which cascade through the whole UI. This is not being covered at this time.


OpenMRS Flow:

UX/UI  work for the week 

https://issues.openmrs.org/browse/MF-22 

 

This was presented for discussion and review.This page is going to basically show up as the primary page just like everybody else has opened Mrs implementation does right now. It will take the Username and password and send a request to session API to authenticate. 

Entering the “Location” will be discussed at a later date.

Process for Application development:

Initial tickets will be created to define what needs to be done. These can be modified as necessary.

After a PR is done, the creator of the PR will assign it to a squad member within 24 hours. The squad member will then have 1 week to provide feedback or approve the PR.

Dev Side project management will be monitored through the JIRA Board https://issues.openmrs.org/projects/MF/summary 

Process for developing the design and approval to start coding:

  1. Trello will be used to monitor design activities , A backlog will be created with the trello

https://trello.com/b/AwkMfSEM/design-progress-openmrs-flow

  1. User stories collected in google doc (like appointment UI)
  2. Figma will be used for designing the user interfaces https://www.figma.com/file/0sfnmvaW8yTCHrpDLyzmRz/OpenMRS-Flow-Toolbox 
  3. The ticket is them moved to JIRA for coding.
  4. User testing on Prototypes? Can be done during design feedback stage.

Figma tutorials: Greg has been asked to develop Figma tutorials for the developers.


Planning for the following week:

  1. Work customising and finish off JavaScript API module 
  2. Complete the Log in page with API authentication
  3. Other features that need to be worked on are ;Primary Nav bar and patient search
8/01/2019
  • The microfrontends squad is starting to work on real features and modules that are intended to be used by as many people and distributions as possible. Please reach out if you want to be involved in this. Upcoming features are 1) Landing page after login, 2) patient search, and 3) patient chart/dashboard.
7/25/2019

https://notes.openmrs.org/mf_squad_2019_July_25

6/26/2019

Updates:

  • We had a design forum on Monday of this week to discuss the creation of an OpenMRS styleguide javascript module. Audio from meeting can be found here. The main decision was whether to use MaterialUI or build atomic elements of our own. A decision was not reached – we’re going to create a separate Talk thread to continue the discussion there. Also, discussion will continue happening on https://github.com/openmrs/openmrs-rfc-frontend/pull/10 2.
  • We’ve updated JIRA with the tasks that the microfrontends squad and other community members are working on. https://issues.openmrs.org/projects/MF/issues 1
  • I am wrapping up my time in Kenya by helping start Ampath’s migration to microfrontends. We have converted the entirety of Ampath’s POC application into one big microfrontend. Plan is to split it up from there. See below gif for more details.
  • One wiki for setting up local development environment is complete: https://wiki.openmrs.org/display/projects/Setup+local+development+environment+for+OpenMRS+SPA

The below gif is the Ampath application running as a single microfrontend. The plan is to use the strangler pattern 2 to replace parts of the application with openmrs core microfrontends (in collaboration with the entire OpenMRS community). @fali will likely be creating an RFC proposal in the coming weeks to go into more depth about what migration looks like for an existing SPA to microfrontends.


Design Forum Notes: https://talk.openmrs.org/t/design-forum-2019-06-24-micro-frontends-squad-rfc-discussions/23588/5

Etherpad https://notes.openmrs.org/Design_Forum_Styleguide_June_24_2019




  • No labels