Developing the "OCL for OpenMRS" Application

(Daniel Kayiwa) #324

@michy what do you mean by all set?

(Michael Mbugua) #325

@dkayiwa I meant I have requested the access and updated the OpenMRS calender. The link to the demo will be available on Monday 15th October 2018.

(Daniel Kayiwa) #326

@michy are you sure that you put this event on the OpenMRS calendar?

(Michael Mbugua) #327

@dkayiwa Yes, it is there. Here is the screenshot

(Daniel Kayiwa) #328

You have just added it. It was not there by the time i asked.

(Michael Mbugua) #329

It was there the moment I responded on the Talk. Thank you for your patience.

(Michael Mbugua) #330

Hello Community,

Please be reminded that the Ninth Sprint Demo will take place from 5-6pm EAT. I will share the Demo Call link here at least 30 minutes before kickoff.

cc @darius @dkayiwa @nesh @emmabaye @muhozi @alexmochu @akanter

(Michael Mbugua) #331


Please be reminded that we are having the demo in about 15 minutes: Could you follow the link below:

cc @darius @dkayiwa @nesh @emmabaye @muhozi @alexmochu @akanter

(Michael Mbugua) #332

Thank you guys for attending the 9th Sprint Demo. In case you missed it, you can access the recording on the link below:

(Michael Mbugua) #333

Here is the summary of the tasks that were completed on on the 9th Sprint:

(Andrew Kanter) #334

My notes from testing against QA:

  1. On CIEL Ref Set dictionary 2 other concepts are shown on the dashboard, but when click on concepts, none show. (only non-CIEL concepts are shown)
  2. On creation of a new dictionary, visibility not set. None = private?
  3. Added CIEL Ref Set to copy from and nothing happens when Add dictionary is clicked
  4. Other Languages are sorted by ANSI code and not the language (should be language)
  5. example text in fields is too dark and looks like an entry. Should be a lighter grey.
  6. Release versions don’t have to be unique (should be)
  7. Copy from concept when creating a new concept not working properly (not all concepts are copied, more concepts shown than are copied)
  8. On all dictionaries page, there is something partially covering the search field.
  9. Browse in OCL and Subscription URLs have double backslash and don’t work.

(Muhozi Emery) #335

@akanter Thanks for the feedback. We’ll look into each of the point in this next sprint.

(Muhozi Emery) #336

Hello everyone,

We are excited to announce the tenth sprint for Open Concept Lab for OpenMRS(OCLOMRS). The sprint planning session is scheduled for tomorrow on Tuesday from 4:00 PM to 5:00 PM EAT(East African Time). I will update you with the link to the session call 30 minutes before.


CC: @darius @dkayiwa @akanter @michy @ianduncan

@alexmochu @nesh @emmabaye We will appreciate your availability in the sprint planning session call sharing what we can improve on OCLOMRS.

(Darius Jazayeri) #337

Sorry I was very late to the call. Here are my comments from viewing the recording:

  • Release: in the UI on the dictionary overview screen we should not say that “HEAD” is a Released Version (because it’s a special non-released current version). I suggest:

    1. change the heading to say “Versions” (instead of “Released Version”).
    2. the row that says “HEAD” should instead say “latest unreleased”, and it should not have a date
    3. Also, change the table header to say “Release Date” instead of just date, and make the actions look more distinct from each other. E.g. browse should have an icon like it does in the Actions section in the top right
  • Actually, releasing seems different at minute 6 vs minute 22 of the video

    • At the later time I do not see HEAD in the version list, but the earlier time I do
    • At the later time I see two different buttons “Release HEAD as a new version” and “Release a new version”. Why is that? This should just be a single feature, and it can have the simpler name of “Release a version”.
  • About “visibility” I think the change made was backwards. Maybe I didn’t communicate this well, or maybe it’s not as intuitive as I think.

    • The options in the UI should say “Public” and “Private”
    • in the back end API these map to View and None, but the end-user of our app shouldn’t ever see this
    • also there should be blank option for this. It’s a required field. (I would have it default to Public)
  • Tooltip for short code while creating a new dictionary doesn’t work like tooltips usually do. Any of the following are pretty standard, so pick one of these standard approaches:

    • write it out as plain text next to the label
    • write it as the placeholder text when the field is empty
    • have a visible icon that you can hover over, and this displays a tooltip
    • help text is displayed as a tooltip when the field is focused
  • (right now it does a tooltip when you hover over the field, but there’s no icon, and it doesn’t pop up if the field gets focus via a keyboard tab). Also this tooltip should say that it cannot be changed after creating the dictionary

  • About creating a dictionary as a copy of another: I thought I had said to deprioritize this until after the MVP, because we instead want to focus on a different workflow (create a blank dictionary, then add all concepts from another dictionary to yours). If this is done/working already, great, but if there are bugs that are going to take time, let’s revisit whether we continue to prioritize this or move it back to the backlog.

  • Bad UX: Create a new dictionary, and add another language. The multiselect widget remains open, so I press Esc (thinking this will close the multiselect) but this closes the entire modal popup and discards my info. Even clicking outside of the modal in the gray area closes it and discards the form. This is bad UX for a form in a modal. Instead the modal should only be dismissable via the Cancel button at the bottom of the form.

    • In fact the form is not entirely cleared when closing the form (either via Cancel or clicking outside the modal): the Visibility and Dictionary Name fields stay filled, but the Other Languages multiselect is cleared. If the form is cancelled, all data should be discarded.
  • Be more consistent (and with worse manners) in error messages. E.g. here all of these error messages should just say “Required”. (No need to say “Dictionary Name cannot be empty” right under the label “Dictionary Name”, and no need to say “Kindly”)


  • Actually when I try to create a new dictionary myself nothing happens. If I leave all the fields blank and click Add Dictionary I do get the error messages as shown in the previous screenshot. But if I fill everything out and click Add Dictionary, nothing happens. (No error message, no network call, nothing written to the console.)

  • Also, when I open an existing dictionary of mine to edit ( it shows up like this (I’m trying to test if this happens for new dictionaries too, but I cannot create one):


(Muhozi Emery) #338

@darius Thank you for the feedback. We will work on those bugs and improvements in this next sprint.

(Muhozi Emery) #339


The sprint planning will start in 10 minutes. You can join it from here:

CC: @dkayiwa @darius @alexmochu @nesh @emmabaye @michy @ian

(Muhozi Emery) #340

Thanks everyone who attended the sprint planning. Those who missed it can find the recorded video here.

(Darius Jazayeri) #341

Actually, stepping back, a better UX for this would be to indicate which fields are required/optional up front, e.g. by have a red * by all the required field labels. (Alternately since this form has ~6 required fields and 2-3 optional fields it would be okay to just mark the optional fields with an “(optional)”, but the first approach is probably more standard.)

It would be more helpful to include a quick snapshot of the output of sprint planning. The typical question someone would have is “what work was prioritized” and I’d rather not watch a video to find this out. Approaches that would be nice:

  1. include a list of the ticket summaries
  2. screenshot of the JIRA board
  3. link to the JIRA board

(Darius Jazayeri) #342

PS- when I look at the JIRA board I see a lot of tickets there, definitely not just one sprint’s worth. How are we using this? Since you’re doing 2-week sprints I would expect to see a board that contains multiple sprints in it (one active and all the rest closed).

Also, once work is completed, tested, and showcased, it should be marked as closed. I see a lot of tickets that are still open even though all their subtasks are closed, like this one:

We should do a round of user acceptance testing by me +/- others (@ball, @akanter). Can the team start by doing a pass through and closing off anything that’s clear and requires no feedback, and give me/us a list of tickets that are ready for UAT?

(Muhozi Emery) #343

@darius Thanks for the feedback. Sorry for not sharing the links here. There is a prepared wiki page stating the goals of this sprint and it includes the summary of the tickets with other useful links for the sprint planning. That wiki page can be found here. You can also find the JIRA board here

In addition to that, there is an announcement made here