worldhealthorganization / app Goto Github PK

Overall tech design of how we are defining the survey questions that will be a part of the Diagnosis & Triage goal of the app. Should be able to be baked into the app bundle for offline functionality, but also with the ability to be overridden with updates from the server. This task should include a plan for the relevant data structures, internationalization, etc

Should use native share sheets - look into Ionic's Social Sharing and Action Sheet components. Should be a modular component that can be reused in the app

Regardless of how translations are created (whether manually or automatically), add the framework for i18n. Options mentioned on the call today were react-intl and react-i18next.

Starting an ongoing thread for the architecture decisions that we should make & have made as a reference. Writing this out in a quick brain dump, so leave a comment with decisions that are missing. Goal should be to make these decisions quickly and not look back once made. Will continue to update this as the discussions/decisions progress.

• Client Framework - Decision: Ionic React for v0.1
  • Note: may move to React Native for 0.1+
• Language - Decision: TypeScript per #7
• Server - Decision: Google App Engine + Github Pages
• Initial Client Scaffolding
  • See #33
• CI
  • See #12
• State Management Library
  • Whether we want to use one, or whether Firebase will serve our purposes well enough
• Routing / Navigation Library
• Code Style
  • Whether we want to try to standardize this now with linters and/or Prettier, or whether that's a future us problem
  • See #30
• Tests
  • Whether test coverage is a requirement, or whether that's a future us problem due to tight time constraints
• Git / Workflow Standards
  • How strictly we want to use standard git flows, whether or not we want to implement standardized commit messages (e.g. something like AngularJS's guidelines), etc
• Device Support
  • See #13
• Automatic Security Enforcement
  • Snyk.io, GitHub's built-in, both, others?
• Dependency updates
  • Dependabot/GitHub, others?
• Dependency / Build Management
  • Initial React Native scaffolding uses Gradle for Android, CocoaPods for iOS
  • Currently using yarn for JS dependencies, but should decide yarn vs npm
• Localization & Internationalization Strategies/Library
  • Proposed in #21: jquery.i18n (PWA), react-native-localize (React Native), react-i18next (PWA), react-intl (PWA)
• Strategy for Dynamic & Offline Content Delivery
  • See #24

...what else?

Once someone has initial, properly licensed (MIT/Public Domain), assets let's get them checked in.

Proposed contribution rule:

• For each dependency you add, acknowledge it in your PR description and describe why you chose it, its license, and a summary of how widely it is used in the open source community (do known apps use it? does it have known backers?)

Hey all, heads up that there is a Slack set up for this project: https://join.slack.com/t/who-app/shared_invite/zt-cq5agryq-GDRTN4bU284Z7PPZZiEIvA

(side note - @SamMousa can you please install the Slack app for this Github repo so we can integrate the two and have all notifications in one place?)

• All strings must be translated.
• All formatting must be locale-specific.
• Need to choose a service for translation or get authoritative translations from WHO.
• Images should ideally not contain any text or locale-specific content.

In order to get started, I was wondering what tech stack we will use to develop this project.

Was thinking React-Native. Thoughts?

• Apple App Store credentials
• Google Play credentials
• Management/distribution of sideloaded APK (if we want to do that)

Suggestions: Travis or GitHub's new actions
I'm very familiar with travis for open source. I am not at all familiar with GitHub's actions system.

@brunobowden and I have worked on a project using Travis long ago.

This requires some investigation if you want to deploy the app in China, you need to deploy to 6-7 different ones to cover the majority of the users.

potential contact person:
https://twitter.com/shuding_
https://twitter.com/youyuxi

React native, TS, just some text on screen
https://github.com/madvay/who-covid-app/tree/master/covidapp

Finalize and set the access origin in client/ionic/android/app/src/main/res/xml/config.xml

Going to throw some useful resources in here for cordova:

https://cordova.apache.org/docs/en/latest/guide/overview/index.html

http://cordova-multiplatform-template.js.org/

https://github.com/CKGrafico/Cordova-Multiplatform-Template

I think it would be prudent to avoid adding multiple SDK's (ionic) on top of one another, as well as limiting to JS instead of TS for the time being.

a designer who is strong in visual and branding design, as those are not my skills. My focus is on interaction

do we want to have a hook to allow users get notified when local maps is coming. might be overkill for the initial release but it is a nice way to get users back.

Review the permissions requested in: client/ionic/android/app/src/main/AndroidManifest.xml

https://www.who.int/about/who-we-are/privacy-policy.

Link to the website.

Using server side setup from #64, integrate dynamic content into the app. Should bake the initial content directly into app bundle for offline functionality, but server side content can override

Working draft of current team roster needs updating please; first draft has been taken from the initial intake form plus some threads on Slack but is not complete. Apologies if I missed you; please add yourself or correct information if needed.

https://docs.google.com/spreadsheets/d/1jt4xrXWUnsh8DmtawNV4XGBj8RAdgn-d7ckgL2qEXPM/edit?usp=sharing

One dead simple choice:

1. A YAML file with the headings, titles and images, and control flow of options.
2. Each app store update we bake in the most recent YAML.
3. Check access to our site for updated YAML and remote load it if available on start.
4. All assets baked in for the baked YAML, YAMLs online use remote assets too.

I'm sure there are frameworks though.

Keep it simple in v0.1, or go extensible in the beginning? Thoughts?

For dynamic content in the app

What minimum version of each device type are we targeting?

From a data driven perspective, there is probably a dataset somewhere which describes the popularity curves for android and ios, although I don't know off the top of my head where it is.

Also, we could cross correlate with disease demographic curves to optimize for impact in the target population. That's probably an over optimization at this point, and we should probably just pick a sensible value for each.

I've been using SurveyJS (https://surveyjs.io/) a lot.
It's a pure JS survey tool that takes a survey definition in JSON and runs a survey.

It supports advanced routing loting and multiple languages.
Should be simple to integrate into an app to do the actual survey.

Will allow us to easily change the survey in the future.

It doesn't have data submission built in so that's perfect for the first iteration where providing information and recommendations is the most important feature.

https://xstate.js.org/docs/

placeholder tasks for the future

For v0.1 and initial launch, Ionic React is the fastest way to get a meaningful MVP on the App Store that will handle distribution of necessary information and triaging. Downstream product requirements may necessitate more native functionality (e.g. background location fetch, etc) that is handled better by fully-native solutions like React Native rather than PWA

Design is a WIP but want to get initial UI set up as a starting point with the currently agreed-upon stack. UI can be fully static at first without worrying about dynamic content or internationalization, which we can use as a base.

Latest design spec can be found here (will update when this is updated): https://www.dropbox.com/s/trysvr1ywfgeiu3/iOS%20UX%20%281%29.pdf?dl=0

Opening discussion here around potential starter kits to bootstrap

placeholder tasks for the future

Tencent mini app

I think we should standardize the code style early and set up automated tools to check / correct code style.
We'll be dealing with lots of contributions and verifying them will most likely be the bottleneck. Cognitively it'll be more efficient to have 1 style throughout the codebase.

We can make our code repository easier to read and write by automating prettier on every PR.

The current scaffold uses Expo: https://expo.io/

Expo builds on top of react-native, but we can always downgrade (or "eject") from Expo. The main benefits of rapid dev in Expo is how quickly you can iterate and distribute to non-eng stakeholders.

(If we ditch React-Native this is not important)

TBD:

• 3rd party libraries / dependency license review
• CLA / developer license review
• Verify privacy policy vs actual system #58 and #1509

Please don't edit to signify changes - GitHub makes it appear that such edits come from me. If your goal is different than what is described here, say so in comments.

I know we're operating very fast here possibly without formal CLAs, so I'm just going to leave this here. It's not legal advice to anyone else.

I, Advay Mengle, license all of my original software contributions in this repository to the World Health Organization and to the public at large, under the terms of the MIT License:

MIT License

Copyright (c) 2020 Advay Mengle

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.