Replacing Modulus: Project Status Updates

Tags: #<Tag:0x00007fe2e2196460>

Another update…

Executive Summary:

  • Good progress
  • Helping to exercise our ITSM processes
  • Blocker: Need to discuss what the MVP should be, and when we’d go live

Done since last update:

Next steps:

  • Define the MVP
  • make it look pretty (@reubenv is working on this)
  • implement the legacy API
  • show download stats (from bintray)
  • show ratings (from bintray)
  • tags/labels
  • “lists” of add-ons e.g. “list of modules in refapp 2.5”

Further on:

  • Migration! (needs analysis)
  • support GitHub Releases
3 Likes

Overdue for an update, so here’s the current status

Executive Summary:

  • We have been slow to do UI skinning, but hopefully this is unblocked now.
  • MVP was discussed, and we have a plan for going live alongside modules.openmrs.org as an MVP, with a larger set of functionality needed to fully replace it later on.

Done since last update:

In Progress:

  • make it look pretty (@reubenv is working on this); we were blocked on getting the tech right, but now are going with bootstrap CSS and https://react-bootstrap.github.io/ for JS. (This is the last piece of the MVP.)

Next steps ([R] means it’s required to replace modules.openmrs.org):

  • tags/labels
  • show download stats (just from bintray)
  • show ratings (from bintray)
  • locally store download stats (consistently across different backends) [R]
  • implement the legacy API [R]

Further on:

  • Migration! (needs analysis)
  • support GitHub Releases
2 Likes

Executive Summary:

  • We have been slow to do UI skinning, but @reubenv is making good progress with react-bootstrap
  • moving towards the MVP (started indexing the modules in Modulus)

Done since last update:

In Progress:

  • make it look pretty (@reubenv is working on this)

Next steps ([R] means it’s required to replace modules.openmrs.org):

  • tags/labels
  • show download stats (just from bintray)
  • show ratings (from bintray)
  • locally store download stats (consistently across different backends) [R]
  • implement the legacy API [R]

Further on:

  • Migration! (needs analysis)
  • support GitHub Releases
1 Like

Great work @darius

Executive Summary:

  • UI looks good now. Thanks @reubenv!
  • This is now better than modulus for searching for modules
  • we can highlight specific lists of modules
  • we can mark modules and deprecated or inactive
  • supports OMODs and OWAs
  • Try it at https://addons-stg.openmrs.org and let me know if there’s any reason not to go live with this now (would be a soft launch, alongside modulus, not yet replacing it). Also, I welcome anyone to put in the correct lists!

Done since last update:

  • UI enhancements (two big PRs from @reubenv, plus stuff by me)
  • optionally label addons as Active vs Inactive vs Deprecated
  • tagging of addons (e.g. “form-entry”)
  • improved search result weighting (still lots of room for improvement here)

In Progress:

  • nothing

Backlog ([R] means it’s required to replace modules.openmrs.org):

  • show download stats [R]
  • implement the legacy API [R]
  • better set of lists
  • filter all screens based on user-entered OpenMRS Platform version
  • show ratings
  • support GitHub Releases

Looking great @darius. I am really happy to see you guys bring this so far. I don’t see a project for this in JIRA (should we be using the existing modulus project)? A few comments:

  • I agree searching could use more refinement. Specifically, if I search for "report’, I’d like to see results with “report” explicitly in their name weighted higher than those with report somewhere in their description or other content. I’d also like to see deprecated add ons at the end of the list
  • If I search for, and click into an add on, there is no way to get back to my search results. There is no navigation back, and the back button does not preserve my previous state.
  • In the module list, it would be great to display (and search on) the moduleid rather than just the display name.
  • It would also be great to link back to the place that it is indexing (in case that is helpful), and also to the github repository (if specified, say, in the pom or config.xml, or somewhere)
  • Clicking on “All Types” shows “Highlighted Modules”, whereas clicking on “Modules” shows a list of 200 results, seemingly un-sorted and un-filtered. It would be great to have either of these act consistently, and also have an explicit way to page through all available modules. These should be sorted alphabetically.

Anyway, not sure if this is helpful or desired feedback, but I wanted to put it down somewhere and this seemed the best place to do it :slight_smile:

Nice work, Mike

1 Like

I replied at Replacing Modulus: Design Thoughts (My intention was for this thread to just be status updates, and the other thread for discussions, to enable better tracking for PM purposes. Thinking about it more, it’s probably best to just have a single thread, and just do periodic progress summaries on it.)

1 Like

Replying to Add-On Index enhancements here, because the other thread was made with the intention of gsoc discussions on the project.

It’s funny how the smallest of issues sometimes get us(me in this case) stuck :sweat_smile:. The reason for the console error was basically that although the new url pointed to “react-router”, it pointed to “react-router v4.0” whereas our project previously depended on “ReactRouter” which was part of V3.0.2 .

The next question is as to how did this happen in the first place?

The answer to this is that we previously used a url which was dynamic i.e. it gets resolved to a different one .The url used was this. This url basically points to the latest version of react router which is now V4.0 . Now, if we look into the contents of this resolved url , we realise that ReactRouter.min.js no longer exists and that only react-router.js is present. Hence , naturally I didn’t initially think that there’s going to be a difference between the two and created a pull request with a url pointing to react-router.js .

This new file missed some vital code on which our project currently depends and hence the console error . On checking the npm package.json file, I realised that we were using v3.0.2 and when I navigated to the React-router files of v3.0.2, I found the file right there. Hence I have now created an updated PR with the link to the exact same file. I have also tested it locally and can confirm that Add-On Index is back up and running :slight_smile: .

@darius Please check this .:slight_smile:

I went ahead and merged it since the CI passed.

cc: @darius

Thanks @r0bby. @cintiadr Can you please deploy the latest changes ?

In theory deployment should occur automatically. I will check why that didn’t happen.

Hum, the build failed. So I had to redeploy.

Thanks @cintiadr :slight_smile:.

Summary:

Add-ons is live again.

Thanks for fixing the problem :slight_smile:

2 Likes

:star2: for @reubenv

1 Like

Sorry for the long delay since last update. I’ve had lots of other stuff going on! But here is some more progress:

Executive Summary:

  • Improved Search UX
  • Implemented legacy API (not properly tested yet)
  • Try it at https://addons-stg.openmrs.org and let me know if there’s any reason not to go live with this now

Done since last update:

  • Search behaves more intuitively (should address Mike and Reuben’s complaints)
  • Back navigation from a module back to your search result works
  • Addons can now specify icons (from fontawesome)
  • Implemented Legacy API

In Progress:

  • nothing

Backlog ([R] means it’s required to replace modules.openmrs.org):

  • GSoC work (hopefully!)
  • show download stats [R?]
  • better set of lists
  • filter all screens based on user-entered OpenMRS Platform version
  • show ratings
  • support GitHub Releases
  • move this backlog to a JIRA project

Is the “RefApp” link at the top dynamic? Or is it one more thing to maintain with new RefApp releases? If it’s the latter, I’d drop it for now.

Can you put a link to the GitHub repo? I’d think we’d want to make it easier for people developing addons to discover how to get their’s added or updated (as well as welcome pull requests for new features).

The RefApp list is static. It (and all the lists) are defined in this section of the add-ons-to-index file.

I think we can automatically determine the refapp release lists based on the openmrs-distro.properties files in the released refapp versions. It would make sense to determine this and some other lists (e.g. top-10-downloads) dynamically, so I’ll add that to the backlog.

I was holding off of putting “how to add your add-on” instructions until we actually replace modulus. But I guess we can put it up sooner. (There is a placeholder https://addons-stg.openmrs.org/#/about page, but I guess the link to this got lost in some of the UI enhancements. :slight_smile: )

I’ve written down the migration path from Modulus to Bintray/Addons at Modulus Migration Path. Please have a look at it and see if I missed anything.

Please also review the new Module Release page.

Let’s try to set some deadlines.

3 Likes