Replacing Modulus: Design Thoughts

I don’t know why I didn’t think of indexing Modulus in the first place. It makes a lot more sense than indexing mavenrepo. So I’ll just implement a Modulus backend now, so that with that and Bintray we can go live early, and be covered for the changes you’re making.

@darius, it seems to be super easy to publish all historic versions of modules from our maven repo to Bintray… I just need to confirm the naming convention.

@darius I have another feature suggestion. When a user opens the site ,he should be asked to choose which OpenMRS product he wants to download add-ons for and its version (This could be done using a popup which has 2 select buttons or something of that sort) .With this information ,we could tailor all the downloads and download links specifically for that version.This helps as the user can now just click on a single download button and be assured of getting the right version for his installation. What do you feel ?

@reubenv That is a great suggestion, however I would like to suggest that the default be without those filters because many users may not know what OpenMRS product to download.

+1 to that ! The default surely should be what you have suggested .We can also have an option in the select box that says “Show all modules”(or something like that) .However, I would like to point out that most modules have a minimum OpenMRS requirement version and hence the user might not be able to download the right module without knowing the version of the product he has.

By default, users just go for the latest version of the module, which most times, works well with the latest platform release. If they are looking for a version other than the latest default, then they must already be knowledgable enough to choose. On a side note, popups, especially model ones, can be destructive. :slight_smile:

This is a good idea @reubenv. (And I agree with others that it should be optional.)

That surely does make sense @dkayiwa and I also agree that popups are annoying . We could probably include an option(was thinking more like a dropdown or something similar) above the list of modules on the homepage or on each module’s page for the user to set his/her preferences.

Replying to Replacing Modulus: Project Status Updates - #11 by mseaton here, because I’d like to keep that other thread for just status updates. (Maybe that’s a pointless battle to fight…)

I haven’t created a project for it anywhere yet. I would not use the existing modulus project. I was actually thinking of using github issues, but I welcome suggestions. So far the backlog is what I paste at the bottom of each status update.

Yes. I tried to do what you say (name matches are 4x the weight, and deprecated/invalid have their scores reduced by 80%) but I only fiddled enough to ensure that if you search for “reporting”, the Reporting Module is the top hit (unlike in Modulus). The code is here.

Agree this is a bug. (I was aware, just didn’t prioritize fixing it.)

Yeah, this was an oversight, since I’m actually only indexing “org.openmrs.module.reporting” rather than just “reporting” I couldn’t do this in the first pass. Would be nice to fix.

The “hosted at” link is this. (Right?) I do plan to leave a place to point to the source code. (I do parse the config.xml but not pom.xml.)

@reubenv also complained about this.

The effect I was going for was like when you go to or the App Store you see a curated list of highlighted/interesting items on the homepage, and there’s a search feature too. Clearly I didn’t get this right. Maybe I need to explicitly separate this into three separate screens: (1) home screen showing highlighted/recommended, which in the first pass can show the (manually) highlighted ones, plus most recently updated ones, as two separate lists (2) search (3) browse all (sorted alphabetically, or by most-recent-update. consistently, in any case) As long as search requires a single mouse click and you can start typing into an autofocused field I think this would work well.

Or do you think this is overengineering for our use case, and browse all is more valuable than seeing a curated list?

@darius , Here are my suggestions as discussed previously,

From a technical aspect :

  1. Instead of showing the highlighted modules on the index page,we could show all the modules sorted by the date they were last updated(After we are able to get the download stats from bintray , we could display all of them based on download stats)

  2. If we are to display all the modules on the index page then its gonna increase load time and hence that’s a bad idea. So as a solution ,I propose that we display the best ones(Last updated ones for now) and as the user scrolls further , we can load the others (Ex: Something similar to facebook’s newsfeed)

From the UI point of view:

3)Currently the nav bar is to the middle of the screen ,I’d vote for it being at top right of the same.

4)The search bar appears huge when viewed from my at 15.6 inch screen.I suggest we slim it down a bit in terms on height.

Out of all these suggestions ,I honestly feel that point 1 does need some attention as I felt the users who just want to browse through the list will find it tough since all the modules are hidden beneath the search bar’s “type” dropdown button.(It has already been addressed in your reply to @mseaton ) We could continue having the highlighted modules page like before but we could make it seperate.

I’d suggest a new project in JIRA: ADDON. People are obviously free to make any choice for their own repositories, but I run a script regularly against the OpenMRS organization in GitHub that ensures repos are assigned to all Dev Stage teams (/dev/1-5) and turns off wiki & issues for all repositories. I’m fine with us switching to GitHub for issues, but I think we need to choose one approach for our community-supported projects (both for the sake of devs and for metrics/tooling).

If we want to discuss this particular point further, I’d suggest we create a new linked topic in the repo management category and to avoid off-topic discussion here.

Looking at add-ons-to-index.json

  • I see “names” for maintainers. Is there support for “id” (or “openmrsId”) for a person’s OpenMRS ID? This could simply link to the user’s profile (e.g., for now, but would helpful information (maybe more helpful than name).
  • There’s a “RefApp 2.5” link in the UI, but I didn’t see any tags in the index. I’m not sure how you are divining the group of addons included in RefApp 2.5, but thought it would be by defining a name (“RefApp 2.5”) for the link and then a list of 1-to-n tags to search on to get that collection of addons.

Looking at

  • First of all, looking great!
  • Tagging would be a helpful & flexible way to support near term search needs including some of the other features being discussed (e.g., include a “highlight” tag on entries that should be highlighted)
  • The inclusion of " Module" at the end of modules seems inconsistent (e.g., “Metadata Sharing” and “Reference Metadata Module”). I’m assuming this is just how names have been entered in the index. My vote would be to omit “Module” from the name by convention, since we can always add it programmatically if we want it.
  • Assuming we’re using Bootstrap, it’d be nice to eventually have better support for mobile views (low priority)
  • Eventually, it’d be great to have an “Advanced Search” link that would expand the search form into something that let you search by maintainers, type, activity level, date last modified, RefApp release(s), etc., ideally converting these into a syntax that advanced users could learn and would be supported via URL (e.g., “concept status:active refapp:2.4+ maintainer:darius”).
1 Like

UI design question for anyone interested… imagine you’re using a large-sized display, and you have clicked on a large list of modules. Which display is easier for you to read?

Option A

Option B

(for Option B you’d need to scroll farther to get to the end of the list)

  1. I prefer Option B as two columns are difficult to read on smaller screen

  2. Instead of the word OMOD can you add the current version of the module as well as platform version(s) supported by the current module version?

  3. On the index I noticed some icons for the modules, is this random, or would that be the app icon of a module?

I would go for option B because it is a simpler interface for me to understand. At first, i thought that the second column was a continuation of the first column for each module, until when i saw the different module names. For scrolling, i do not expect to scroll when i can just type to narrow down the search results displayed. :slight_smile:

@ssmusoke @dkayiwa Thanks for your valuable inputs !

That can surely be done but don’t you feel that it might make the module info a bit crowded? I mean we could possibly add the latest version along with the type of module ( OMOD or OWA) . For further info the user could click the module name and all the info will be listed right inside. Moreover we also plan to automatically​ provide the module which is supported by the user’s installation in a future release of add-ons.

What do you feel @darius ?

That would be the app icon of that particular module.

This particular screen is supposed to be showing you which modules(+versions) are in RefApp 2.6, so I do think it makes sense to show that version number.

For other screens (e.g. search results) we could show the latest version number, but I agree with Reuben that this is not really necessary on this screen. Is it really value to search for “form entry” modules, and see the version number without needing to click on the search result?

We should not display the required OpenMRS platform version(s) on this screen, but I think we should achieve whatever Stephen’s underlying need is when Reuben adds a feature this summer where you can set your Platform version number and have all of the display screens take this into account.

When I added the icon feature I just manually added it for a couple modules like this. When we actually go live with this Add Ons tool, we should add icons to more things. (Or better, people can add icons to their own modules!)

And, Option B wins by 3 votes to 0. (I also prefer it.)

You should add a footer with copyright info :slight_smile:

@r0bby, the copyright info of what? Of the addons codebase? Of the content that’s being displayed? Of the underlying module that someone is viewing?


A footer in general – maybe include version info or something – and of Addons itself. This is for the addons webapp.

We are currently working on trying to improve the search results displayed at Add Ons. We would like to hear your opinions as to how and exactly what aspects of the search results you would like to see a change in. You may try it out here .

For example:

  • Some users may want the search results to be sorted such that all the deprecated modules rank low whereas some may want it to be equal preference as other modules.

  • Currently suppose I give part of the name of a module say “Ref” . In the search results , certain modules with “Ref” even as a part of the module description like Chart search module are currently being given a higher ranking. Sometimes, like in this case , it means that the actual modules being searched for i.e. the modules with "Ref " as part of their module names like Reference application module was ranked low. This is an undesired feature.

We were hoping that you would help draw our attention to more such undesired features present in the search algorithm.

Any suggestions are also welcome :slight_smile:

For any further queries, you may feel free to ping @darius , @mseaton or me.