|Self researcher(s)||Kiel Gilleade|
|Related tools||sensor, Excel|
|Related topics||Mood and emotion, Media, Heart rate, Activity tracking, Stress, Productivity|
Builds on project(s)
|Show and Tell Talk Infobox|
|Event name||2014 QS Europe Conference|
|This content was automatically imported. See here how to improve it if any information is missing or out outdated.|
Rhythmanalysis is a Show & Tell talk by Kiel Gilleade that has been imported from the Quantified Self Show & Tell library.The talk was given on 2014/05/10 and is about Mood and emotion, Media, Heart rate, Activity tracking, Stress, and Productivity.
Description[edit | edit source]
A description of this project as introduced by Quantified Self follows:
Kiel Gilleade has been interested in measuring and visualizing physiological data for quite a while. In this video, Kiel talks about his new project, Rhythmanalysis. Rhythmanalysis was a project centered on “visualizing the biological rhythms of employees at different workplaces.” He describes his experience working on this project and some of the lessons he learned along the way.
Video and transcript[edit | edit source]
Kiel Gilleade Rhythmanalysis
Hi everyone, my name’s Kiel Gilleade and this is me, or to be precise this is me in 2001. This is a visualization of all the heart data I tracked for a project called body blogger which I presented here back in 2001. This is a heat map during the course of that year. And one of the things that we learned through that project was creating meaningful interfaces that convey to something important in the data, so either yourself or to end-users is really really challenging to build. And what I’m going to talk about today is a project that I consulted on about trying to create similar visualizations for workers as part of an art project. So what we did was in conjunction with Liverpool we were looking at the daily rhythms of workers and can we convey this in interesting art works. But the problem with this and looking at daily rhythms is how do we quantify the daily rhythm of someone at work. And it was particularly challenging in how we were going to encapsulate this. We were looking at performance metrics and the amount of work that you do through the day, the psychological impact of going through the work, physical activity, and one of the particular things of interest was we’re not workers in the zone. But again in the zone, while it does sound cool it’s again, how do we quantify something in the zone. In the end, we chose to quantify workers at the place of work using heart beat rate, motion, and a series of subjective questionnaires which would ask them periodically through the course of the day. Now the place of employment that we were interested in monitoring, we attempted to monitor three groups of employees; people at Game entertainment at Liverpool, hairdressers, and people on production line work. Originally we were going to use low cost centers compared to a mobile phone; it’s dead cheap to employ this type of tech. the big problem was is trying to deploy this into a workplace we automatically got overruled by the game testers because they are not allowed to take mobile phones into their place of work due to security reasons in case the latest technology was leaked out. So this obviously meant we had to drop the mobile phone and go for sensors that had their own internal memory supply, and in this case we used Camtech centers. Unfortunately because of this we were automatically ruled out from going into the production line workers due to health and safety reasons. So we can no longer monitor people making chocolates which would have been an interesting thing to work at. So an interesting thing in adapting the QS principles to the workplace was the fact that in order to adapt we had to radically change the project because we could deploy the similar sensors we used in a personal sense into the work environment. And that was interesting to do that because it did change the type of data collection that we could do. Originally we were going to look at groups of people over the course of a single day and create an art piece from that. Unfortunately because we couldn’t use cheap sensors we had to radically scale the project. So one of the interesting things is after the data collection was trying to figure out how do we visualize this and convey this in the form of an art piece. This was one of the early proposals that me and a colleague made base on the body blogs type of data for a bit of a techy thing is about visualizing heart rate as color codes and the height graph. So we would have two bars representing short and long cardio time, so you could see what people are doing over long term and what people were doing in the short term. Conversely, comparing that to the designers that we had on the team, they were going for the more not dry and scientific route, they were going for these organic, over the top and systems displaying the art work. And this is a picture of the final concept that was actually built, which we will get on in a sec. And it was interesting comparing it from the more techie side and what we wanted to convey what we know in the data because we have messed around with it, compared to the designers who were trying to play with a theme and try to convey information that way. There were interesting conversations in the project about whether we could actually see anything meaningful from these elaborate designs. Whereas considering from a technical point of view we knew what was in the data, because we obviously collect it and processed it. And this is the final design that was recently shown and each of these little circles, boxes, little spinners that represent heart rate of the individual people and they all synchronized and played according to the people we monitored. And some of the important lessons that we learned is QS tools although they can be personal have to be adaptive to the workplace and adapting these tools for work. And another thing that we did find in the end of this project in creating meaningful interfaces it will be useful instead of trying to just give an interface for someone to use and see if they drive, but if we give them the tools to create their own interface and understand the data from the data source to derivatively create.
About the presenter[edit | edit source]
Kiel Gilleade gave this talk.