2019 Notes & Recordings

Agenda for the meeting will include:

1. Dashboard configuration led by @bistenes
   1. Work planning of infrastructure level tickets

Meeting Notes:

1. the thoughtworks team presented their project where the are aiming to use the new styleguide guidelines to develop a patient dashboard for one of their clients. The also talked about the different look and feel that new styleguide will bring to the UX of the application. However they decided to stick to current OpenMRS reference app style guide due to the  a tight deadline within which their application was to be delivered.
2. Question was raised as to the migration/adoption path that would be used to introduce the new style guide?
3. It was mentioned that the MF team is currently working on low level features and that the styleguide has been developed in such a way that implementors can change the UI to suit their needs where applicable. thus an attempt should be made by the thoughtworks team to try and adopt the new styleguide given that the current guide is limited. More details around the design of the application would need to be shared by the thoughtworks team and studied to identify potential synergies or opportunities for adoption of the new styleguide.
4. It was noted that the Ref App is server based JSP's and the MF are client rendered single page app, limiting the ability to choose which parts of JSP  and MF you may want to use as the technologies are different.  What was the implementation approach the throughtworks team was going to take? Developing withe current existing styleguide could take more work to complete, compared to how MF has been set up
5. Could a middle ground be reached ? How would one adopt the new style guide in an iterative  incremental manner?
6. Question for thoughtworks: Could the scope and focus be on the specific elements within the  designs that would come forward to support the appointments and user dashboards and fingure out a way to include them in the new styleguide where appropriate; If there are things that could be shifted  to the existing elements in the style guide e.g. buttons etc then we use the existing ones.

Configuration:

-General Config Library

-Config schema for the dashboard
The dashboard configurations were presented as a MF. Which has an activator function. Concerns: Route privileges are insufficient to determine a particular dashboard ; suggestion is it that program may also be necessary ?.  Ideally we should have the flexibility to configure the server to show the right dashboard at the right time for the particular user who has logged in; that may introduce a significant amount of complexity.  The reason to choose a configuration pattern is because there will be modules/widgets that don't belong to any particular dashboard but shared across different dashboards. The main idea with this to say "how do we enable that sharing of  modules , using some generic framework to integrate the modules into a particular view, that needs to account for privileges as well.

Recommendation: these are schemas that will be interpreted by something, thus the focus should be on building the schema for one usecase for now then build as we go.

How will the frontend know what to display based on the facts that it needs to know? Current its configured to have a context with a user object available to every single module within the SPA.

The big architectural problem that may need to be solved is " will the config as is be built into the frontend and used or is it something that is requested by the frontend by the backend ?  do we want data to drive those decisions?

Next steps :

• continue to build out the config library
• Working on the dashboard code
• Have something to present at next week's call

Meeting Notes:

1.  A presentation on completing the patient search ticket according to the designs that were created , as well as its associated tests.
2. Regarding pagination: Was it infinite scroll or pagination ?
3. Design Discussions: Navigation & labeling on the home page:
   1. Navigation : Whether to have an omnipresent bar or have buttons within the app itself to perform the navigation. More commonly today, browser buttons are used for navigation. Suggestion was to do easiest root possible; Desktop side could use omnipresent navigation without back button, mobile &tablets to follow a more standard approach.
   2. Having a back button inside of the UI may not be good idea (esp. on desktop), as well as two different navigation bars. However the most common pattern is to have a fixed nav bar on desktop & for mobile the nav bar is at the top but not fixed.
   3. We need more input from designers to better define the process of how the current design activities are being undertaken. but there continues to be a lack of resources of designers.
   4. User testing may also be a challenge given that at this time there are no users for the artifact
   5. Action Item Proposed: Members were asked to identify designers within their own organizations to get more feedback especially for user testing.
   6. Should also establish what the design process means within the squad and also an effective user testing approach

Summary of Next Steps:

1. Defer to the standard practice, and should there be time and resources more research  into more innovative designs based on the feedback given
2. Proposal is to move forward with an omnipresent navigation bar without buttons .
3. Plan out a way forward for new approaches.
4. A design process needs to be established from when the design is approved to when its coded, QA when working on tickets

Announcements :

Andre from Mekom solutions joins the MF squad

Meeting Notes:

1. Joel provided an update on his talk the REACT Rally. Topic of his talk was focused on new work and what has been done in OpenMRS thus far.
2. Joel & Fatma presented progress to date of the home page and the search button functionality. The architecture and repo has been organized; there are 2 MF navigation and home, where home dashboard at this time has only the patient search link, when the patient search link is clicked, it takes you to another page, which is the main page for search.
3. Style Guide: Links were added to explain when Buttons vs Links vs Div could be applied. Also </main> content which becomes responsive to the navigation bar opening and closing. fonts were also updated. Colours on icons can now be done.Fatma set up all the repo's. the icons are in svg's and fontawesome/font icons as they no longer being considered as best practice.
4. members were encouraged  to make comments on the designs that were being produced within Figma.
5. A concern was raised around how the design process had been set up ; How has the design team set up? Currently there is only one dedicated person who has been trying to engage with other designers to aid with the design process.

Summary of Next Steps

1. members have been asked to review the unassigned tickets and assign to themselves for completion.
2. A demo of the patient search results should be completed by the next call.
3. Technical questions around building the patients dashboard should commence on talk as soon as possible, a google doc will be started https://docs.google.com/document/d/1uDUU63G00o3TFIkUl3nLb163a07AKhJqsyKOg8e-cq0/edit?usp=sharing . 

https://notes.openmrs.org/microfrontends_-2019-08-22

1. Demo of Login (completed)

Fatima provided an update on what she had been working on for the week.

How does the interface handle fuzzy searches, How does the current OMRS search API work ? 

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

Greg provided a presentation of the  above

3.Work planning for following week

Tickets will prepared for the additional work that needs to be done on Greg's templates
Going to start development activities and will complete by End of September

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

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

• 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.

• A live documentation website has been created for the new OpenMRS styleguide. For now, it can be found at https://openmrs.github.io/openmrs-esm-styleguide/ 4. In time it will move to be hosted within the OpenMRS wiki or openmrs.org. The code repo for the styleguide is under very active development: https://openmrs.github.io/openmrs-esm-styleguide/ 4
• We are using Figma 4 to host UX designs for the styleguide and upcoming features. Please click the link and join the Figma organization to see those designs.
• New RFC Proposal: API Calls and FHIR
• PR Approval Process:  @mfsquad to agree on the following withe regards to PRs: (1) 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.
• Overview of Figma: @Gregory Schmidt provided overview of Figma for design system. The link to view this is https://www.figma.com/file/RQHnjNOtD3BghygdwboIXT/OpenMRS-Design-System-Experimenting?node-id=0%3A1. 
• Design System Process: The general plan is once a widget is designed, a ticket will be created in Jira on the MF board. The process for how to move from figma into code is unclear (at least to me). @Joel Denning perhaps you could provide guidance on getting from design to code (? in storybook?) (edited)
• @Fatma Ali demo’ed a framework agnostic tabs widget (very cool!). you can see it here: https://codepen.io/fatmali/pen/Vopdew. Fatma seeking guidance on how to integrate into storybook.
  

https://notes.openmrs.org/mf_squad_2019_July_25

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://openmrs.atlassian.net/wiki/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