Make offline episode content loading possible

[superdweebie]

This feature will greatly reduce the amount of data used by the app.

When selecting an episode the user should get a choice to either load the episode from the web or their file system.

To do this we will have to bring back the BSO file format that rolls the audio and question data into a single file. This will also drop support for firefox. At present we support firefox by providing ogg audio format as well as mp3. If we move to BSO files with a single audio format, mp3 will win and ogg will lose.

[superdweebie]

Regarding firefox mp3 support, I've found this lib that does mp3 decoding with pure js (https://github.com/audiocogs/mp3.js). It could be conditionally loaded just for ff to maintain full cross browser support. Is it worth adding this complexity, or should we just notify ff users to to use a different browser?

[superdweebie]

Another thought with local file loading. I think we should probably calculate the sha1 hash of the locally loaded file and compare it to a hash sent from the server. Then we can reject any local file that may have been tampered with. This is the most compact implementation of sha1 in js that I could find: https://github.com/kvz/phpjs/blob/master/functions/strings/sha1.js

[90084]

Excellent, yes please. Is it feasible to have some basic way of blocking the playing of the audio file outside the web sequence?

On 01/09/2015, at 8:26 PM, Tim Roediger notifications@github.com wrote:

Another thought with local file loading. I think we should probably calculate the sha1 hash of the locally loaded file and compare it to a hash sent from the server. Then we can reject any local file that may have been tampered with. This is the most compact implementation of sha1 in js that I could find: https://github.com/kvz/phpjs/blob/master/functions/strings/sha1.js

— Reply to this email directly or view it on GitHub.

[90084]

Great to have the option. At this stage of the project, let's leave it on the shelf. I expect most would have Android, and thus most would be on Android. But now we have GA support, we can monitor client specs and up the priority of this one as needed.

On 01/09/2015, at 7:47 PM, Tim Roediger notifications@github.com wrote:

Regarding firefox mp3 support, I've found this lib that does mp3 decoding with pure js (https://github.com/audiocogs/mp3.js). It could be conditionally loaded just for ff to maintain full cross browser support. Is it worth adding this complexity, or should we just notify ff users to to use a different browser?

— Reply to this email directly or view it on GitHub.

[superdweebie]

So for local file loading we will definitely use a sha1 hash.

Regarding blocking playing of the audio file outside the web sequence, I'm going to email you so my response isn't recorded here forever.

[90084]

and thus most would be on Android I meant and thus most would be on Chrome...

[superdweebie]

Here's the first mockup for a modified UI. It adds a new screen between the episode summary the first slide.

[90084]

Great, thanks. This would show we're serious about helping people with expensive data (a common 'blocker' I get). Some questions to think about: I assume that the 'consumption selection' would only appear if no content is already present? Also, (this might relate to 'content protection'), just bringing up the issue of 'inter-episode flow control'. Ideally, we want the audience to complete all the questions in one episode before they move to the next. How might we allow for the audio drama to be listened outside the mobile (e.g. radio broadcast or church PA system, guy with a big loud ghetto blaster on a bike), at least partly? I've suggested the idea of a radio/mobile hybrid, where they listen acts 1-2 on the radio, then they can complete the questions on the mobile to get access to act 3 download (or they can just wait for the next broadcast). I'm not asking we build a solution for all these options now. :-) I'm bringing them up so we keep mulling over them, and especially so we don't make irreversible decisions that shut us out of opportunities...

On 04/09/2015, at 9:25 PM, Tim Roediger notifications@github.com wrote:

Here's the first mockup for a modified UI. It adds a new screen between the episode summary the first slide.

— Reply to this email directly or view it on GitHub.

[superdweebie]

As you know, at present we don't have any 'inter-episode flow control'. It seems to me that we would need a user authentication system first, which I don't think we are ready to tackle yet.

Regarding listening to parts of an episode from an alternate source, I think that wouldn't be hard to work into the web flow. We could simply allow users to skip a section of audio if they say they have already listened to it. Something I do think would be helpful if we go down that path is labeling 'Act 1', 'Act 2', 'Act 3' in both a radio broadcast and the web flow so that users know which bit is which.

Regarding when the 'consumption selection' would appear, you have prompted me to think about it more. I think the logic could go something like this:

A. First check to see if the episode is in browser local storage (IndexedDB). If so then offer these two selections on the 'consumption screen':

• Save to share with download size 0mb, file size 7.4mb.
• Listen to episode with download size 0mb.

B. If the episode is not in browser local storage, then offer the three options in the mock up above:

• Download to save and share with download size 7.4mb, file size 7.4mb.
• load from a file and listen
• listen from the web with download size 7.4mb.

C. If the episode is loaded from a file or listened to from the web, then add the episode to browser local storage ready for next time.

[superdweebie]

Direction has changed on this slightly. Still need offline episode loading, but the questions shouldn't be bundled in the file, and we don't want to use an encryption. Instead use plain mp3 audio format so the episode can be shared freely outside the app.