Planning Soldevelo work while Rafał's on holiday

@dkayiwa Do you mean topic on Talk’s Implementing category? Because if I understand this this post correctly, Implementers mailing list has been replaced with it.

@tmarzeion and @adamg, there’s one thing I’d really like to be done. One important task of GSoC was to move away from XForms and ODKCollect and use dynamically generated forms from the rest api. While the second part is done, there are still some remaining dependencies on the ODKCollect module which prevented me from completely deleting it. Could you guys just pick up the necessary parts, integrate it into the main app module and delete odkcollect altogether? That would clean up the code and reduce app size nicely :slight_smile:

Also there is a force close in the app when the app is started and logged into for the very first time. I asked rafal about this, and I suspect from the logs that this is related to xforms as well.

I’ll think of other things and put them in JIRA as I can. I’m slightly busy with midsems till the 20th, I’ll begin helping out with actual code after this! :smiley:

1 Like

@gutkowski you got it right! :slight_smile:

@dkayiwa Done, see : Planning Android Client development

Hi @darius,

I guess I should start with your openmrs-owa-tutorialexample and probably leverage on what you have already done with openmrs-owa-uicommons? Looks like this thread is a great resource too: Concept Dictionary OWA 1.0.0-beta released! Actually the discussed OWA presumably shows how to handle styling and auth no?

As you guessed, we would be keen to start with developing a cross-distribution UI for the Data Quality Dashboard.

2 Likes

@mksd, actually, you should ignore my older example, and instead look at OWA Yeoman Generator v0.3.0 Release and the Concept Dictionary OWA. These are newer and show a better style and approach.

Soldevelo team, I would strongly recommend against focusing whole sprints on the Android Client in the near term. Answering the questions of “what do real implementations need from a mobile client?” and “is there a specific gap in the Android Client that will make it valuable for real implementations?” will not happen quickly. (The other thread you started about planning AC work is a good start at a conversation, and I’ll follow up there.)

@dkayiwa’s suggestion to focus on the community-priority tickets is actually very important. I’d go further and say that the default answer to “what OpenMRS thing should we be working on?” should always be that!

1 Like

@darius, considering what you say, the fact that QA sprint is almost finished and we are eager to work, I guess you are right.

@darius Having apps for multiple distributions is a good idea. As you said, we will need to explore ways in which we can make it generic at the same time leverage styles, navigation from the distribution. From Bahmni side, we are interested in the idea. Some thoughts on top of my mind.

  • Can the apps developed be javascript components/packages (React/Angular 2) instead of full blown apps. The advantage of having them as components is that we can do a little plumbing on the distribution side to incorporate them.
  • If the apps are completely independent (or on administration side) and have their own navigation, it can be OWA apps and the distributions can provide a way to link to the apps. But not sure it is a seamless integration from user experience perspective.

@gutkowski, when does the current sprint finish, and when would the next one start?

I suggest that the next sprint should focus on community-priority tickets (@dkayiwa and @wyclif, you two should review those and make sure everything there is actually a good one).

During this sprint, someone could also spike on what might be a possible way for the Data Quality Dashboard UI to look native in both Bahmni and the Reference Application.

@darius QA spring finished yesterday, we can start the next one as soon as it is created on JIRA.

Maybe dynamic importing with SystemJS would do the job?

@gutkowski, we already have an existing Kanban board for the community-priority issues: https://issues.openmrs.org/secure/RapidBoard.jspa?rapidView=79

I suggest we just use this, rather than specifically creating a Scrum board.

(Meta: the idea is that you’re putting one iteration worth of effort into an ongoing “continuous flow” of effort.)

Does this work?

(@wyclif, @dkayiwa, can you please review community-priority tickets and ensure they all are still priorities?)

@gutkowski the feature that @darius is talking about for the Data Integrity module is here https://issues.openmrs.org/browse/DINT-68 and the relevant Talk conversation starts from Data Quality Dashboard

I am available to offer you any testing/QA support that you need

@darius, are you suggesting that @gutkowski should look into UICM-71 then:

I mean before specifically working on a cross-distribution UI for the Data Quality Dashboard (which is what DINT-68 is about I believe)?

@mksd, no, UICM-71 was a ticket I created at the beginning of the year, and that it has more or less been addressed by work done on the Yeoman generator and the Concept Dictionary OWA since then.

We need a new ticket that phrases the DINT-68 work in terms of a cross-distro-suitable UI. (Someone, maybe me, should create this and report the number back here.)

Sure that makes sense. I will follow up this thread for updates then. Thanks @darius.

@darius We didn’t know about this board before, thanks! We already started work on couple of these.

@ssmusoke I see, thanks!

I see that @mksd is interested in working on DINT-68(although ticket is not claimed yet), would you like to take on creating cross-distro suitable UI as part of this work, or do you want us to do that first?

@gutkowski,

There is a clear need for DINT-68 but behind the scenes what is really important community-wise is that this could allow for a real (first?) case of cross-distro UI.

In fact the Data Quality Dashboard already has a UI in Bahmni. The ideal final outcome should be that the work being discussed here would allow to seamlessly port this Bahmni UI to the Ref App. And by doing so we would go through the exercise of establishing a UI development framework, that, when followed, achieves the production of cross-distro UIs.

P.S. With the Platform now being released this is not just a ticket or a feature, this paves the way to bringing UIs to a headless Platform.

Cc: @bharatak

Just wanted to point your attention to https://github.com/PawelGutkowski/openmrs-contrib-uicommons and https://github.com/rkorytkowski/openmrs-owa-conceptdictionary

It’s our first take on providing cross distro UIs via Open Web Apps. The uicommons components use css/openmrs-refapp.css styling, which can be provided by a distribution for all Open Web Apps. If css/openmrs-refapp.css is not provided by a distribution, then an app is using a version of the file embedded in the app itself so you can actually run the app on the headless platform. You can also deploy the app to a static server and configure it to connect to an openmrs instance e.g. http://rkorytkowski.github.io/openmrs-owa-conceptdictionary/ (given you configured the server for CORS).

I’d envision adding an ability to override components in addition to styling. For example we have an openmrs-header component, which defaults to a header known from the Reference Application, but I can imagine overriding openmrs-header component by a distribution globally for all Open Web Apps deployed on the server similar to how css can be overridden.

@gutkowski Just checking in if you have been able to make any headway

Hey @ssmusoke, sorry for late response. No, we didn’t work on it. As Darius suggested, we are working on community priority tickets.