...
Is Haiti the first release partner? Most advanced so far are
Haiti
Guam
Santa Lucia
Dominican Republic
Kenya
What is the timeline? Depends on GRO but ideal if we are not the bottleneck delaying the critical path on the first rollout.
What is a “Branding” at code level?
TBD, but assume some defined set of files, to include
logo
app name
any replacement text
defined set of languages supported.
Ideally we would have a repository of brandings, under version control.
Plus a pipeline that takes a new Safe Paths build, and for each branding under version control, creates branded versions of the App (APK / IPA files), ready for use in testing.
TBD whether this repository & pipeline belongs as part of the Safe Paths repo, or is external to that maintained & PM’d bey a different team. Probably makes sense for repo structure to match org structure - which I thinks points to this being external to the App.
However there are likely synergies, but also possibly tensions, with how we manage translations for text in the App, particularly when a partner wants to modify substantial parts of the text in the App and do so in multiple languages - this may point to tighter coupling with the main App codebase.
Core Team
Christian Crumlish coordinating
Ali Raizin UX strategy
Jared Snider design system
Diarmid Mackenzie or Diarmid Mackenzie (Unlicensed) testing
Abhishek Singh (Unlicensed) to help identify a key dev contact, filling in until then
Sanket K to lead deployment team
...
Minimal co-branding
Country name in app name
Country or government name and logo on splash page, on start page, in design template
Content delta(s)
Release partners likely to request changes to the base copy in the app
translations
additions, subtractions, changes
Custom (added) content
Ideally minimal.
Might include resource links or phone numbers
Might include text or other resource content
(Only necessary when the existing health authority news feed won’t suffice.)
Marketing / Promotion
Customized App Store and Google Play branding/text
Dev
tbd
Testing
There are 2 key concerns for our internal Test team
Are the branding process & pipelines fit for purpose? Is it well-documented, usable etc.?
Actually testing the branded versions of the apps, ahead of use by a customer.
It is likely that as we get comfortable with the process, we will get a sense of where the key risks lie in Branding, and be able to tailorr the testing under 2 to just focus on these risk areas, rather than having to retest the whole app. In the short term, while we are still developing this understanding, we should expect to perform a pretty comprehensive test of the first few branded apps.
We also need to consider how the custmer will test their branded version.
For Android, we can distribute APKs
For Apple, we will presumably need to use TestFlight. Some thought needed to make that work.
(maybe we should put a “rough”version of the branded app - maybe not even branded at all yet - into the App store submission immediately at the start of the process, to reduce delays later)
Implementation
tbd
Operationalizing the Pipeline
We will need clear definitions for the customer regarding:
What they can brand
What they can’t brand
What assets they must provide for the things they want to brand, and what formats are acceptable (SVG, hi-red bitmaps etc.)
In the short term, the key for efficiency will be precisely defining this set of information/assets, so we can collect with minimal iterations.
Manual collection of these assets (and manual check-in into the Repo) is probably acceptable in the near-term, at least for the first few brandings. More automation here starts to be necessary as we move into 10s of brandings.
Assumptions / Restrictions
Selection of Health Authorities will be as per the standard app, with all HAs available for subscription, and recommendations/auto-subscriptions made based on location, rather than based on branding.
We won’t offer any means of pre-provisioning HAs, or restrcting access to other HAs.
Legal Issues
Who is our point person for legal? Lee Brody
...
Handling submission officially
...
Walk their IT staff through setting up an app store accounts
What is a “Branding” at code level?
TBD, but assume some defined set of files, to include
logo
app name
any replacement text
defined set of languages supported.
Ideally we would have a repository of brandings, under version control.
Plus a pipeline that takes a new Safe Paths build, and for each branding under version control, creates branded versions of the App (APK / IPA files), ready for use in testing.
TBD whether this repository & pipeline belongs as part of the Safe Paths repo, or is external to that maintained & PM’d bey a different team. Probably makes sense for repo structure to match org structure - which I thinks points to this being external to the App.
However there are likely synergies, but also possibly tensions, with how we manage translations for text in the App, particularly when a partner wants to modify substantial parts of the text in the App and do so in multiple languages - this may point to tighter coupling with the main App codebase.
Testing
There are 2 key concerns for our internal Test team
Are the branding process & pipelines fit for purpose? Is it well-documented, usable etc.?
Actually testing the branded versions of the apps, ahead of use by a customer.
It is likely that as we get comfortable with the process, we will get a sense of where the key risks lie in Branding, and be able to tailorr the testing under 2 to just focus on these risk areas, rather than having to retest the whole app. In the short term, while we are still developing this understanding, we should expect to perform a pretty comprehensive test of the first few branded apps.
We also need to consider how the custmer will test their branded version.
For Android, we can distribute APKs
For Apple, we will presumably need to use TestFlight. Some thought needed to make that work.
(maybe we should put a “rough”version of the branded app - maybe not even branded at all yet - into the App store submission immediately at the start of the process, to reduce delays later)
Operationalizing the Pipeline
We will need clear definitions for the customer regarding:
What they can brand
What they can’t brand
What assets they must provide for the things they want to brand, and what formats are acceptable (SVG, hi-red bitmaps etc.)
In the short term, the key for efficiency will be precisely defining this set of information/assets, so we can collect with minimal iterations.
Manual collection of these assets (and manual check-in into the Repo) is probably acceptable in the near-term, at least for the first few brandings. More automation here starts to be necessary as we move into 10s of brandings.
Assumptions / Restrictions
...