OWA App Store GSoC project

Ok will be waiting then. Please don’t forget to ping me when its done. :slight_smile:

1 Like

It’s not broken, it’s just not the easiest to setup – it’s documented – but we just wanna make it as easy as possible.

1 Like

Hi @sunbiz @pascal

I have been working on some mockups and i would like to get you feedback on them.

I am still documenting my use cases but i would like to get your feedback on these ones for now and also would like to know if you had a few non obvious in mind especially for the admin section. These are just for the changes on modulus frontend, that for OWA module will be a little different. Also i noticed that for modules we keep all versions of module and the user chooses which to download. But on conventional app stores, only the latest update is available for installation. So what do you think would be best(keep all app versions or just the latest version).

1 Like

Missed one screenshot…

Given that we have modules, web application apps, and OWA apps in our ecosystem, it would be nice to try to consider how we can manage these in a way that is simplest (and least confusing) for users and developers.

  • Modules – traditional OpenMRS modules
  • Applications “apps” – the “apps” we see in the Reference Application home page and the “apps” showing up in various Angular-based distributions of OpenMRS
  • Open Web Apps – apps that follow the OWA spec and are installed via the OWA manager

There are definitely going to be cases where people will just want to browse one of these types (e.g., in the OWA manager, you only want to show OWA apps); however, I can imagine there will be other cases where people may want to look at all the things offered across types (e.g., “all extensions that have to do with diabetes” or “all extensions rated highest”).

So, creating an app store is all good, but it’d be nice if we supported (or were prepared to support) the ability for someone to browse all types of extensions through a single UI – i.e., create a unified UI that can easily filter to a specific type (and maybe even do that by default) but avoids creating a separate UI for each type. For example, if we add user rating capabilities for modules, it’d be nice not to have to repeat the same work for apps and OWA apps or have them behave differently.

Lastly, can we come up with some friendly terminology than “OWA” for users? Or is teaching people the distinction between “web application” apps and “OWA” apps enough? Or is there a way we can prevent users from having to care about this distinction? My instinct would be to distinguish between “web apps” and “apps” (i.e., “apps” are the things you add to your web application’s dashboard and “web apps” are almost like little standalone web applications themselves that may offer similar functionality but follow the OWA standard.

Anyway, I mainly just want to make sure we don’t end up (1) confusing users and (2) creating unnecessary distinctions between various types of extensions in modulus that we aren’t able (even if its done later) to show them in a unified interface.

-Burke :burke:

1 Like

@burke, this may be a distraction from the GSoC project focus of this thread, but I should point out that what you’re calling ‘Application “apps”’ are not something that exist in downloadable form, they are merely a UI approach that we used to build the reference application.

Specifically, anything that attaches to the extension point org.openmrs.referenceapplication.homepageLink is displayed on the home screen. A module could provide zero, one, or many of these. Also, an administrator can add these things through an administrative UI.

There’s an ongoing discussion here between Saptarshi and I about letting OWAs add these “homepage apps” too. And like a module, an OWA could conceivably add 0, 1, or many homepage apps. (The spec has a single start_url, but there’s nothing to prevent multiple homepage apps from having deep links into an OWA.)

Anyway:

  • I agree we should have one unified “store” for modules and OWAs
  • by default I’d assume this should start from the current modulus UI
  • we do need users to know that homepage apps are not the same thing as OWAs.

I noticed that writing the same code for modules and OWA is not a very good idea. I agree we should definitely have a unified UI, this will not only make life easy for users but also for developers. Just so we are on the same page, you are suggesting that we should not have different UI pages for the same functionality twice, like for example instead of creating separate forms to upload module or OWA, we should just have on upload form that is able to upload either an OWA or a module. And also users browsing the store should see all available extensions(OWA or module) from the same UI, but maybe in the description page of a particular extension we mention what type of extension it is since they have different ways of been installed. So the approach will be redesign modulus-ui to provide a unified interface for OWA and modules but the owa manager running in openmrs webapp should only provide a ui for OWAs. I guess we need a generic name then that will group together OWA and modules.

Creating a distinction between OWA and homepage apps. @burke I agree this might be a little confusing to users and it is very important for us to make users understand the difference, but is the distinction between the two a responsibility of the store? I mean the store should just take care of hosting extensions, whether OpenMRS module or OWA. Also since homepage apps have a different workflow, putting it in a unified interface together with modules and OWA does not sound like a good idea to me. Will a wiki be enough for this or you had something else in mind about how to make users understand the difference. @sunbiz, @pascal i would love to hear your thoughts on this.

1 Like

I am saying that the user should experience a single “store” from which they can access all OpenMRS extensions (modules and OWAs), and since we already have a “modules.openmrs.org”, this store should be the next version of that. In the same way that Chrome Web Store has both Apps and Extensions.

I guess I probably agree with the specifics you have said, but I haven’t thought it through.

I think the store only needs to know about Modules and OWAs. (The documentation of a Module or OWA should eventually state how it will appear in the reference application, and that’s all that the “application app” or “homepage app” is.)

3 Likes

I’m probably showing my ignorance here, but do we really want consumers to have to distinguish between modules and “owas”? Aren’t they more or less functionally equivalent to the end-user? If we were to build a “concept management” owa that adds a new app to the homepage that is backed by one or more pages with one or more functions, how is this different to an end user from us providing a “concept management” module that provides the exact same thing?

Mike

2 Likes

Probably different in the way they are managed within an openmrs instance, am not yet very much into the OWA openmrs stuff though and just thinking :thought_balloon:

I agree, that they are functionally equivalent but they have different ways of been managed(installed, uninstalled, updated). But i think we can still hide these details from the end user. That is if the store only allows owa or module installation directly into a running openmrs instance, as it is done by other appstores, it will be possible to hide this underlying difference of how they are installed. But when the store supports downloading of apps and modules which can be manualy installed by an admin, it would be difficult to hide the difference between OWAs and modules since the installation process for OWA and modules are different. Still, even if the we are able to hide the details of installation, an admin will still need to be aware of the fact that these are managed differently since modules are managed from the manage modules page legacyui, while OWAs are managed from OWA module. To hide this detail too, i think we will need to add something like a manage extensions page inside core that will handle the management of OWA and modules with a uniform interface, in such a way that an end user may never know that there is actually a difference between the extensions.

cc @darius @burke @pascal @sunbiz, i would like to hear your thoughts on this.

1 Like

The end-user doesn’t care whether something is an OWA or a Module. But the system administrator who is managing an OpenMRS system should care, and should know that they are different.

An OWA is lightweight and costs nothing to deploy (but is more likely to require the admin to have to do manual configuration to attach it to the reference application UI).

A module is heavyweight and expensive to deploy, and it also has more (potential) security implications.

1 Like

Yes i think this is the best approach. The administrator should definitely be aware of the difference.

1 Like

My primary concern at this stage is that we avoid creating complete distinct & competing mechanisms for handling these different types of extensions in modulus. Instead, let’s enhance modulus to understand that there are more than one type of OpenMRS extension. Not everything will be a module. Starting now, some things will be OWA apps. In the future, we will likely add a new type of extension (i.e., our vertical packages that include a mix of modules+apps+content).

So, to get more specific… assuming we use the term “extensions” for the all-inclusive name for these things, I’m proposing something like:

  • Consider adding extensions.openmrs.org as an alias for modules.openmrs.org that we will begin transitioning toward being the default.
  • Add “extension type” as a property of entries in modulus (e.g., “module” or “owa” for now, will likely have new ones in the future)
  • Start migrating the modulus API from “modules” to “extensions”. This could begin by adding OWA capabilities through new “extension” endpoints that include both OWA & modules in responses.

Clients that want to filter to specific type(s) of extensions should be able to do so easily by specifying the extension type(s) in their API requests. So, for example, an OWA manager could show an embedded “OWA app store” backed by modulus via only asking modulus for “owa” extension types; the module manager could be refactored to do the same except limiting its view to “module” types. Users visiting modulus could have a UI that shows both in a unified interface.

An important outcome of this approach is that, when we add user ratings and other features, we don’t have to repeat the work for each type of extensions independently; rather, we add these features with the understanding that there are different types of extensions and all extension types benefit from the new features.

3 Likes

Hi @burke

I had something like that in mind even though it was not well polished like you just did. If you look are the screenshots i shared you will notice, that i did not create a different UI for OWA, I just extended modulus, but i guess they were not clear enough and my idea was not exactly like yours. Because with my idea, i had to add new html partials for OWAs and replicate most of the grails services and controllers to work with OWA, now i see that will create the problem you suggested that when changes are made, they will have to be replicated for both OWA and modulus. I think your approach will be the best and i would like to know @darius, @pascal and @sunbiz thoughts about it.

Also i wanted to find out what you all think about version management in the store. I mean with modules, you have the option of downloading what ever version of the module is available, but with appstores, as you click on the install button on an app, it installs the latest version of the app available. This can be done from OWA manager since that is the only place where we can install an app directly into a running instance of openmrs. But from extensions.openmrs.org(an alias for modules.openmrs.org as suggested by @burke ), since we cannot be sure if the person browsing there is having a running instance of openmrs, we can only provide him with a download option, so my questions is should i maintain the convention for modules where when you click on an app it shows you all the available versions to download from or should it just display the lastest version of the app as it is done with most app stores.

Yes, I broadly agree with @burke.

In my opinion the most important user of the store is the administrator of a production OpenMRS installation, and for that user persona it’s more important to get the right thing, than it is to do a one-click download.

So, I believe the store UI should work basically as it does now, that when you pick a module/extension, you see all available versions (should also show info about requirements to run those versions).

Being able to install directly from the store is a nice-to-have, more valuable to developers than to real implementers, in my opinion.

Hi @sunbiz

I have shared a draft proposal with OpenMRS. I will appreciate your feedback

1 Like

Hi All

The deadline is fast approaching and i have not had any feedback on my proposal yet. @r0bby i know you already made it clear that you review proposals only for your project, but it will be an honour to get feedbacks from you. :slight_smile:. I have already ping @pascal and he says he will look at it, but will appreciate feedbacks from anyone available.

I will look at it later today

1 Like

I added comments to the proposals by @vishnurao and @ivange94.

2 Likes