Hi @sheriff, the first two flow videos look right, but the last video has one thing wrong: the source should display as CIEL when you reopen/edit the q and a concept. (Because the answer concept’s source is CIEL. It should also be mapped this way in the back end.)
Also, two UI/layout comments:
Like Andy said, the answers should be much further down on the page. (Answers, set members, and mappings should be the last 3 things if I remember right.) See my mockup in the original design Google doc.
Please also display the concept id in the concept column of the table, like we are doing in the mappings section, I think. It could look something like “(123) Concept Name”
I thought we had decided that the demos and catch-ups would always be in the same time slot on Thursdays.
(Also we need to verify the time since we just had a daylight savings time change in the US.)
Please create a ticket (post-MVP) for going through the whole application and making table column widths be smarter. In many screens I’m seeing the concept name (which is usually the most important detail in the table, and is often long) squeezed/overflowing in a small column, while there’s another column just the same size showing something like 1234 or Yes.
Watching the ticket about making Mapping Source a select option. That part (having it be a dropdown) is good for the MVP.
But when you change the source of an existing row in the mapping table, I would expect this to clear the selected concept. E.g. this state doesn’t make sense, because there’s no concept (32) Malarial Smear in the Locales source:
I hope you’re doing well. This is just a reminder to help me clarify what you meant by this
"Answers for the concept should be near the bottom not BEFORE the concept names" when we have created a Q-AND-A relationship.
Should I still schedule the weekly sync call today because we had a Demo_call yesterday and there is nothing more to show since the new_sprint just started.
This is a reminder of the OCL-client team and POs weekly sync (Thursdays 6pm - 7pm EAT). I will share a link to the call 15minutes before the call. kindly attend if you can make it.
Darius, I reviewed the original mock up. I think I would modify it to look like the following:
OpenMRS ID
UUID
Class Datatype
Names (FSN first, locale setting first)
Descriptions (Locale setting first)
Set members
Answers
Mappings to reference terms (not set members or answers. Haven’t decided on sorting of these but should be grouped by source)
One other point. I realized that the class is no longer editable. That means that the only way to change this is to delete and re-add the concept. In the OMRS UI, you can change this on the fly and not have to re-enter information (particularly if there are set members, etc.). I think we need to discuss for MVP+.
FYI, we are moving the SYNCH/Sprint review meeting up 1 hour EAT so it can remain at the same time which is 10am EDT/9am CDT/7am PDT in the US on Thursdays.
Thanks for rescheduling this. I can do this new time (which is the same time for me on the wall clock).
Sorry I’m giving my feedback split up over many messages, but I’m only getting to watch the recording in fragments.
Andela tech team, please as a high priority do an estimate of what it would cost to refactor (a) just the add-from-CIEL page, and the create-a-concept(mappings) search, or (b) the whole application, to ensure that we are using a single service to do concept searching, such that the behavior is consistent throughout the application.
I agree with Andy’s comments around minute 24 that it seems like we’re repeatedly discussing the same set of issues on one search box that we’ve already resolved on other search boxes.
About retire/unretire/delete/remove, here’s how I would prioritize:
MVP:
Able to retire and unretire a concept (for custom concepts in your own dictionary)
Able to remove a concept (included from another dictionary like CIEL)
Not MVP:
move Retire and unretire to the View/Edit Concept screen (not the dictionary concepts screen)
Able to delete (instead of retire) if you have a custom concept that has never been released (on the View/Edit Concept screen)
Also, it’s a requirement before we release the MVP that Andy and Ellen can test the against the full CIEL dictionary in QA.
We have a ticket in the current Sprint to make all the search fields consistent. We were previously having trouble with the search field that was also working as a dropdown but it will be fixed as well. This should all be ready for review in the next Demo/Sync.
While working on “Retire/Unretire” Concept, I noticed that when a Concept is Retired (or Edited in any way):
The edited values are properly reflected only when one retrieves that specific concept
GET https://api.qa.openconceptlab.org/users/admin/sources/MULAGO/concepts/0949f6d9-82bc-4cf1-9c8a-ab1faeee3d3d/
But if you retrieve all Concepts within a specific Dictionary, you’ll notice that the copy/reference of the Concept (within that Dictionary) wasn’t edited.
GET https://api.qa.openconceptlab.org/users/admin/collections/MULAGO/concepts/?includeRetired=true
Basically, each Dictionary creates its own copy of a Concept which cannot be edited directly. All attempts to edit it (or retire it) just end up editing only the original version of the Concept.
Please let me know if this was the intended behaviour or if there is another way to edit a reference of a Concept in a specific Dictionary. The API Wiki doesn’t feature “Edit a Reference to a collection”. Thanks.
So I managed to implement what you had requested for so that the bash script is run at run time but on merging the PR the Build failed even after rebuilding.
I can’t remember exactly what @darius said, but in my mind, dropping the active distinction and reporting the number of concepts makes the most sense. Until we get the active/inactive toggle working the numbers should at least be consistent.
The issue that Andy highlighted in the last demo is that the numbers on this screen did not correspond to the number of concepts when you actually Go to concepts. (If I remember right, in the demo recording this screen was showing 19 total, but when you viewed the actual concepts there were 2 pages of results, with 1 result on the second page, so probably 21 total.)
Taking a step back:
for the MVP the only important thing is to display a total number of concepts that is correct and consistent with the concepts shown on the next screen.
I don’t like “Active Concepts” because I don’t know what “active” means (and neither will users). So I prefer to remove this.
the breakdowns are nice-to-haves, and it’s okay to include them in the MVP if they are correct
if we can’t get the breakdowns right, then remove them: this should not be a “launch blocker”
This is a very important thing you’ve caught, and it was definitely an oversight on my part that I hadn’t thought of.
The situation is a bit different from how you’ve interpreted it, so let me describe more:
In OCL, every edit to a concept is tracked as a new “concept version”. So when you edit a concept, this actually creates a new concept version and makes in the active one. (You can see this by doing GET concept, looking at “version” and “version_url” fields, editing the concept, and GETting it again.)
The key point is that there’s a difference between these two URLs
# this means "latest version of this concept" (not exactly correct)
/users/admin/sources/MULAGO/concepts/0949f6d9-82bc-4cf1-9c8a-ab1faeee3d3d/
# this means a specific version of the concept
/users/admin/sources/MULAGO/concepts/0949f6d9-82bc-4cf1-9c8a-ab1faeee3d3d/5c8b9f0f8e836c01a92b47ee/
The collections API is a bit limited (and this is because we had limited dev resources when we built it), so a collection can only include static references to a concept version not dynamic references to the “latest of a concept”. (See the message of the example return value here:
collections · OpenConceptLab/oclapi Wiki · GitHub) (@paynejd please confirm this is still true.)
This has advantages and disadvantages for the consumer. But for our case specifically, what this means is that if the user edits (or retires/unretires) one of their custom concepts in the dictionary, you also need to remove the reference to the old version from the collection, and add a reference to the new collection.
Ideally this would be handled in the API layer, and when this project was starting I recall discussing a way to do this, but I don’t remember what we settled on. (@raff, @paynejd do you know?) If not, the workaround is to do this in the UI layer whenever a concept is edited.
(Just to be explicit, if a concept from another source (like CIEL) is edited, we do not automatically want to bring in the new version, because this is outside the control of the dictionary owner. Post-MVP we will add a feature like “check for new versions of my concepts”.)