Getting fit, bit by bit

I’ve been making decent progress on my software, and while it’s no good yet for any kind of data analysis, it can already be used to do a number of things related to the management of datasets and collaborations. I may even unleash the current incarnation upon some unsuspecting human beings soon, but for now, I’m using myself as my first guinea pig, so I’ve started wearing one of the Fitbits I bought myself (or rather, for my project) for Christmas. From the perspective of my research, the reason for this is that I need to capture some sample data so I can get a look at what the data looks like when it’s exported from the Fitbit cloud into a file, but I’m also personally interested in seeing firsthand what’s happened in fitness trackers since the last time I wore one, which was quite a few years ago and then also for research purposes.

Back then I wasn’t hugely impressed, but it seems that by now these gadgets have advanced enough in terms of both functionality and appearance that I would consider buying one of my own. My initial impression of the Fitbit was that it’s quite sleek but not very comfortable; no matter how I wore it, it always felt either too loose or too tight. However, it seems that I either found the sweet spot or simply grew accustomed to it because it doesn’t bother me that much anymore, although most of the time I am still aware that it’s there. I’m probably not wearing it exactly as recommended by the user manual, but I can’t be bothered to be finicky about it.

By tapping on the screen of the device I can scroll through my basic stats: steps, heart rate, distance, energy expenditure and active minutes. More information is available by launching the Fitbit app; this is where I see, for example, how much sleep the device thinks I’ve had. Here I could also log my weight and what I’ve eaten if I were so inclined. Setting up the device and the app so that they can talk to each other takes a bit of time, but after that the device syncs to the app without any problems, at least on Windows. However, for some reason the app refused to acknowledge that I’m wearing the Fitbit on my right wrist rather than my left; this setting I had to make on the website to make it stick. The website is also where I export my data, which is quick and straightforward to do, with a choice between CSV or Excel for the data format.

The accuracy of the data is not really my number one concern, since I’m interested in the process of collaborative data analysis rather than the results of the analysis. However, on a personal note again, it is interesting to make observations on how the feedback I get from the device and the app relates to how I experience those aspects of my life that the feedback is about. For example, I can’t quite escape the impression that the Fitbit is flattering me, considering how consistently I’ve been getting my daily hour or more of activity even though in my own opinion I certainly don’t exercise every day. On the other hand, I do get a fair bit of walking done on a normal working day, including a brisk afternoon walk in the park next to the university campus whenever I can spare the time, so I guess it all adds up to something over the course of the day.

Based on my fairly brief experience, I can already see a few reasons for the rising popularity of wearables such as the Fitbit. Even if the accuracy of the data in terms of absolute values leaves something to hope for, presumably the device is at least reasonably consistent with itself over time, so if there are any rising or falling trends in your performance, they should be visible in the data. To make the product more friendly and fun to use, the developers have used a host of persuasion and gamification techniques; for example, there are various badges to be earned, with quirky names like “Penguin March”, and occasionally the device gets chatty with me, offering suggestions such as “take me for a walk?”. When I reach the daily magic number of ten thousand steps, the Fitbit vibrates a little silent congratulatory fanfare on my wrist.

In terms of what I need to carry out my project, the Fitbit will definitely serve: setting it up, syncing it and exporting the data all seem to work without any big hassle. As for whether I’m going to get one for myself, I would say that it’s now more likely than before that I will get some kind of wearable – not necessarily a Fitbit, but one that will give me the same kind of information anyway. Having this opportunity to try out a few different ones is an unexpected perk of the project that I now suddenly welcome, even though I wasn’t particularly interested in these devices when I was applying for the grant.

Philosophical ruminations vol. 1

Holidays are over and I’m back from the Finnish winter wonderland in Ireland, who seems to retain an appreciable fraction of her famous forty shades of green even in the middle of winter. No sign of the pre-Christmas frenzy anymore – I’ve been working at a fairly leisurely pace for these past few weeks, enjoying the luxury of being able to take the time to have a good think about what I’m doing before I actually do it. The only deadline of immediate concern was the extended deadline of the conference for which I was preparing a paper before the holidays, and since I didn’t dare rely on there being an extension, I all but finished the manuscript during the break, so there wasn’t much left for me to do to it after I got back on the clock.

Since things are not so hectic now, I thought this would be a good time for a post discussing a topic that’s not directly concerned with what’s going on in my project at the moment. When I started the blog, my intention was that one of the themes I would cover would be the philosophical dimension of knowledge discovery, and there’s a certain concept related to this that’s been on my mind quite a lot lately. The concept is known as epistemic opacity; that’s epistemic as in epistemology – the philosophical study of knowledge – and opacity as in, well, the state of not being transparent (thanks, Captain Obvious).

I ran into this concept in a paper by Paul Humphreys titled “The philosophical novelty of computer simulation methods”, published in the philosophy journal Synthese in 2009. Humphreys puts forward the argument that there are certain aspects of computer simulations and computational science that make them philosophically novel as methods of scientific enquiry, and one of these aspects is their epistemic opacity, which he defines as follows:

[…] a process is epistemically opaque relative to a cognitive agent X at time t just in case X does not know at t all of the epistemically relevant elements of the process. A process is essentially epistemically opaque to X if and only if it is impossible, given the nature of X, for X to know all of the epistemically relevant elements of the process.

That’s a bit of a mouthful, but the gist of it – as far as I understand it – is that computer simulations are opaque in the sense that there is no way for a human observer to fully understand why a given simulation behaves the way it does. This makes it impossible to verify the outcome of the simulation using means that are independent of the simulation itself; a parallel may be drawn here with mathematics, where there has been criticism of computer-generated proofs that are considered non-surveyable, meaning that they cannot be verified by a human mathematician without computational assistance.

The philosophical challenge here arises from the fact that since we have no means to double-check what the computer is telling us, we are effectively outsourcing some of our thinking to the computer. To be fair, we have been doing this for quite some time now and it seems to have worked out all right for us, but in the history of science this is a relatively new development, so I think the epistemologists can be excused for still having some suspicions. I doubt that anyone is suggesting we should go back to relying entirely on our brains (it’s not like those are infallible either), but I find that in any activity, it’s sometimes instructive to take a step back and question the things you’re taking for granted.

The algorithms used in knowledge discovery from data can also be said to be epistemically opaque, in the sense that while they quite often yield a model that works, it’s a whole different matter to understand why it works and why it makes the mistakes that it does. And they do make mistakes, even the best of them; there’s no such thing as a model that’s 100% accurate 100% of the time, unless the problem it’s supposed to solve is a very trivial one. Of course, in many cases such accuracy is not necessary for a model to be useful in practice, but there is something about this that the epistemologist in me finds unsatisfying – it feels like we’re giving up on the endeavour to figure out the underlying causal relationships in the real world and substituting the more pedestrian goal of being able to guess a reasonably accurate answer with adequate frequency, based on what is statistically likely to be correct given loads and loads of past examples.

From a more practical point of view, the opacity of KDD algorithms and the uncertainty concerning the accuracy of their outputs may or may not be a problem, since some users are in a better position to deal with these issues than others. Traditionally, KDD has been a tool for experts who are well aware of its limitations and potential pitfalls, but it is now increasingly being packaged together with miniaturised sensors and other electronics to make a variety of consumer products, such as the wearable wellness devices I’m working with. The users of these products are seldom knowledge discovery experts, and even for those who are, there is little information available to help them judge whether or not to trust what the device is telling them. The net effect is to make the underlying algorithms even more opaque than they would normally be.

Now, I presume that by and large, people are aware that these gadgets are not magic and that a certain degree of skepticism concerning their outputs is therefore warranted, but it would be helpful if we could get some kind of indication of when it would be particularly good to be skeptical. I suspect that often it’s the case that this information exists, but we don’t get to see it basically because it would clutter the display with things that are not strictly necessary. Moreover, this information is lost forever when the outputs are exported, which may be an issue if they are to be used, for instance, as research data, in which case it would be rather important to know how reliable they are. I’d be quite interested in seeing a product that successfully combines access to this sort of information with the usability virtues of today’s user-friendly wearables.

Dear Santa

Now that I’ve managed to clear away all of the stressful and/or boring stuff that was keeping me busy, time to do something fun: Christmas shopping! After the break my project is going to be almost halfway through, and although it will be a good while yet before I’m ready to start conducting user tests, it’s time to start getting serious about recruiting participants. After all, the tests are supposed to be about analysing the participants’ data, so they can’t just walk in at their convenience – I need them to spend some time collecting data first, and to do that, they’ll need something to collect the data with.

Our initial idea was to recruit people who are already using a sleep monitor of some kind, and I’m sure we’ll be able to find at least a few of those, but naturally we’ll have a bigger pool of candidates if we have a few devices available to loan to people who don’t have one of their own. Also, it’s obviously useful for me to play with these devices a bit so I can get a better idea of what sort of data they generate and what’s the best way to export it if I want to use it for my research (which I do). Besides, I’m hardly going to spend my entire expense budget on travel even if I go out of my way to pick the most remote conferences I can find to submit papers to.

So I didn’t need to worry too much about what I can afford – one of the many great things about the MSCA fellowship – but that doesn’t mean that the choice of what to buy was straightforward, because the range of consumer products capable of tracking sleep is, frankly, a little bewildering. Some devices you wear on your body, some you place in your bed and some at the bedside, and although I soon decided to narrow down my list of options by focusing on wearables, that still left me with more than enough variety to cope with. Some of these gadgets you wear on your wrist, while others go on your finger like a ring, and the wrist-worn ones range from basic fitness bracelets to high-end smartwatches that will probably make you your protein smoothie and launder your sports gear for you if you know how to use them.

One thing that made the decision quite a lot easier for me is that the manufacturers of fitness bracelets now helpfully include all of their sleep tracking functionality in models that are near the low end of the price spectrum, and since I’m only interested in sleep data, there was no need to ponder if I should go with the inexpensive ones or invest in bigger guns. Also, I had a preference for products that don’t make you jump through hoops if you want to export your data in a CSV file or similar, so I looked at the documentation for each of my candidates and if I couldn’t find a straight answer on how to do that, I moved on. In the end I settled on three different ones: the Fitbit Alta HR, the Withings Steel, and the Oura Ring.

What I particularly like about this trio is that each of these models represents a distinct style of design: the Fitbit is a modern bracelet-style gadget, whereas the Withings looks more like a classic analog wrist watch, and the Oura is, well, a ring. I can thus, to a certain extent, cater for my study participants’ individual stylistic preferences. For example, I’m rather partial toward analog watches myself, so I’d imagine that for someone like me the design of the Withings would have a lot of appeal.

Today’s my last day at work before the Christmas break, and things are wrapping up (no pun intended) very nicely. The orders for the sleep trackers went out last week, this morning I submitted the last of my (rather badly overdue) ethics deliverables to the European Commission, and just minutes ago I came back from my last performance with the DCU Campus Choir for this year. The only thing that may impinge on my rest and relaxation over the next couple of weeks is that there’s a conference deadline coming up immediately after my vacation and I’m quite eager to submit, but I shouldn’t need to worry about that until after New Year. Happy holidays, everyone!

Sleepytime

I recently obtained approval for my research from the DCU Research Ethics Committee, so I’m now officially good to go. This might seem like a rather late time to be getting the go-ahead, considering that I’ve been doing the research since February, but so far the work has been all about laying the foundations of the collaborative knowledge discovery software platform (for which I’m going to have to come up with a catchy name one of these days). This part of the project doesn’t involve any human participants or real-world personal data, so I’ve been able to proceed with it without having to concern myself with ethical issues.

As a matter of fact, if it were entirely up to me, the ethics application could have waited until even later, since it will be quite a while still before the platform is ready to be exposed to contact with reality. However, the Marie Curie fellowship came with T&Cs that call for ethics matters to be sorted out within a certain time frame, so that’s what I’ve had to roll with. I’d never actually had to put together an application like this before, so perhaps it was about time, and presumably it won’t hurt that some important decisions concerning what’s going to happen during the remainder of the project have now been made.

One of the big decisions I’d been putting off, but couldn’t anymore, was the nature of the scenario that I will use to demonstrate that the software platform is actually useful for the purpose for which it’s intended. This will be pretty much the last thing that happens in the project, and before that the software will have been tested in various other ways using, for example, open or synthetic data, but eventually it will be necessary to find some volunteers and have them try out the software so I can get some evidence on the workability of the software in a reasonable approximation of a real-world situation. It’s hardly the most controversial study ever, but it’s still research on human subjects and there will be processing of personal data involved, so things like research ethics and the GDPR come into play here and need to be duly addressed.

What I particularly needed a more precise idea about was the data that would be processed using the software platform. In the project proposal I said that this would be lifelogging data, but that can mean quite a few different things, so I needed to narrow it down to something specific. Of course it wouldn’t make sense to develop a platform for analysing just one specific kind of data, so as far as the design and implementation of the software is concerned, I have to pretend that the data could be anything. However, the only way I can realistically expect to be able to carry out a meaningful user test where the users actually bring their own data is by controlling the type of data they can bring.

There were a few criteria guiding the choice of the type of data to focus on. For one thing, the data had to be something that I knew to be already available at some sources accessible to me, so that I could run some experiments on my own before inflicting the software on others. Another consideration was the availability of in-house expertise at the Insight Centre: I’ve never done any serious data mining myself, having always looked at things from more of a software engineering perspective, so it was important that there would be someone close by who knows about the sort of data I intend to process and can help me ensure that the platform I’m building has the right tools for the job.

When I discussed this issue with my supervisor, he suggested sleep data – I’m guessing not least because it’s a personal interest of his, but it does certainly satisfy the above two criteria. Furthermore, it also satisfies a third one, which is no less important: there are many different devices in the market that are capable of tracking your sleep, and these are popular enough that it shouldn’t be a hopeless task to find a decent number of users to participate in testing the software. The concept of lifelogging if often associated with wearable cameras such as the Microsoft SenseCam, but these are much more of a niche product, making photographic data a not very attractive option – which it in fact was anyway because of the privacy implications of various things that may be captured in said photographs, so we kind of killed two birds with one stone there.

Capturing and analysing sleep data is something of a hot topic right now, so in terms of getting visibility for my research, I guess it won’t hurt to hop on the bandwagon, even though I’m not aiming to develop any new analysis techniques as such. Interestingly, the current technology leader in wearable sleep trackers hails from Oulu, Finland, the city where I lived and worked before joining Insight and moving to Dublin. There’s been quite a lot of media buzz around this gadget recently, from Prince Harry having been spotted wearing one on his Australian tour to Michael Dell announcing he’s decided to invest in the company that makes them. I haven’t personally contributed to the R&D behind the product in any way, but I feel a certain amount of hometown pride all the same – Nokia phones may have crashed and burned, but Oulu has bounced back and is probably a lot better off in the long run, not depending so heavily on a single employer anymore.