Happy New Year, and I hope the holidays went well for everyone. Hope you are well rested for the new year ahead.
As per the release cycles for the reference application, the next release is due on March 31, 2017. In the spirit of keeping the releases regular and bi-annual, this post is to solicit for input for what has to be delivered in the next release.
The approach that I would like to suggest for this release is based on this post How we Structure Work Learning from BaseCamp with a recommendation of 3 big features and 4 small ones
Based on discussions from the last few design meetings and discussions, the first draft of the suggested features for this release are:
Big Features:
Foundation of using Twitter Bootstrap for the reference application UI with sample migration of remaining legacy UI as a foundation
OCL integration: need to determine what is currently available
+1 to all the Small Features. They all seem like high priorities, and should all be achievable.
All three Big Features you have listed require some design work, and don’t forget that they need to be finished well before March 31 for all the testing and release process that happens in the refapp release. I’m concerned it’s not feasible to develop three things that still need significant definition in this release.
I’d rather see the big features phrased in terms of stories with user value, not “foundation of…” tech tasks.
So, I would suggest rephrasing some of the Big Features in terms of a small-but-achievable user value, that can be approached as an MVP in an agile fashion in this release.
Also, it occurs to me that we should shift our refapp release dates to take advantage of the flow and timing of GSoC applications. I will write this in its own post.
@darius Yes the big features are a little vague since they are still high level and I am hoping to get some help from the community to help define them.
For Twitter bootstrap and the widgets, fingers crossed I may be able to get a dedicated person to work on those, but will need design support, and my hope is that some useable examples can be included in the Ref App release with the new dates.
OCL is one where I have no visibility, or knowledge and not sure what the status is, but I am hopeful a simple use case can be included to set the foundation for 2.7.
@ssmusoke in the early days, we used to do lots of generic feature harvesting from other distributions like PIH and KenyaEMR. The beauty with this is that the code was already in place and much of the efforts were extracting it out and some small cleanup work to fit it in the refapp. What are your thoughts on this?
Alongside adopting bootstrap we would be keen for a general UI re-thinking.
And we see this happening on at least two levels:
Dashboards re-thinking
At the very least the patient dashboard must undergo some serious changes (and in particular patientdashboard/visits.gsp). In our experience at least this page is not good enough from the user’s perspective and it is a nightmare from the developer’s perspective.
But perhaps this leads to re-thinking the CF dashboard as well? Perhaps one larger, better designed dashboard would be more useful as a central place to offer a synoptic view of the patient, including its history of visits & encounters.
Number of clicks
One design flaw of the Ref App is that users must perform too many clicks.
There are many examples of this, but here is one: when finding one patient (so when the result of finding a patient is a unique occurrence) the patient CF dashboard should open right away on that patient.
From a usability standpoint, we would be better off staying mostly on one page (the idealised dashboard mentioned in point 1 above) and use widgets to rapidly visualise further data, rather than always accessing other pages to visualise further data.
In fact what I am saying here is that each app, or each piece of functionality that is rendered fully through an ad-hoc page, should provide at least one widget that could be inserted into dashboards (or not, depending on the desired configuration). Some modules/apps/functions already do that: Allergy UI, VDUI, Appointment Scheduling UI, … etc, some don’t: Chart Search.
Leveraging reusable UI components paves the way to this. One should produce configurable UI widgets, then those widgets could be used with a compact display for dashboards insertions or in a full size display for the ad-hoc page.
It is very possible the above two points are out of reach for end of March, and in that case we would love to keep them in mind for later releases.
2. Small features
We could bring in the Sticky Note feature. We will create ad-hoc RA tickets for this.
@mksd Thank you for the input, and it makes sense to spend some time on it during the release
@darius I have not gotten any input on OCL, so I would like to exclude it from the big features list, so that we can focus on the UI changes for 2.6, and can work on its integration in 2.7. @burke@wyclif@dkayiwa@mogoodrich thoughts?
if in this roadmap you plan to conduct some automatic testing as well, please contact me.
As someone among you have already got in contact with me, I’m willing to support OpenMRS project on testing activities.
Thank you
Thank you so much @domenico for the great help with our testing process!
Do you currently have anything you are working on for improving our automated tests? Or are you blocked on anything?
My first short term object is to recover past test cases, to this aim I’m working on two fronts:
a)I’ve opened this issue, can someone assess it? I’ve already fixed the test.
I want to recover all the UI tests annotated with ignored or broken. If I have to open an issue for everyone of them
the risk is that I’ll be waiting for my issue to be assessed.
b) I would like to “clean up” all the issues of type Test. I’ve already tried to contact privately @pavlo and @natalia
with no success (they are reporters for many of the issues). Maybe they are not contributors anymore.
At the moment, I’ve commented some of the issues.
The idea is to check that each issue is satisfied by a test. If there is no test, I’ll ask to developers if it makes sense to implement, then I implement it
If there is a test, I have to check if it works, fix it otherwise.
@domenico I have assessed the issue and assigned it to you. Actually issues that refer to the reference application test suite should go in the Reference Application project in JIRA (not OpenMRS Core) so I moved the issue to RA-1281. Assuming that the fixes are straightforward and/or similar, you can create a single ticket to cover a batch of fixes. If any of them will require significant discussion, it should probably have its own ticket.
As far as cleaning up the issues of type Test, I don’t think that Pavlo and Natalia are around the community anymore. You can go ahead and make the appropriate changes to tests and issues. (Of course, ask questions if you have them, but at this point you may know as much about the test suite as anyone else that is active.)
I notice that OCL was dropped, where is this up to? Do we have a date when this might be ready?
@raff do you think the OCL subscription module could be ready for the reference application?
@paynejd how is the server side going? Would this be usable by the reference application?
@burke@darius@dkayiwa@wyclif@raff Please do advise on the process for adding new modules to the reference application in this case I am looking at the visit documents module.
@ssmusoke before considering adding it to the reference application, i would first of all ask, does it work well out of the box (straight from modulus)? Does it have some end user documentation? Answers to these would guide the next steps.
