Last week I went to San Jose for a week to attend CHI. Among other things I got to present my note Forget-me-not: History-less Mobile Messaging. This note received an Honorable Mention which is given to the top 5% papers and notes at the conference.

The paper is based on work done by a group of level 3 students. The group project was to design, build, and study a mobile text messaging app without history. This is what they did and turned into the app forget-me-not. The student project lasted a year, and throughout the project the students received first best presentation at the intermediate project presentations at half-time, and finally they received best L3 project in Computing Science in the school. I could not be prouder of these students. Topping that up with also being able to turn the work into a paper receiving an honorable mention surely is the cherry on the cake!

The final paper discuss mobile text messaging and the role of messaging history. To do that we study what happens with mobile text messaging when there is no history. By interviewing 10 participants after using the app for 2 weeks, we gain insights into how they perceive the app, and how they perceive messaging through it. We found that messaging requires effort, but allows users to be relaxed about what they write. History turns out to be useful in the ability to "scroll up" to see the past messages which allows for distractions. Not having history instead makes it more engaging. It is also discussed how not having history allows for sending messaging you don't want to have on record, such as bank details, or planning a secret birthday party. Read the whole paper, where we discuss the design of the app, and discuss the method of deliberately removing history to study history.

One of my summer interns, Ivaylo Lafchiev, is working on an interesting project over the summer, looking at the effect delays might have on mobile phone use. He has developed an Android app that introduces a delay when the phone is unlocked. The effect is that the user will have to wait for a short while (seconds) before the phone becomes available to them. The idea is to vary the duration of the delay to see if we can notice any effects on the overall usage of the device (for instance is the amount of time spent on the phone altered).

The app is now ready to be used in an experiment. The app is available on the app store, and the hope is that the app will attract a few users who will keep it installed for at least a few weeks. This is extremely risky. Why would anyone keep an app that makes it harder to use the phone? The hope here is that people do want to become more conscious about their phone use, and therefore are willing to participate in this experiment. The question however then is in what way the data will be biased by participants already wanting to change their phone use? We are trying to mitigate this bias (and investigating it) by first setting the delay to a short time, and after some time, we'll change the duration of the delay remotely to see if we can stop a difference in phone behaviour. By comparing the use before and after the delay change, and by changing the delay differently for different users, we hope to gather evidence as to whether this will have an effect or not.

I've made two personal observations from having the app installed myself. First, each time I unlock the phone, it serves as a reminder that I'm now about to use my phone. This might seem like a weird thing as the fact that I'm using the phone should be a reminder itself. However, I tend to use the phone when ever I have nothing else todo: waiting for the subway or waiting in line at Starbucks for instance. With the delay, I'm reminded, and then given a short time to contemplate whether I actually want to use the phone or if I should just take a few seconds to do nothing. The longer the duration, the more annoying the app is, but it also makes me more aware of my phone use. When the duration is long enough (more than 3 seconds or so) I start to think before using my phone, even before I take it out of the pocket. All of a sudden I'm reminded that I will have to wait a few seconds before the phone becomes available, and I choose often not to subject myself to it because the thing I was supposed to do with the phone was pointless anyway.

I'm looking forward to see what happens with this experiment. Is anyone going to download the app and install it? Is anyone going to keep it installed for long enough for us to collect data on their behaviour? Only time will tell. But until then, I will be more conscious and mindful of my phone use – until Ivaylo makes the duration so long that I will uninstall the app and go back to mindlessly fill every void of my life with mobile phone use.

You can find more information about the project, and download the app, here.

Last week I was awarded a Teaching Excellence Award from the college. The award was given for my teaching activities within the school , including: the development of a set of tutorials given to students and staff across levels, supervising undergraduate and postgraduate students, and contributions to undergraduate courses.

This morning I presented a paper at CHI entitled Pass The Ball: Enforced Turn-Taking in Activity Tracking. See the abstract below

We have developed a mobile application called Pass The Ball that enables users to track, reflect on, and discuss physical activity with others. We followed an iterative design process, trialling a first version of the app with 20 people and a second version with 31. The trials were conducted in the wild, on users’ own devices. The second version of the app enforced a turn-taking system that meant only one member of a group of users could track their activity at any one time. This constrained tracking at the individual level, but more successfully led users to communicate and interact with each other. We discuss the second trial with reference to two concepts: socialrelatedness and individual-competence. We discuss six key lessons from the trial, and identify two high-level design implications: attend to “practices” of tracking; and look within and beyond “collaboration” and “competition” in the design of activity trackers.  

I've been struggling recently with transcoding media files and streaming to Chromecast. Starting with the excellent project castnow over on github I wanted to be able to 1) stream media files directly from rar archives, and 2) create a web interface to start media files. It is not meant to be overly ambitious but just something useful to use at home.

Among several problems I've encountered so far, one has been especially annoying and turned out to have a very simple fix. The transcoding is done using ffmpeg. What I've been doing is to let ffmpeg reencode any media file I give it, into an mp4 with h264 and aac. This works most of the time, however for some mkv-s there's been no image when transcoded. Casting the mkv directly to the chromecast gives you moving pictures, but it has no sound (since Chromecast does not support 5.1 audio as of yet as far as I understand).

The first attempt at a solution was to then not reencode the video but to simply copy the original. That is simple using ffmpeg flag: -vcodec copy. Unfortunately this still doesn't work. However encoding the video to a file and then casting the file to the chromecast works. Thus there was something going on when the output from ffmpeg is streamed directly. I've still not worked out what is going on, but I've found a solution. Instead of creating a mp4 container, encoding everything into a mkv (or matroska) suddenly makes everything work just fine. The final line is

[code]

cat some-media-file | ffmpeg -i - -f matroska -vcodec h264 -acodec aac -ac2 pipe:1 | stream-to-chromecast

[/code]

So far this seems to work all the time, however it is somewhat unnecessary to encode h264 if the video is already h264. In my project I therefor check codecs and set the flags for ffmpeg accordingly.

The project is written in Node.JS and is available on the following github repository.