simplify handling of media uploads

[jshslsky]

1. Drop maxDuration on audio and video prompts.
2. Drop maxDimension on image prompts.

@cketcham @stevenolen @hongsudt can you see any reason why we actually need these restrictions?

We will just leave out these restrictions for 3.0 and then add them back in 3.1 if we can formulate a good enough argument to add them back. For 3.0, we are going to go with a universal maximum for upload sizes and then we'll come up with max file sizes for the different prompt types.

[stevenolen]

I think they may be quite important, actually. They exist (based on my understanding) as a way to limit the data consumption on participants' phones. Eg. if a participant is required to collect 300 photos in a month, perhaps the study coordinator would like to limit the amount of (a potentially limited) user's data plan, since they may only need small images for the study purposes anyway..

[jshslsky]

The data usage issue never came up when designing the prompt types. It's possible we had side conversations about it, but I think this is actually not a good reason to have limits. Any smartphone user is going to run into data usage caps regardless of whether they use ohmage or not.

[stevenolen]

i can't make a comment about if it came up when designing prompt types (I don't think I was around for that) but when we changed the <res> property to <maxDimension>, I'm sure we had a conversation about why we would want to keep it around.

Any smartphone user is going to run into data usage caps regardless of whether they use ohmage or not.

Totally fair, but having a simple way a study coordinator can GREATLY reduce the data upload burden (if they care about this) is quite useful, not just to limit monthly data usage, but to speed up uploads (slow uploads on mobile devices result in unexpected states for users) and reduce our server load as well as our server disk usage.

[jshslsky]

So far, no one has actually used the audio or video prompt types in real pilots.

That said, here is the latest plan info I have.

Vendor	Cost	Cap
Verizon	$70	4 GB cap
AT&T	$70	4 GB, can be increased with higher price
T-Mobile	$70	Unlimited data
Sprint	$80	Unlimited data

I bet VZ and ATT will soon drop the data caps in order to compete. For server disk space, we'll just have to deal with it once it comes up.

If someone actually wants to use a video prompt and they know they'll have users that have bad network coverage then one of our tasks is to have them set the "upload on wi-fi only" option.

[stevenolen]

OK. not to keep arguing, but I have some comments about the data caps above. First of all, this is data from the largest "unlimited" plan options for these carriers. Most of these carriers offer much lower cost data plans (for example, t-mobile offers data plans that are unlimited, but throttled after 200MB/month) which are becoming more and more popular.

But the real issue with listing these 4GB+ caps as sufficient is MVNO carriers. A massive amount of the smartphone user base these days comes from MVNO carriers which offer really weird plans at very affordable prices. Data caps ~200-250MB/month are quite common, and the users of these MVNO plans likely have the least knowledge of any of our user base, and thus would be very limiting. Lots of users like this might not even have Wi-Fi available to them..

[jshslsky]

I get it and thanks for continuing to push back. In the cases where we have users that we know are on limited or throttled plans, we'll have to educate the ohmlet creator about these issues.

[cketcham]

I think it is most important to have the ability to specify if uploads happen on the mobile network or only wifi. I'm not sure if we need to have the ability to resize media before uploading.

In google music, there is an option to stream high quality or normal quality when not on wifi but this is only for streaming, not for permanently storing music. In google music, youtube, and google+ photos, etc. you can't upload resized media. You only have the option to upload via mobile network or wifi only.

For the QS case I think it makes sense to only have an option to specify if uploads can happen on the mobile network. But for the clinical case I can see your point. It makes sense that the clinician either needs high quality uploads or not, so it would be good if they could be able to configure that setting.

[jshslsky]

The one clinical case I know of right now is the case where a patient has to take a photo of a blood sample container just after they draw blood. The only purpose of this photo is to provide a timestamp to the clinician because blood changes properties over time and knowing the time helps the clinicians perform smarter analysis.

[jshslsky]

@jojenki and I are discussing this and we think it is okay for the server to accept binary data of any size, and we will keep the restrictive properties to be used as hints for the mobile app.