App Hub & App Management App idea dump

[amcgee]

App Hub & App Management App idea dump

This is a braindump of ideas for features and improvements which we want to support (either immediately or further down the roadmap) in the App Hub and App Management apps. This is intended to serve as a framing for the upcoming design and implementation phases for our application distribution infrastructure.

Additional thoughts, ideas, and concerns are more than welcome! We will also need to triage the full set of functionalities in order to develop it iteratively, rather than all in one go.

AppHub

Thoughts on Sketch spec from Joe:

• What do we expect from the "demo" link?

Thoughts on existing App Hub:

• Apps should have canonical URLs -
  • /apps/xyz and /apps/xyz/edit (If we need different URLs, preferably it would be state on the canonical page based on the logged-in user)
    • /apps/xyz/edit should always redirect to /apps/xys if no edit permissions
  • Instead of /apps/xyz and /user/apps/xyz
• Links to "contact developer" and "view source" should be exposed to the end user
  • (don't expose the actual email address though, we'll need to proxy it through a gateway maybe with Mailgun
• Apps should probably have a dedicated "documentation" link exposed
• Versions should be immutable and new versions of existing apps should require a CHANGELOG entry specifying what change.
  • The changelog should be highlighted on the app page - see Apple App Store, Garmin App Store, etc.

AppHub Features we want (not ordered):

• Reviews
• "Download count"
• Enforce matching name, slug, and icon in .zip files
  • Probably don't want to support manual icon or name in the AppHub, just use the one in the app
  • Don't let the name/slug/icon change - if it does, we need to change it in all existing version .zips
• DHIS2 version support should be specified in the app manifest, not in the AppHub UI
• App slugs should eventually be namespaced by organization (requires more work on DHIS2 app infrastructure)
• Should highlight a list of DHIS2 instance / metadata requirements
• Should highlight, and eventually enforce, what access and actions the app performs - i.e. does this edit medatada? Does it edit users? Does it view tracker data? Aggregate?
  • Eventually we should enforce this using OAuth authority grants
• Should support highlighting certain "high quality" or "UiO recommended" apps
• Should support app tags, based on what they do - "dashboard apps", "data visualization", "configuration", "data entry", etc.
• Should maybe highlight new apps and new versions of "popular" apps
• Support login without Google - i.e. GitHub or username/password
• NEED to support M2M authentication tokens, so that it's possible to upload an app (or at least a new version of an existing app) from the command-line. Each user should probabbly have a "Personal token", like GitHub does, and maybe the ability to create more than one. Might be helpful to allow creation of tokens at the organization level as well.
• The AppHub should require screenshots with new app uploads, and should require that an app has a unique icon (in App Hub but also in the app itself)

App Management App

• Need to support AppHub search, as well as exposing ALL (or most) of the metadata we have about an app in the App Management App interface
  • We should, as much as possible, reuse the exact components we build for viewing app details in the App Management App
  • I think apps which are NOT supported by the current DHIS2 version should also be shown, but disabled with a clear reason why
  • Similarly, apps which support the current version of DHIS2 BUT ONLY FOR OLDER VERSIONS OF THE APP should be clearly indicated
  • Older versions should be hidden but accessible
• Apps which are currently installed in the system should be hidded from the search and/or should be clearly shown as "already installed"
• The list of currently installed apps should clearly show which ones came from the App Hub
  • They should also have a prominent button allowing that app to be updated when a newer version of the app exists in the App Hub - currently the user needs to go find the App Hub app and install it again
  • We might also want a way for the user to downgrade the version...
• Installed apps should be groupable by "tag"
• We might want to show which user roles have been granted access to an app from within the App Management App (reverse lookup)
  • Maybe with the ability to edit...? If the logged-in user has that authority
• "Core" apps, including those which were bundled with DHIS2 and haven't been installed from the App Hub, should be shown in a different tab than the installed apps.
  • These should also feature an "update" button when there is a newer version available!
• Manual app uploads which will OVERRIDE a core app or an App Hub app need to require verification before being installed, as it will disrupt the update logic

Eventual features (to keep in mind, but not to implement now)

• Eventually we will want to send messages or otherwise notify system administrators when new app versions are available
• Eventually we will want to support "previewing" a new app version within your instance, before "promoting" that app to send it to all users.
• Eventually we will want to have a standardized, consistent way to configure applications, rather than requiring apps to implement their own infrastructure and interface for this
• Eventually we will want to support an opt-in "send anonymous diagnostic reports to the app developer" (including for core UiO apps)
• Eventually we will want to support separate "language packs" for core and installed apps, rather than always bundling all languages in the app itself.
• Eventually we will want to support metadata packages through the Hub (MetaData Hub) which may or may not be installed and linked to one or more apps
  • This is becoming quite high-profile, as the manual process of creating, distributing, and installing metadata packages for lots of different DHIS2 versions is super cumbersome
• Apps should eventually be bundled together, and/or declare dependencies on other apps or certain metadata configurations

---

Prior art

Garmin App Store

[cooper-joe]

Meeting notes–28/01/21

Present: @cooper-joe, @Birkbjo, @deboragaleano, @mediremi, @scottrusspatrick, @varl, @amcgee

Topics for discussion:

• What features raised above by Austin will be included in, or be considered for, ongoing design mockups?
• Will App Hub and App Management apps share use cases of discovery and management?

App Hub features for consideration

The following features and concepts were considered for an update to the App Hub:

Changelogs

• Decision: Include in design mockups. Required on app update, but not reviewed by the core team.

App Ratings / Reviews

• Full 5-star rating system probably not necessary, could be simplified with a Like feedback system to distill user sentiment.
• Feedback to app developer could be facilitated through the Community of Practice, this has already succeeded in one case.
• Flag this app could be useful where there are problems to report that would result in a 1-star review in traditional rating systems.
• Visitors to the App Hub are looking for some kind of verification that an app is of a certain quality. This can be achieved through other methods than a rating/review system.
• Decision: A simple feedback system: Like, Report a problem to the developer, Flag this app will be included in design mockups. Technical and implementation discussions will inform final decision to include or not.

Download count

• Not a reliable indicator of how much the app is in use.
• Installed on # instances would be more reliable, but requires analytics we do not collect.
• Do not expose to visitors, but potentially make available to app developers to encourage ongoing support of apps.
• Decision: Defer until a later version. Keep in mind for designs, but do not include in mockups.

App Categories

• Will be self-curated by the app developer. Can be changed by core team when reviewing.
• Current use of Types can be deprecated and consolidated into a single Category label.
• Decision: Include in design mockups. Deprecate Types and use only Category.

Highlight Recommended by DHIS2/UiO/Core Team Apps

• Recommended apps can be badged and/or highlighted.
• App Hub could also have larger Featured or Recommended sections
• Other badges could be App Competition Winner, App Competition Finalist
• Decision: Design mockups should include Recommended as subtle badge. Keep in mind that larger sections for highlighting Recommended apps may be used in the future, dependent on App Hub growth and traction.

Highlight app access and actions requirements in app listing

• Decision: This should be included in the App Hub description now. Implementation of an automatic detection and labelling system is deferred.

Highlight app instance and metadata requriements in app listing

• Decision: This should be included in the App Hub description now. Implementation of an automatic detection and labelling system is deferred.

App Hub vs. App Management use cases

• There are two different usage patterns: discovery and management.
• App Hub facilitates discovery, App Management facilitates management.
• Reusing components is good, but not a critical need.
• Decision: Discovery use case should be included in both App Hub and App Management apps.

Other notes

App Management

• It is important to be able to distinguish between Core and Custom Installed apps
• Update app user flow needs attention

---

Next steps

• @cooper-joe will create design mockups based on the above decisions. These design mockups will be shared and will eventually form the basis of an implementation spec.
• Technical discussions can begin regarding agreed upon features, where priority and time permits.