DISCUSS: how often to update which tablets at beta sites?

[JackMostow]

It’s not clear which versions(s) we should use at our beta sites?

a. Update as often as possible +: kid-test improvements ASAP +: enable data-driven design iteration -: more work for Fortunatus and Mwita

b. Stick with 1.8.9.1, same as at code drop 1 at XPRIZE sites – though they’ll be starting over as XPRIZE rolls out the fix for an installation bug that prevented data upload. +: easiest (no updates) +: results more predictive of XPRIZE sites +: longitudinal results more meaningful

So I thought of a hybrid: c. Pick one “alpha” tablet at each beta site to update as often as possible, and update the other tablets less often. +: less work for Fortunatus and Mwita to update one tablet than 5-6 +: kid-test improvements ASAP +: enable data-driven design iteration +: results on the other tablets more predictive of XPRIZE sites +: longitudinal results more meaningful -: extra work to keep track of two deployed versions -: possible “ice cream cone” effect if the other kids notice their friends have something new

d. Update [1] “alpha” tablet at each site as often as possible, update [3] tablets less often, and leave 1.8.9.1 on [2] tablets. +: less work for Fortunatus and Mwita to update [4] tablet than all 5-6 +: kid-test improvements ASAP +: enable data-driven design iteration +: results on the tablets with 1.8.9.1 more predictive of XPRIZE sites +: longitudinal results more meaningful +: possible to compare new versions against 1.8.9.1 baseline -: extra work to keep track of 3 deployed versions -: possible “ice cream cone” effect if the other kids notice their friends have something new -: less data in all 3 conditions

Questions:

1. How many kids suffice to kid-test a new feature informatively enough to inform design iteration?

2. Which kids do we want for alpha-testing, if we even have a choice? a. Lowest kids may be more predictive of XPRIZE sites b. Highest kids may reach new activities sooner c. Diverse kids may expose more problems d. We may have very little choice. If we can’t change which kids use the alpha tablet, we’ll just have to pick which diverse group is best.

Comments? Questions? Recommendations?

[JackMostow]

Judith - As discussed, please:

1. Pick a suitable network speed test that can run on Android. Many network speed tests are just for Mac or Windows, so see Top 10 Best Internet Speed Test Apps for Android in 2018

2. Help Mwita run it on an Android tablet on at least 2 days when he has free WiFi.

3. Post the results.

For comparison, I just ran www.speedtest.net on my home PC and got the results shown.

IP_ADDRESS	TEST_DATE	TIME_ZONE	DOWNLOAD_MEGABITS	UPLOAD_MEGABITS	LATENCY_MS	SERVER_NAME	DISTANCE_MILES
173.75.12.11	6/14/2018 2:20	GMT	14.66	12.99	26	Pittsburgh, PA	0
173.75.12.11	6/14/2018 2:22	GMT	16.06	11.44	29	Akron, OH	100

Thanks! - Jack

[JackMostow]

@judithodili -

1. Thanks for volunteering to serve as point of contact with Mwita. Please cc me on email to him to keep me updated.

2. We need to know the actual upload and download speeds at night when WiFi is free in order to make an informed decision about how often to update. What's the status of this task, and how soon can you complete it?

3. Does it make more sense to automate the task by deploying an app that runs a speed test at night on one of the tablets, and logs its output to a folder that already gets uploaded by DriveSync? If so, must we implement our own, or can we use an existing app? There are many free Internet speed tests on-line, but we need one that we can:

   a. Deploy to Mugeta so it runs locally rather than in a browser. E.g. Speedtest.net APK v4.1.9 downloads an APK (11.5 MB), so we can use DriveSync to deploy it.

   Netflix's FAST Speed Test installs a local app, but measures only download speed, not upload speed; also, is it possible in Mugeta to install from Google Play Store?

   b. Schedule when to run: E.g. testmy.net lets you schedule a periodic speed test, but from a browser. Is it possible in Mugeta to run a browser in order to perform this step?

   c. Run without requiring user interaction: We'll need to check.

   d. Configure where to write results, so that we can store them in a folder uploaded by DriveSync: We'll need to check.

   e. Doesn't install adware or other bad stuff

   f. Any other requirements?

Thanks. - Jack

[JackMostow]

@judithodili I realized what may be even simpler, or at least doesn't require a separate app: just upload drivesync.log from /storage/emulated/0, and analyze it to figure out the actual speed in practice. drivesync.log is an example drivesync.log. Every line starts with a timestamp, so subtracting the first from the last timestamp tells total time elapsed. Computing upload and download time would require parsing drivesync in more detail, or using other means to measure the amount of data uploaded or downloaded. Thoughts?

[judithodili]

Mwita ran these tests at night. While these numbers seem decent, I'd rely on having him download an actual RT 20MB file, and tell us how much it took him from start to finish to download on a weekend.

I can coordinate this if you like... we can just have him download the old RT version.