@reubenv yes user ratings would be great! But as you know, some users will still not participate in the rating activity.
I had been planning to index all the modules that are released to mavenrepo as the starting point for going live on this addons project. But if we’re going to sunset the mavenrepo server I will probably need to take another approach (since I’m counting on the awful nexus REST API).
One idea is that I should just index what’s currently in modules.openmrs.org directly (and we eventually migrate that to bintray). Or I could start indexing from artifactory. In the long run do you think we want to support a model where a module is released only to artifactory, and not to bintray or github releases?
The plan is to configure Artifactory to push all module releases to Bintray automatically. The Add-On Index will be able to use just Bintray. In fact I was planning to configure pushing all our releases to Bintray including wars and distros. Would it make sense now to extend the Add-On index to be our Releases index?
In a week I’ll confirm, if it can be done for historic releases (so that you do not have to index modules.openmrs.org).
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 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.
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 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 amazon.com 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 :
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)
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., http://darius.is.om.rs) 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 addons-stg.openmrs.org
- 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”).
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?
(for Option B you’d need to scroll farther to get to the end of the list)
I prefer Option B as two columns are difficult to read on smaller screen
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?
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.
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