General information

Team Lead: Daniel Kayiwa

Sprint Lead: Emery Muhozi

Timeline

Start date: 18th October 2018

End date: 2nd November 2018

Participants

• Michael Mbugua
• Emery Muhozi
• Ian Duncan Abidha 

Sprint Goals

The main goal of this sprint is to fix bugs found in the application and work on the pointed features that have to be refined. In this sprint we should also work on application UI consistency especially on app colors.

In this sprint we'll work on the following notes that were identified during the demo:

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?(We should seek clarification on this)
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.

In this sprint we will also work on the following feedback we have received after the demo:

• 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 (https://openmrs.qa.openconceptlab.org/dictionaryOverview/users/darius/collections/DIT/) it shows up like this (I’m trying to test if this happens for new dictionaries too, but I cannot create one):

  
  

Sprint Dashboard

How To Participate

Add your name to the list on this wiki page (with any comments about your availability). If you want to join after the sprint has started just join the IRC channel mentioned above and say hello.

The general process:

1. New to OpenMRS sprints? Want help getting started? Join IRC and say "???": I'd like to participate in the sprint!". If you get no response, just ping any of the above sprint participants as per the IRC tips at http://en.flossmanuals.net/openmrs-developers-guide/support/
2. Pick a ticket from the available tickets in the top-left of the sprint dashboard page at:
• Make sure it does not depend on a ticket that is incomplete.
3. If you have any questions about the ticket, ask on the group chat.
4. Do the ticket. See our HOWTO for git. Sprint specific git HOWTO for devs with push rights: whatever works for you :-) If you don't like pull requests, don't send them. Commit and push directly to the main repo. If you do like pull requests, fork the main repo and send pull requests, but merge them right after. My favorite way is to work on the main repo, but create local branches (without pushing them to the main repo). Merge branches locally to the master and push to the main repo.
5. Join the daily scrum to share your updates

During Project Notes for the sprint

To be added while the project progresses 

Sprint Retrospective:

To be added after the end of the sprint. 

Resources

JIRA board: https://issues.openmrs.org/secure/RapidBoard.jspa?rapidView=173&projectKey=OCLOMRS

Github repo: https://github.com/openmrs/openmrs-ocl-client