Nth Screen, Nth Camera: on groups and sessions
Many research issues have been occupying us in the Nth Camera project. One is how to support our users in groups.
We’ve known since starting Nth Screen last year that groups are necessary: if you and I would like to watch an N movie together (a collection of videos played synchronously), then we need to be in a group to distinguish ourselves from everyone else watching or recording an N movie at the same time (whether its the same one or a different one).
We also know from our Nth Camera workshops and from It’s the Skin You’re Living In that getting into a group can be fun as long as it’s not too onerous. It’s fun because it lets us play with social identity. E.g. choosing a name for our group together to reflect our common interests or other social capital. C.f. the culture of Bluetooth naming.
But groups are a little bit more complicated than they first seem.
For users of our app do things together, but not everything together. E.g. Alpha, Beta, Gamma and Delta shoot an N movie together. They’re all filming, all doing the same thing. Then they review the film together: the videos play in time on their mobiles. Alpha and Delta then decide to shoot another film. They go into Capture mode. Beta and Gamma meanwhile are still in Review mode. Gamma is suddenly reminded of an N movie that she saw last month. She finds it in the app and plays it. Beta joins in.
We think of these activities as sessions within groups. We believe it would be a good idea to support sessions seamlessly. It would be a bit of a pain if these four had to split into different groups every time they changed what they were doing, i.e. go back to the group-formation interface in the app. We found in our workshops that it’s also confusing for users if the app changes groups for them implicitly and tells them they are in a different group just because they changed what they were doing.
So we implicitly form subgroups out of (group, activity) pairs. The app knows your activity from what you are doing with it: shooting a new N movie, reviewing one you’ve shot, or watching an N movie that’s already been uploaded and shared. The app can automatically put you into these subgroups. Without changing what you think of as your group.
So that’s what we’re doing. We keep the group you’ve formed and inform you about what is happening in your group. You can join what others are doing in the group from a list of all the activities. When you’re in an activity, you can see (for example) that you are “one of 3 in <your group name> watching <the film you’re watching>”.
You can always decide to create or join a completely different group.
We’re using/considering three different group formation mechanisms
- Pick a name. This mechanism already exists in our prototypes and in It’s the Skin You’re Living In. It works well for many situations. But it doesn’t guarantee exclusivity: just because three people in Willesden are using the name ‘freddy’, it doesn’t mean that someone in Bavaria isn’t doing the same. This type of ‘spillage’ between groups can be entertaining or it can be annoying… Of course, you can always add to your group name to exclude others.
- Click on a link. Ask the app to create a unique group. This is presented as a type of link. Share it via your favourite means (Facebook, WiFi Direct, maybe Twitter). When others click on it, they join your group. This has the advantage that it’s orthogonal to the sharing mechanism, and you can form groups with strangers.
- Invite. This is a special case of (2), one where you care about exactly who is going to be in your group. Log in on a social network. Create a group. Invite others to join it via the network.
Group implementations tend to differ in how ‘heavyweight’ they are: the resources required at the server and in the app to manage the group, and the computational/bandwidth/other costs of joining, leaving and communicating within the groups.
We’re experimenting with a relatively lightweight notion of subgroup for activities (aka sessions), alongside the relatively expensive notion of group that we need for the groups of users.
The advantages of this are that we consume fewer server resources and involve the app in fewer (heavyweight) group membership changes. The cons are that, unless we add to the complexity and implementation overhead in the server, the app may receive messages for subgroups it doesn’t belong to, and that scalability is affected.
Scalability is an important implementation issue for us. Subgroups need to be implemented along with groups, so we cannot divide the work of managing them between servers. This is neither here nor there for a group of four as in our example above. But what if Twitter users form a group of 10000? Or 1000000? We may have to restrict groups of more than a certain size to no more than one activity at a time.
Watching N movies
This case is quite different from Shooting or reviewing an N movie. For, when you watch an N movie, the video you see is in general a function of your rank in the group.
But supposing only two of four are watching the N movie?
It’s possible to project the rank onto the subgroup, e.g. ranks 2 and 4 become 1 and 2. This seems at first sight a reasonable fit with what the users will think of as their rank, although it raises implementation issues.
We’re still thinking about this issue. An important principle is: users (including the filmmakers) should be able to understand the choice of video for each user. Included in that is: don’t change the user’s rank too often, or in a way that the user doesn’t understand.
There are no conclusions yet. We’re experimenting with how to present group functionality to users, and how to implement that functionality. All we know so far is that using nothing but groups (no implicit subgroups) was confusing for users and heavy on the implementation. We’re hoping implicit subgroups will provide a way forward.