Today I presented our paper 'Personal Tracking as Lived Informatics' at CHI. By interviewing 22 people about how they were using personal tracking devices, such as Nike Fuelband, Jawbone Up, FitBit, and mobile apps (e.g. RunKeeper and MyFitnessPal).

Among the findings, we uncover how the people we talk to use multiple trackers, and track multiple things. They switch between trackers, as well as what they track, over time. While they say that they do not share tracked data to social networks, they do track together with people in their lives. Furthermore, while they track for a long time, they rarely look at their historical data.

We discuss our findings and present an alternative view to Personal Informatics which we term Lived Informatics. Lived Informatics emphasises the emotionality of tracking and that tracking is something done with an outlook for the future, rather than part of a rational scientific process for optimising self as seen in Quantified Self and in Personal Informatics.

We are very happy the paper got an Honorable Mention.

The paper:

Rooksby, J., Rost, M., Morrison, A. and Chalmers, M. (2014) Personal Tracking as Lived Informatics. To appear in Proceedings of CHI’14, Toronto, Canada.

On friday I gave a guest lecture in a course at LinCS at the University of Gothenburg. The course was 'Understanding and designing for social media practices' and is aimed at exploring methods for studying online social media.

The lecture was based on two previous studies of foursquare. The first one was a primarily interview based study where we looked at performative aspects of using foursquare. The second one deals with a study of log data from foursquare. The talk discussed what it means for people to share their location through the means of checking in (or what it means to check in), and discussed what this means for the genera of data, and showed examples of communicative features in the log data from foursquare.

The slides can be found on slideshare.

Encountered such a stupid thing that I do not wish anyone else ever to encounter so I feel I have to write a post about it. Tl;dr: BitmapFactory.decodeResource may rescale the image to match the pixel density of the device, which is not good if you are concerned about the pixel size of the image.

I recently had a problem with textures in OpenGL ES 2.0 on Android. Everything worked like a charm on the development device I was using, and everyone was happy. But when I found a less common device in the office, I decided to try it on that device to see the performance. I did not expect it not to work, but was prepared that might be some performance issues. Little did I expect that nothing would show on the screen. Also, no proper error messages were shown anything. Just black screen.

When loading textures in OpenGL on android, people generally use something like

[code]
Bitmap bitmap = BitmapFactory.decodeResource(context.getResources(),R.drawable.cool_texture);
GLUtils.texImage2D(GLES20.GL_TEXTURE_2D, 0, bitmap, 0);
[/code]

Its doubtful that anything would go wrong with these two lines, so I went to check the most obvious things I could think of. First off I checked if the device required power of two sized textures (256x256, 512x512, etc). I created a texture that was 256x256 and loaded it. Did not work. So I went ahead and tried all kinds of things, stripped down the code to bare minimum to isolate where the problem was.

To cut things short. The problem was with the two lines, and the way BitmapFactory.decodeResources decodes resources... The bitmap I obtained ended up not being the dimensions of the image I created, but something slightly less. The fix:

[code]
final BitmapFactory.Options options = new BitmapFactory.Options();
options.inScaled = false;
Bitmap bitmap =
BitmapFactory.decodeResource(context.getResources(),R.drawable.cool_texture, options);
[/code]

Once this was added, I learned the problem indeed was with power of two sized textures, and could take care of it.

Ps. if you want to check the platform supports non-power of two sized textures, you can run this check:

[code]
String extensions = gl.glGetString(GL10.GL_EXTENSIONS);
mSupportsNPOT = extensions.indexOf("GL_OES_texture_npot") != -1;
[/code]

Potentially not the nicest way of doing it, but it works. Ds.

I believe coding should be seen as a craft, and as such there has to be as little between your creativity and executing on the creativity as possible. One such obstacle when it comes to most development of web applications, is the need to create a database structure. For years now I have been using different iterations of my own set of help functions in PHP. It started with some getters for fetching an array of rows from a MySQL query in one go, and later it evolved into what I called ProtoDB, which is available on GitHub. The core point of ProtoDB is that it creates the database structure as you code it. Setting some value for a column in a table will create that column if it does not exist, and will create the table if the table does not exists. This allows you to stay in the code editor and still work with a database. (Optimizing can always be done later.)

However, sometimes it can be nice to use a simple ORM, in order to group model functions together in an object oriented way. Most ORMs however (that I have seen), still require the database structure to be in place. The tables need to exist, and have the columns needed for the ORM to map to this structure. I have therefore started to expand on ProtoDB to create a basic ORM on top of it, which gives you the flexibility of ProtoDB and the benefits of an object oriented architecture of an ORM.

For now there is only one class Model that is the base of everything else.

[php]
namespace ProtoORM;
use \DB;

class Model {
public static function create($row); // row is an associated array of values for columns given by the keys
public static function find($id); // gets the model object with the given id
public static function all(); // gives you an array of all objects in the table
public function save(); // updates the table or inserts a new row
}
[/php]

From this it is easy to create a new model, for instance a User:

[php]
class User extends ProtoORM\Model {
protected $table = "users"; // sets the table name
}

// create a new user
$user = User::create("name"=>Mattias);
$user->save();

// later we can set some more info
$user->age = 31;
$user->role = 'dev';
$user->save();

$user = User::find($user_id);

[/php]

The points of this is that the table 'users' does not need to exist before running this code. Everything will be added to the database structure as need. This is obviously only the beginning, and I aim to expand on it as I keep using it in some of my current projects.

I am also thinking about also implementing some kind of automation of migration files, in order for groups of people to work together in early stages of design.

If you're a PhD student working with things such as ubiquitous and mobile computing, statistics and inference, and formal modelling and analysis, the project I'm working in is offering internships! It's preferably over the summer, but not restricted to it.

The Populations project is trying to advancing the design process and underlying science of mobile applications. We do this by designing, building and studying mobile apps through large deployments, and investigate new methods and analysis tools that allow us to advance this area of research and practice. If you're interested in reading more you should check out the call.