Hi all,
We’re planning to expand the Add-Ons Index to cover two new kinds of artifacts: O3 frontend modules and content packages. This post explains what’s changing and where we’d like your input.
The Add-Ons Index today
If you maintain an OpenMRS instance, you’ve hopefully used addons.openmrs.org to find a backend modules, check which version works with your platform version, and download whichever version you want. If you haven’t, you should know that’s available.
Today, this index covers backend modules (OMODs) and legacy Open Web Apps (OWAs), but as OpenMRS evolves, especially with O3, that’s no longer sufficient
New Module types
With O3, a working OpenMRS system is assembled from more than just backend modules and OWAs. We also have:
Frontend modules, i.e., packaged O3 apps and extensions — the patient chart, registration, form builder, and so on. Today they live on the npm registry, which is a fine place to publish them but not a friendly place to find them if you’re not a JavaScript developer.
Content packages, i.e., bundles of ready-made clinical content — forms, concepts, reports, and configuration — that you add to a distribution with a single line like content.hiv=1.0.0. Examples include the Reference Application content packages and the HIV Care & Treatment package. If you worked iwth content packages yet, Content Packages Explained on the wiki is a good introduction.
Currently, finding these means hunting across NPM, GitHub, the wiki, and word of mouth. We’re hoping that storing these in the Addons site will make these easier to discover.
What you’ll see
Search will work across all add-on types, with a filter to narrow down to what you need:
Each entry gets the same treatment modules get today — description, maintainers, tags, version history with release dates, download links, and download counts. For content packages, the index will also show what each version requires to work: the platform version range and any backend or frontend modules it depends on. This comes straight from the package itself, so it’s authoritative, and should be easy to keep up-to-date:
For frontend modules, the version list will show stable releases only, so what you see is what you’d actually deploy:
You’ll also notice each detail page shows the exact line to add to your distro.properties, which is hopefully helpful.
For OMODs and OWAs, nothing should change today, though we would like to solicit any opinions on changes we should be making to the UX for these as well to make them more easily discoverable, understandable, and useable.
For the initially indexed artifacts, we’ll be focusing on ensuring that we’re indexing everything in the O3 Reference Application, but we’re happy to work with the community to identify other resources that should also be included.
Where this could go
Once the index knows about all the ingredients of a distribution — platform, backend modules, frontend modules, content packages, and which versions of each work together — it can do more than search. Imagine picking your platform version, ticking the boxes for the modules, apps, and content packages you want, and downloading a distro.properties file the SDK can use to create full OpenMRS distribution.
Ultimately, we’d hope that this would be a useful tool for starting out a new OpenMRS install, but are also keen to hear any ideas on how we can extend the index and it’s knowledge of OpenMRS addons to better support existing installations as well.
We’d like to hear from you
A few questions for implementers especially:
- When you’re choosing add-ons, what do you look for that the index doesn’t show today?
- Which content packages or frontend modules should be listed first?
- Would the “build me a distro.properties” direction change how you set up or maintain your instances?
Links: addons.openmrs.org · Content Packages Explained · openmrs-contrib-addonindex on GitHub
(Screenshots above are mockups of the proposed UI)