90084
commented
8 years ago Thanks Tim. As discussed, let's simmer this one in our brains for a bit. Just making a note of the other idea we floated, a cookie based solution, with a 'completion cookie' dropped at the last page of each episode, informing which episodes are available on the first menu. Cons noted: would not work across browsers and/or devices, a shared device wouldn't allow for different progress points of different users, info lost if cache is cleared.
On 09/09/2015, at 10:18 PM, Tim Roediger notifications@github.com wrote:
Ok. This is a big one. There are three issues here all very much intertwined. Our direction on these issues relate not just to the code, but the whole BSO project in general. I'd suggest that solid direction on these will require a significant amount of thought, and will possibly be best resolved with a face to face workshop, perhaps with all three of us (Tim, Marty, and Joe).
So here is an outline of the three points as I see them at the moment and how they fit together.
Inter-episode flow
This has been identified by Marty. We want to be able to control a user's progress through the BSO material. They should not be able to consume episodeds out of order. They may be required to show comprehension of one episode before moving on to another. There may be time controls on episodes, such as no more than one per week. There may be payment for episodes. etc.
In app speak, this is basically an authorisation issue. An episode is the resource that users want. Inter-episode flow logic should define a set of rules for who and when episodes can be accessed. Authorisation per-supposes the app knows who the user is, thus we need a user authentication system...
User authentication
We need to identify who is consuming the episode so they can have their progress recorded and be given the proper authroisations. I think we must go with a ratio of 1 user to 1 account. I don't think group accounts are a good idea. (Individual user progress also becomes the basis of issuing certificate of educational achievement). Whatever method we use for user authentication it needs to be low-friction. That is, we need to be able to authenticate users quickly and simply.
Here are a few technology options that come to mind:
Classic username and password login. This is very standard. Users expect it. It can be a pain as a user when you can't remember your password. Login using google or facebook accounts. This is also a standard method. It is simple and quick if users already have one of those accounts. It's really annoying if they don't (would need username/password fallback). Partial login using photo and face recognition. This is a bit novel, but I think it could be very useful in small group settings (2-10 people). Ie, one person has their device, they login with one of the two methods above. They tell the app they are in a group meeting, and take a photo of the group. The app can then via face recognition take a roll-call of the group and log progress against each individual user account. Heterogeneous content delivery methods
By this I mean that we hope to support delivery of episodes by multiple methods. We need to make our user authentication as flexible as possible so we can support and track as many individual users as possible despite the different delivery methods. Possible examples:
Single user, single device, solo personal learning. This is the easiest to support. It is how web apps are normally designed.
Small group (2-10), single device. Group learning. Possibly not too hard to track individuals. Each would person would need to go through some kind of account creation process, and could then possibly be tracked via group photos (see note above).
Large group (11-300?). Pa system and projector/TV driven from single device. This one is difficult. Not sure how to do it well.
Deliver partial episodes via radio, with the conclusion available via web. Likely to be close to the single user, single device scenario. Users could acknowledge/prove they have heard some of the content already.
So, what is the way forward? I actually think we need to nail the three issues down in reverse order. If we decide what delivery methods we want to support, then we understand what kind of authentication we need to build. Once we have authentication, then the inter-episode logic is almost trivial ;) .
— Reply to this email directly or view it on GitHub.
Ok. This is a big one. There are three issues here all very much intertwined. Our direction on these issues relate not just to the code, but the whole BSO project in general. I'd suggest that solid direction on these will require a significant amount of thought, and will possibly be best resolved with a face to face workshop, perhaps with all three of us (Tim, Marty, and Joe).
So here is an outline of the three points as I see them at the moment and how they fit together.
Inter-episode flow
This has been identified by Marty. We want to be able to control a user's progress through the BSO material. They should not be able to consume episodeds out of order. They may be required to show comprehension of one episode before moving on to another. There may be time controls on episodes, such as no more than one per week. There may be payment for episodes. etc.
In app speak, this is basically an authorisation issue. An episode is the resource that users want. Inter-episode flow logic should define a set of rules for who and when episodes can be accessed. Authorisation per-supposes the app knows who the user is, thus we need a user authentication system...
User authentication
We need to identify who is consuming the episode so they can have their progress recorded and be given the proper authroisations. I think we must go with a ratio of 1 user to 1 account. I don't think group accounts are a good idea. (Individual user progress also becomes the basis of issuing certificate of educational achievement). Whatever method we use for user authentication it needs to be low-friction. That is, we need to be able to authenticate users quickly and simply.
Here are a few technology options that come to mind:
Heterogeneous content delivery methods
By this I mean that we hope to support delivery of episodes by multiple methods. We need to make our user authentication as flexible as possible so we can support and track as many individual users as possible despite the different delivery methods. Possible examples:
So, what is the way forward? I actually think we need to nail the three issues down in reverse order. If we decide what delivery methods we want to support, then we understand what kind of authentication we need to build. Once we have authentication, then the inter-episode logic is almost trivial ;) .