Cricket Tales: Brainstorming the Workflow
Following a meeting with the Wild Crickets team at the University of Exeter, Amber and I spent some time brainstorming a workflow for the Cricket Tales game, and considering how to integrate it with the existing system.
We had discussed a training interface for all new users – registered or guests. We would like all visitors to engage with the game wether registered or not, however the ‘game’ aspect can only progress for the user when they become a member of the site and can adopt burrows. This way we will gathering a large quantity of data from one-time users, returning users and registered members alike, with perhaps more quality from the registered members. A step we can take to ensure that users understand what they are looking for is by providing some training videos, using footage of crickets fighting, mating, singing, etc. Watching these videos may not be mandatory, but will be useful – when a guest enters the site from the front page, the training videos will appear, but can be skipped. When a user is registered, this step will not be visible, but accessible from the landing page. According to the life cycle of a cricket, the user will be achieve an ‘egg’, ‘nymph’.. etc badge depending on how many videos have been watched.
ID + Movement
An incentive of the research project is to understand the movements of crickets, wether they move more/less in older age. Each cricket, therefore, should be ID’ed – within the footage, the cricket ID’s can be clearly seen as a badge, tracking these is essential. We had discussed entering the cricket ID using a keyboard, clicking on the cricket at the beginning of the video to prompt ID entry and record the starting location, also clicking on the cricket’s location at the end of the video and measuring the distance moved. However, this is problematic – firstly, if this game were to be played on a tablet or touchscreen, a keyboard may be obtrusive. Secondly, the cricket may not be visible at the start of the video or the end, or the ID may not be visible either. Also, the judging the movement of a cricket by it’s ‘start’ and ‘end’ points will be inaccurate, as crickets probably don’t move in a linear fashion the whole time. For now, we will instead focus on ID’ing the cricket using an on-screen touchpad of sorts at any point during the footage, and calculate movement via entering and leaving burrow using the data from the surrounding footage clips.
When something in the footage is alarming, different, questionable or notable, it would be useful for the user to be able to contact the researchers directly outside of the game structure. However, easy access to this could lead to large amounts of accidental submissions and such, meaning that the quality of miscellaneous data will decrease. To address this, I’m thinking of generating a ‘code’ including the video number and timestamp, and prompting the user to email the researchers (an inbox specifically for this) including the ‘code’ as the subject. This is created when the user presses the ‘Something Weird’ (TBC) button, pausing the video. This extra step will hopefully prevent accidental submissions or unwanted messages, however removing the user from the game to email may be bad. Will see how that goes.
Sometimes, there will be no events in the footage. If no events have been recorded, an alert will be triggered at the end of the video asking the user to confirm that nothing had happened with the option to watch again. If nothing has happened, the user could then be redirected to a video with lots of events (watched before, interesting) – this way, the user will gain satisfaction from watching a video with many events, and their events can be checked against others on our end. Alternatively, they could be redirected to a video that has not been watched before – the feeling of watching something that has not been viewed before, anticipation of finding something new.
The user may not understand what a predator is, or the types of predators the researchers will be looking for. Also, a simple ‘predator’ button may be too generic in terms of data collection, so we agreed to buttons for ‘types’ of predators, such as birds etc. This will be displayed in the main interface of the videos, but how it will be integrated effectively, I am not 100% sure on just yet.
I’m personally super excited about this aspect, after working with maps for various projects over the past year. Here, we would illustrate the burrows as a community. Users can adopt burrows by watching their videos and providing the most data on that particular burrow – users will also be able to draw their own flag, which will be displayed by the burrow. This map will be viewable from the ‘landing’ page of the website, and clusters of burrows will form as the relationships between the crickets become more apparent. It’s important for the user to build an interest in and affinity towards the crickets and burrows, so developing a ‘story’ of the burrows will be a nice touch, interactions can be displayed on the landing page ‘feed’ (not like a social network but not completely unlike it either..). It will be interesting to see the findings build up this way. Back to maps – it is entirely possible to create fictional maps using mapping libraries (such as MapBox) with the full API for placing markers, calculating distances etc. Some inspiration for this…
… Is this game created in MapBox, showing just how this is possible.
We also discussed the general design and feel of the website. Although we aren’t entirely clued up on the specific demographic just yet, we have some ideas of its application (arcade cabinets, a film), so it will be good to build up an identity this way. So far we are interested in illustration, collage and natural materials, so we can see how this will develop.