🚀 1.2 #581
Comments
ivan-aksamentov
added
t:feat
ivan-aksamentov
added
IMPORTANT
|
regarding the sharing of scenarios via URL: could you maintain a simple cache/hash table (probably separate from the app server) to essentially have random keys and parameters as values? Then URL references could be like https://covid19-scenarios.org/Aeif13D, the app would use the Aeif13D key to pull the parameter JSON string from the hash table, and we would have nice shareable short links? entries could be evicted after a while (or if possible, after they haven't been queried for x days). I only used redis a while back, and one would have to do the math to see how much data would be stored in the DB/day etc. Uploading files could be left as addition for people that want to use the app more as an API. |
|
@noleti this is what I imagine as well. |
|
another maybe: localization? We would a) need enough translations (and verify they currently catch everything needed), b) see that it works in the current UI |
|
Regarding the URL suggestion, we thought about it previously. This is basically a URL shortener service (like Regarding translations, I don't know what has to be done. In order to translate, we need English version to be finalized. But it's never final because we change everything every day. So I guess the translations have to be done in an incremental fashion. But that's kinda annoying for the translators. |
|
In my view, there are two distinct target audiences: "consumers" and "pros". The former will just look at a graph for their country, and not play with values too much (at most starting infected, ICU beds, and R0/ mitigations). The latter might want to try many different scenarios, seasonal influence, severity assumptions, age distributions, etc. For the former, scenario sharing should be as easy as possible, i.e. the hash in the URL, lookup from DB by your API. The latter user group will be more comfortable with downloading files, changing or generating files on their side, and re-simulating based on the files. That audience would also need more API capabilities (e.g., just return results, plot.png, pdf based on uploaded file). Once they have settings they want to share, they could just use the URL shortener again. I don't really see the issue with sharing the same DB for stable and testing instances, as long as the DB is key/value store (e.g. Redis). If keys are all pseudo-random, the instances should(TM) not interact? The values should have a metadatum about the version of the schema, maybe. If you start to use a nosql DB with schemas etc (e.g., MongoDB), things will get more complicated I guess (i.e. new versions require new schemas). Or do you mean SQL with "normal database"? There would be the same schema issues I guess? Storage-wise: I'm not sure how many users you have daily, but lets assume 1M. If each scenario settings needs 3kB (current settings export), then this would be 3GB. But the current settings have some crazy float precision (and pretty printing), so maybe 1kB/setting is more realistic. Given that many users will concentrate on few countries and default settings, I assume using a hash of the settings as key will lead to further storage reduction. So the database would maybe need 10GB if values are kept for a week (more to be on the safe side). cache.r4.large aws instances with 12 GB RAM cost about 150 USD/month? So key:value caching with minimal REST API boilerplate on your server seems feasible to me. Not that I am volunteering to write the code though. Regarding translation: I think we will have to live with the risk of having some untranslated strings. The Gitlocalize should make it easy for people to contribute, though. We just need to write some instructions/advertise this (If we want to use localization soon). I think we should also start to use "placeholder/ID" strings in the app code, and have the actual text in the EN translation files. but I didn't dig into this yet. |
|
@noleti By "normal database" I mean whatever stores data in a typed format, not just a string of serialized JSON (which our URLs are). For shortener, hosting or storage cost should not be a problem. Why do we need to use placeholders in the app? Won't English text do for placeholders? It seems to be working alright so far. |
|
Re: placeholders. The way I understand the localization setup from #494 is as follows: we extract strings from the .ts/.tsx files, and generate these dicts from the strings. the dicts currently are setting the value to key by default. This means that if we change the original string a bit, a new key will be generated and needed to be translated in all languages. If instead we use placeholders, we can decide if the english string only changed a bit (and keep the placeholder and all existing translations), or if the meaning is so different a new translation needs to be done (by introducing a new placeholder). Does that make sense? I am not used to i18n, so I might misunderstand things. |
|
@ivan-aksamentov Is this what you had in mind for the tooltip layout?
|
|
@noleti @ivan-aksamentov I agree for the localization, this would be great to re-enable the language dropdown. Because there is no point in updating the translations if we don't use them. For the debate between using real strings as keys / using IDs to reference translated strings in the code: I see your point about – modifying translated text in the code also changes the key used for other languages. The problem with using keys is that if you decide to update a text in English, the other languages will still have the old translated version, which could not be relevant anymore if the text changed a lot. Worse: in gitlocalize, you won't easily see that a translation isn't up to date. On the contrary, by using directly the string as key, it also removes the translation, avoiding the risk of having translation mismatchs. That said, I understand that it's not perfect: if you remove a space in the code, every corresponding translation will be reset. But I still think this is the best tradeoff for now. Maybe another translation platform than Gitlocalize could spot outdated translations, but that's not the case right now :/ |
|
I think we should just report the percentiles as absolute numbers, not
plus/minus the median. I like your suggestion of (low, <b>median<b>, high)
…On Tue, Apr 21, 2020, 1:34 PM Ivan Aksamentov ***@***.***> wrote:
@davihans <https://github.com/davihans> I am not sure. We need to ask
@nnoll <https://github.com/nnoll>. Also this may influence the format:
#613 <#613>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#581 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHAVMG2WG3IPPUAVOW47X7LRNX7L7ANCNFSM4MK4CAYA>
.
|
|
Uncertainty is released in 1.2 |
|
This is a superissue to aggregate and prioritize issues and PRs currently in the works
https://github.com/neherlab/covid19_scenarios/milestone/3
🍎 Core features
- Uncertainty of parameters
Some parameters are now ranges
{min, max}. Results are now a distribution[{mean, lower, upper}]run progress indicatorlooks like this cannot be done for the computation on the same-thread. Maybe with webworkers or something like redux-saga?- Mitigation presets
Mitigation table should be populated with real data
- Parameter upload
Currently scenarios can be shared via URL. It is not perfect and we constantly have problems with it. File sharing would be another option.
Proper JSON export: all parameters required to exactly (barring the uncertainity) reproduce a run should be present, and nothing more
New JSON import (it should reproduce the exported run)
New UI/UX for import
[x] Dialog instead of scenario dropdown: Replacing the scenario dropdown with "Load scenario" dialog #397 feat: Preset loader #490
[x] JSON Import: JSON import/export #541
[ ] Better styling for import window and dropbox
Better UX for JSON export
Proper serialization and validation against JSON schema
Proper error handling and error dialogs
Versioning
- Double-check URL validation and add error dialogs
Currently errors in URL import are are silent for the user
🍌 Important
- Automatic data updates
- Algorithm in a webworker
- Fix remaining type issues and enable build-time type checking
- Translations
🥝 Maybe
- Additional details in PDF
- Improve error pages
The text was updated successfully, but these errors were encountered: