Archive for the ‘Chartbeat API’ Category

Sound and Color: Data as Art

June 18th, 2013 by Danny

As an engineer at Chartbeat, I’m obviously a believer in the power of data visualization. When you have the right data displayed in the right way at the right time, you gain a deeper understanding of the world and can make more thoughtful decisions based on that.

This belief has made me very curious about what happens when you bring data and technology to fields where they’re traditionally absent. I’ve worked on a number of projects exploring alternative data visualization and interaction, ranging from SoundQuake, the winning piece at Art Hack SF, to Living Los Sures, an innovative documentary piece from PBS’s POV Hackathon last summer. I often use my Hack Week time at Chartbeat to try to visualize and interact with our data in new ways. 

Data as Abstract Expression

We usually visualize data in very literal ways to make sure we’re getting a concrete sense of what it means in real world terms. Numbers, charts, graphs – these take a data set and convert it to something very tangible. You can understand the Average Engaged Time of all users by converting the Engaged Time of each individual user into a single number. You can understand which sites refer traffic to your site more than others by looking at a pie chart of referral traffic which translates percentages into literal segments of a circle.

But I was curious what would happen if you broke that literal connection and tried to convert a data set into something more purely emotional, active, and formless – if you could connect the data to the subconscious in a way that yielded a different understanding of it. My expectations were that it would be “kind of cool, but probably not that useful.” The result, Chartbeatnik (the name seemed more clever at the time…) was an interesting first foray into this idea.

Chartbeatnik uses d3 and SVG to convert real-time data into an abstract expressionistic dripped-paint style visualization. Each visitor will be painted on the screen and the Engaged Time of that visitor will affect the size and shape of the form. So rather than seeing the Engaged Time of your visitors as a single literal number, you see it unconsciously in the energy and spirit of the forms. 

Data as Synthesized Sound

I’m a musician and have been very interested in sound as an expressive form for a long time. For one of my more recent Hack Week projects, I wanted to see if I could convert a data set into a soundscape – a kind of data synthesizer. I was also curious to experiment with Web Audio. I ended up making Chartwave, which takes a historical data set from Chartbeat’s historical traffic series API and creates a soundscape based on the series data returned. You can modify which series it uses by adding something like ‘?fields=return,social’ to the end of the URL (the available values are listed in the app itself and the API documentation).

The first parameter controls the frequency of the tones played. The set of possible frequencies spans 5 octaves, harmonically centered on a G major chord. As you go up in frequency, the harmonic focus shifts occasionally to A major. The subset of frequencies playing at any given time is determined by the value of the first parameter at that time relative to the maximum value of that parameter. So if the first parameter is 10% of the maximum in the series, then the lowest 10% of tones will be playing. The bottom 2 tones are always playing no matter what. Each tone plays for a random amount of time between 0 and 5 seconds, with a 1 second cooldown before it can play again. So not all tones that can be played will be played at any given moment – a given tone might already be playing, or in its cooldown phase.

The second parameter controls the level of distortion and reverb applied to the output. This is controlled similar to the first one, based on the value of the second parameter at any given time relative to the maximum value in the series. So if the second parameter is 50% of the maximum in the series, 50% of the output will be routed through the distortion/reverb channel.

For those curious about slightly more technical details, the routing graph is detailed here. The first parameter basically controls the gain levels of the spectrum of oscillator nodes. The second parameter controls the relative gain of the MasterWetGain vs the MasterDryGain – to increase distortion/reverb, more of the output is from the MasterWetGain. It uses the Web Audio API, jQuery, Underscore, dat.GUI, Html5Boilerplate, and the Google Visualization API.

Data for everyone

Beyond being “kind of cool,” these experiments are interesting to me because they don’t assume that everyone sees the world the same way. Maybe for a lot of people numbers are the fastest, most useful way to understand something about the world, but there are probably other people for whom numbers don’t quite have the same power as sound or color. We should be open to the idea that in some contexts numeric information could be converted into expressive forms that might be more meaningful.

If you have any ideas for future hacks involving abstract data interpretations, please shoot me an email or add suggestions in the Comments section.

Illuminating Hack: Pager Hue-ty

May 31st, 2013 by Justin

As many of you guys know, every 7 weeks at Chartbeat we have a Hack Week where we can work on any project or projects that interest us. At the end of the week, we present our creations, some of which make it to our Labs page or even become fully-fledged features for our products. 

Meet Hue.

Last year Philips released a much-hyped LED light bulb called the Hue that gives you complete control of every aspect of the bulb from your smart phone or through the Philips website. Hue lights have an API which unlocks a ton of potential for interesting integrations.  I acquired a Hue set around the holidays and ever since I’ve been wanting to hook them up to our PagerDuty alert notification system at Chartbeat.

Enter: My Hack Week project, which I’ve named “Pager Huety”.  Pager Huety is a script that controls the Philips Hue light bulbs based on triggered incidents from the PagerDuty API.

Meet me and my hack.

Part of my job as the Chartbeat Senior Web Operations Engineer requires being a part of an on-call rotation to ensure everyone’s dashboards are running smoothly 24/7.  Occasionally you may see an issue on your dashboard but luckily we’re immediately alerted to any issues via our monitoring system, which will send an alert via PagerDuty to the dedicated on-call team member.

I wrote Pager Huety to wake me up in the middle of the night with my Hue lights rather than have my phone going off with whatever less-than-awesome ringtone I’ve selected.  There’s an option to only have it alert during nighttime and filter for incidents only assigned to me.  Currently the default light sequence is to flash the bulbs red and blue a few times, then turn bright white for 10 seconds and shut off.  A video of Pager Huety in action can be seen below:

 

There are a lot of cool things you can do with the Hue Bulbs and your Chartbeat data.  You can even utilize the Chartbeat API to flash Hue lights when you hit a new 30 day max – want to give it a go yourself? Tweet your results to @Chartbeat.

Hack Week Kickoff: Creating a Reader that Measures Quality

April 2nd, 2013 by Shaun

After wrapping up some exciting additions to the Heads Up Display, I’m diving into my second Hack Week here at Chartbeat. For those of you who don’t know, the Chartteam has a Hack Week every six weeks where people can work on a project of their own choosing. The only rule is that you have to have something to show at the end of the week – in the past people have built new dashboards, apps, robots, and explored the Chartbeat API extensively (you can see past projects on our Labs page).

Goodbye Google Reader

Feeling inspired by the recent departure of Google Reader, I’ve decided to attempt to create a feed using content trending on Chartbeat’s partner pages. As most developers know, creating a compelling Hack Week demo in just a week’s time is a pretty ambitious goal, and building a new type of content aggregator is definitely going to be a challenge. 

My Project: just a bit ambitious

Most reader services focus on new and trending content. But usually when I’m looking for new content, I want to make sure not just that it’s new, but that it’s actually interesting and worth my time – it has to be a quality piece. But to date, I haven’t seen a real measure of these stories’ quality in a reader. That’s mostly because readers measure only metrics like page views, shares, and likes, which indicate that people enjoy sharing a story, but I want to know if a story holds peoples’ attention and keeps them engaged.

At Chartbeat, we’ve built our metric Engaged Time to do just that – measure more than just those people that click and bail, but the quality of that content as defined by a reader’s experience – if they choose to give a story their attention, their time. So I’d like to see how factoring in Average Engaged Time data will affect how my Hack Week feed sorts and ranks stories.

By displaying a list of content filtered by Average Engaged Time and by the average reading time each story takes to finish, I think readers could find the content that’s more likely to keep their attention, keep them engaged.

Over the next week I’ll build an application that uses data available through the Chartbeat API* to build a reader that aggregates content based on how Chartbeat measures quality – through Engaged Time as well as some of our other metrics – including one I’m hoping to create with this hack project.  I plan to share what I learn from this experience with you. 

blog-2-ss

Technical details

As with all Hack Weeks, the goal is not only to create something new, but to challenge ourselves technically, so I decided to do this project in Python, a language I have only recently dabbled in. Focusing on the backend of the application first, I will build an API to report the necessary data along with a few new metrics related to the task at hand. From there I will create a basic user interface, in Google’s Closure JavaScript library and test out the concept from there. If I am happy with the results, the UI will be polished, and maybe added to our Labs section of our website.

As usual, any comments or suggestions are appreciated. See you all next week!

*While we experiment with the data available from our API, our clients’ data is kept private and never shared publicly.