I believe that I have spent a fair share of time on gathering possible enhancements for the Add-on index project.
I have made sure to include the suggestions of other developers along with my own and have also thought of ways of implementing them. After all this while I’ve created a fairly comprehensive list of all possible additions to be worked upon which I wish to share.
History with OpenMRS :
I’ve been an active member of this community for a while now and in the process I have learnt a lot about how open source organisations work and particularly OpenMRS. I go by the username “reubenv” on talk , Telegram and IRC. Here is a list of my contributions to OpenMRS .
Discussion :
I am interested in working on the Add On Index enhancements project. Firstly, I would like to add that the work done by Darius so far is highly commendable . Here is a list of possible improvements to the existing website :
Documentation support: We need to create a wiki document or guide stating as to how a user should go about with getting their module indexed.
Improve searching algorithm(As discussed here): Currently the search algorithm is quite efficient but if a word is searched for, it returns all module names with the particular word somewhere in the name. We would like to rank those with the modules with the word only as their module name to be ranked higher over the rest. This can be achieved by improving the elastic search algorithm.
Tagging support : I would give this a high priority as with an increase in the number of modules , tags are going to be very useful to sort applications using their category . For example: Allergy UI module can be given a tag called refapp. If this tag is clicked then it will show all the ref app modules.
Ratings: We could implement this in a number of ways
We could create a ratings section where user can rate. This should be done if we use rating as a parameter to judge the quality of a module and not it’s usefulness.
We could use download counts as the primary rating parameter. This is because. if we consider that in our current scenario, ratings basically signifies the usefulness of the product, then we should rely on download counts.
Display compatibility of the module with current installed OpenMRS version : I believe this could be implemented as agreed by the community [here] (Replacing Modulus: Design Thoughts).
Download counts , ratings, comments : As we all know that we will be in due course of time migrating to Bintray in which case we can use their rest api similar to this.We could probably also generate graphs based on the stats.
Talk profile integration: We could link the names of the module devs to their talk profiles.
Return to previous search results on pressing back button.
Support for mobile view.
Re-implement the OpenMRS modulus API so as to shift completely to Add ons.
The use of the term “module” seems inconsistent as stated here.
Lastly, some minor UI enhancements could also be added.
Now, that is my list of possible add on enhancements which will be forming the gist of my gsoc proposal. I would love to hear and discuss the priority of these ideas and their implementation with Darius before I submit my gsoc proposal.
I would also love to get some valuable inputs from @burke , @wyclif, @dkayiwa , @raff , @mseaton who were actively part of the Add on index design discussions.
I would also like to add that we must create a JIRA project for the Add-On Index.
Hopefully, you find these ideas worthy of being discussed and implemented.
Looking forward to some active discussions based on this!
@cintiadr That’s a small issue I suppose.I have submitted a PR in the GitHub repo that hopefully that fixes it. Here’s the link to it : https://github.com/openmrs/openmrs-contrib-addonindex/pull/5.
Since you have manual access to the files of the deployed version, could you manually make that change so that we have it running again immediately instead of waiting for the PR to be accepted ?
On Chrome console, I have for both the deployed site and running locally:
Uncaught TypeError: Cannot read property ‘location’ of undefined
at new e (react-router.min.js:1)
at p._constructComponentWithoutOwner (react-dom.min.js:13)
at p._constructComponent (react-dom.min.js:13)
at p.mountComponent (react-dom.min.js:13)
at Object.mountComponent (react-dom.min.js:14)
at performInitialMount (react-dom.min.js:13)
at p.mountComponent (react-dom.min.js:13)
at Object.mountComponent (react-dom.min.js:14)
at a (react-dom.min.js:14)
at r.perform (react-dom.min.js:15)
That fix anyway applies irrespective of as to whether the site runs now or not .That’s because the previous link to the resource (React-Router) is no longer valid. The current link points to the new location of the same resource.
@cintiadr I’ll take some time out and run it on my local installation and get back .
@cintiadr The issue is now fixed(pull request with fix waiting to be merged) and I have posted a detailed post about the same here since I’d like this thread to focus on add-on index enhancements discussions
There is already API support for tags (which you put on an individual add-on) and for lists (top-level idea of a list of add-ons). I’m sure the UI around the tags could be improved. And we definitely need to do the manual work of putting the correct tags and lists given our existing add-ons.
+1
We should not implement any features in this tool that require the user to log in. (This is to keep the tool’s complexity lower, and leverage features already available elsewhere.) I would prefer that we just have a link that takes people to bintray to write a “review” like Service End for Bintray, JCenter, GoCenter, and ChartCenter | JFrog and we can display the bintray comments on our app too.
I agree that we should display this data in some way (pulling it from bintray).
My preference would be that we should display ratings that are stored in bintray, but we should not implement any features in this tool that require the user to log in. (This is to keep the tool’s complexity lower, and leverage features already available elsewhere.)
Agree about cleaning up the UI to make sure we’re using consistent terminology.
+1
Low priority since nobody is actually going to download OpenMRS add-ons from a mobile device. But nice to have.
Okay. (I don’t care about this, but it will make things look a bit more pretty.)
Yes this does suffice. What I meant was like you said creating a wiki page and also adding a link in add-ons( Maybe something that says “Want to upload your own module?”)
True, I have noticed that some modules(like the form entry module) have this implemented already. I meant to say that we could improve the utility of the tags and make them clickable such that all modules with the same tag will be grouped together. This could be similar to the one being used in talk currently where clicking on any category gives us all the posts relating to that category.
That’s a much smarter approach! That way we can get reviews for the modules and also ensure that the identity of the reviewer is known while not having to implement our own login mechanism.
it