Archive for the ‘Development & Design’ Category

Phone-owning journalists, we’ve got some big news for you.

Today, we’re releasing our new, improved, powerful mobile iOS app.

For the last four months, our team has been working hard to build an enjoyable, on-the-go experience that brings you all your most important data—whether you’re in line for groceries or just stepping away from your desk. We think you’re really going to like it. Let’s dig into how we made it happen.

It all started with listening: We read through your feedback emails, documented your bug reports, and most importantly, we met in person with a whole bunch of you. We wanted to know what you dug about our current app and what you thought might make the experience better.

Through many design iterations and feedback sessions with our beta testers (huge thanks to y’all!), here’s how we translated what we heard from you into the new app:

First things first, your Top Pages

This is the guts. This is what we heard is most important for you to see. Now your site’s Total Concurrents are front and center, and we added in the animated dial to let you know, top level, where you’re at right now in a clean, no frills design.

Your Top Pages@2x

Richer traffic sources

Tab over to Overview, and you can view how different traffic sources are contributing to your concurrent count over time. Pivot left and right to home in on top referrers within those categories. This feature is now also available on the page detail level, so you can better understand where your readers are coming from for every piece of content.

Richer traffic sources@2x

Page deep dives

Speaking of page details, you can now zoom in on the content that matters to you most. Tapping on a particular story will bring you to a thorough overview of how that post is performing.

Filtering galore

You want to see what’s important to you. Now you can click on Filter in the top right of your navigation and choose a section, author, traffic source, or referrer to dig deep into the traffic patterns you’re seeing in real time.

Filtering galore@2x

More data, more viz

You know just as well as we do that it’s not just the clicks you get, but the attention you keep that matters. You’ll now find two signature Chartbeat metrics — Recirculation and Engaged Time — in the mix. These are the kind of meaningful metrics that help you grow your audience, not just scavenge for pageviews.

More data, more viz.@2x
You’ll also get breakdowns of your sites’ visitors by their frequency of return and what device they are using in an engaging visual display.


The app will now remember, automatically save, and return you back to the last site you were viewing the next time you open the app. No more futzing with settings.

Now, hop on over to the app store and download it!

And while we hope you love this update, there’s always work to be done. Want to help us prioritize the wish list? Email your thoughts to And if you have something nice to say *fingers crossed*, be a pal and leave us a review in the app store?

Before we close out this post, a huge tip of the hat to the Chartbeat dev team who wrote this entire app using React Native, which we were synchronously learning and teaching ourselves as the React community was building it. At Chartbeat, we take our commitment to learning and self-improvement seriously, and as you can see, the results are pretty fantastic.

Please note: some features are available to Chartbeat Publishing clients only. Want the app in all its glory? Send us a note to to learn more about upgrading to our Chartbeat Publishing suite.

PS: Android users, we hear you, it’s coming… If you could do us a favor and fill out this form we’ll be sure to keep you in the loop!

For a full walkthrough of all the new bells and whistles check out our orientation guide.

A little while ago we released our Paid Content product after two consecutive six-week sprints. The first six weeks were spent creating the MVP, and the second six weeks were spent polishing it up. This is the breathless tale of those first six weeks.

Part 1: Research

This whole thing began because we saw that our clients were struggling. Paid content, sponsored content, native content – whatever you call it – remains a mysterious beast for many folks and there were few options for measuring paid content performance, let alone figuring out what you can do to make it better.

For the first two weeks of our sprint we researched and brainstormed. We huddled into offices and littered the white boards with ideas, questions, diagrams, and whatever else we could to make sense of things. We’d pore over data to see what insights we could glean and what information would be helpful to know for any native content campaign. It was a lot of debating and arguing, breaking for lunch, and then regrouping for more debating and arguing.

Amidst these debates we talked to existing clients. A lot. We wanted to know how they created paid content campaigns, and what pain points they have experienced. We’d invite them into the office and talk to them on the phone. We’d visit them in their office and pummel them with questions, searching to find what we could do to improve how they analyzed paid content performance.

Part 2: Design


As we were assessing the type of data our clients needed, we also began to design our version of better.

We’d create one mock-up, show it around, gather feedback, and iterate. We’d see what worked in a design and what didn’t. We’d toss out the bad, toss out some of the good, and try again. We moved swiftly, for time was against us.

Something that proved to be a great success were clickable mocks. Typically a mock is static. With a static mock you can cycle through a list of images to give a sense of what the product will contain, but a clickable mock allows you to simulate how the product will feel when it’s complete.

These clickable mocks proved insanely helpful when discussing the product to clients. It enabled us to show our ideas and direction rather than just tell.

Part 3: Development

With under three weeks left to go in the cycle we knew we had to hustle.

We wanted to see what the data for a real paid content campaign looked like so we worked towards getting things working on the screen as fast as possible. Despite all our planning and designing we had yet to see real data for a paid content campaign and we had concerns that we had planned and designed for data points that may not exist. It’s fine to plan to include data about the amount of Twitter activity that drives traffic to a piece of native content, however if that value is always 0, it’s not helpful.

To our relief our planning paid off. The data worked and made sense. From there on out it was a sprint to bring all the beautiful designs to life.

Part 4: Launch


With the launch of our MVP looming we knew we’d have to start making some hard decisions. Everything we wanted to include for the first version would not fit, so out came the knife as we looked to see what we could cut away.

Delicately we began to inspect what was left. We began to weigh things, deciding what were show-stopping features or essential functionalities that had to make it for the launch, versus things that would be fine to include afterwards. We’d see which features would be more ‘expensive’ to complete. At this stage the only currency we traded in was time, with everything balanced between time to complete versus its impact on the product.


Some hard decisions were made but ultimately we managed to ship on time and practically feature complete.

We were able to bring to market a product that six weeks prior did not exist as anything but an idea. Everyone at Chartbeat came together to make this a reality, each pulling their own weight and helping one another. Through and through it was an incredible team effort.

Within Chartbeat we managed to create a MVP in record time. We were able to assess client needs and industry gaps to form our product and get it out the door and into client’s hands. We’re not done, but we’re off to a strong start.

Front-end engineers have gone through a bit of a renaissance in recent years.

There’s been a wild and wonderful spurt in innovation that has completely changed what it means to be a front-end developer.

We now have a vast and wide array of tools available to us, allowing us to develop faster and smarter.

We now can push the limits of what a modern web browser can do, accomplishing things that two years ago seemed impossible.

Bottom line, right now is an amazing time to be a front-end developer.



Today there is almost zero friction to getting set up with a new project. Everything that you need to get started is only a few key strokes away thanks to some powerful new tools.

Git is the version control system of choice for most developers nowadays. It makes sharing code easy and frictionless. When you want to get going on a new code base you only have to run the simple git command of git clone and all the code and all of its history is downloaded directly to your computer.

NPM is the node package manager. It allows developers to package their nodejs code a self contained module and then share it with the community. There are npm packages that provide almost every type of functionality you can imagine, allowing you to leverage the work of the community. Each new project has their own unique set of dependencies they require for them to work. To get all these dependencies installed locally you only need to run npm install, which downloads and installs everything you need.

Bower is a package manager for third-party web libraries. Historically if your project requires jQuery be included you would have to navigate to the jQuery website, download the file, extract it, and move it into your project. Bower simplifies that process by giving you the command bower install which handles getting jQuery into your project.



Actually coding and developing your project is where most time is spent. Nowadays this is one of the most enjoyable parts due to the many wonderful tools available. These tools make dev’ing so smooth that I’d dare say it makes it fun. Scratch that – it makes it oodles of fun.

GruntJS is the most popular task runner amongst front-end developers. There’s already a huge community of grunt plugin authors that to date have written over 2,000 Grunt plugins, all of which are immediately ready for your use. Grunt allows you to automate rote tasks without breaking a sweat. For example if you need to compress all your jpg, gif, and png files you can use the imagemin grunt task .

CSS Preprocessors like LESS, Sass, or Stylus have made it easy to architect maintainable, extendable, and modular CSS. Among the many features that CSS preprocessors provide the two of most value are without a doubt nested selectors and variables. Having the ability to define a color variable in one location and use it throughout allows for a flexibility in CSS that did not previously exist, yet one that was sorely needed.

LiveReload changes the way you develop, as it brings a fluidity to your development flow that you didn’t realize you needed. Whenever you change a file that you’re working on LiveReload will notice that it changed and refresh your browsers so that you can immediately see your changes in place. No longer do you have to save a file, switch to the browser, and then refresh the page. With live reload after you save a file the browser will refresh itself, saving you time and grief.



When you’re ready to push some of your code into the wild it’s always a good idea to review it with your team and run it through some code quality and style tools.

A GitHub Pull Request is one of the handiest ways that you can rally your team around vetting your changes. After opening a pull request you’re given a page that allows you to clearly state what you changed along with a view that shows the changes you made. Coupled with a robust comment system, a GitHub pull request makes it easy for your team to review and give feedback on changes.

JSHint is a tool that programmatically finds errors in your code. It’ll prompt you if you have a function with two arguments, and the second argument is never used, or if you’re missing a semicolon where one should be. All these things ensure your code is in good shape, allowing your teammates to focus on other things that aren’t as nit-picky as JSHint.

JSCS is another tool that is great to have in your repertoire. JSCS is a JavaScript code style checker, focusing on the style of your code and not the quality. You define what code styles you want and when you run your code through JSCS it’ll alert you if there are any areas of your code that are not inline with your project’s expectations.



Getting your code from your computer out into the world is the best part of development, as it’s when you get to share all your work with the world at large.

Continuous integration is a practice that enables and encourages getting your code to production frequently and without fear of breaking anything. A CI server will automatically perform tests across all products, not just the ones you touched. If any tests fail alerts are sent out and any changes to production are halted, preventing regressions from reaching production. When all tests pass your changes are merged into the production ready branch, assets compiled, and production is updated.

This makes the entire process of getting your changes live easy, effortless, and safe. You can view the progress of the CI server as it chugs along, letting you be kept in the loop of what’s going on without having to push the process along yourself.


The life of a front-end developer has never been easier. Browsers are getting better every day, and the tools we have at our disposal have never been better.

No longer are we wallowing in the shadow of legacy browsers, but we’re barreling ahead to stretch what’s possible in the browser.

The processes outlined above lets you worry less about minutiae and just focus on development and the product.

The life of a front-end developer is pretty damn good.

Interior, startup office loft. Friday Afternoon.

SUIT: Hey dude, you know Feature X that we were asking for?

DEVELOPER: Do I ever! I spent all week working on Feature X, and you know, I’ve really started to take a special pride in how it’s turning out!

SUIT: What if—now hear me out—what if we didn’t do that at all. Let’s just cut it completely. Instead, we’re going to do Feature Y: we’ll graph this one thing against this other thing, and have it automatically annotate and blah blah foo bar etc etc…

This type of exchange is familiar to most developers, and particularly to those of us working in the startup world. The “suit” might be an executive, a product manager, or even a designer (it’s just more fun to call the person who’s telling you what to do a “suit” in this context1).

There are a few different ways this conversation can continue:

1. The developer refuses. She’s worked too hard on Feature X, and dammit, you’ll have to pry it from her cold dead hands!!!

2. The developer begrudgingly agrees to throw out her precious work and start again from scratch, but she’s really not happy with it. Deflated, she might not work as hard this next go-round, and the suit might not be quite as inclined to reimagine the product next time (even if it seems like the right thing for the product).

At Chartbeat, we aim for the conversation to continue something like this:

DEVELOPER: Yeah, we can do that. Actually, you know when I said I’m taking a special pride in this thing? It’s because I anticipated that you’d want to do several revisions of Feature X, and I built some flexibility into the code, so making Feature Y will actually not be so hard. I’m almost glad you asked for this change, because now I have the opportunity to amaze you with how fast I’ll churn this thing out!

Admittedly, that’s a completely contrived example and an exaggerated response. In real life, we’d probably try to see one version through and actually test it out with users before deciding to go in another direction (unless we’re in the extremely early stages of a product/feature). Also, a little bit of disappointment in lost work might be expected and is totally okay—we’re not robots. And from a development perspective, it’s not always best to spend extra time making code super-extensible/flexible if there’s a high likelihood that it will never be used outside of its original context.

Continuous Iteration

But my main point still holds: to end up with the best product we’re capable of creating together, we need to be able to change directions, and we should expect to change directions several times.

We don’t have (or want) the luxury of moving from “requirements gathering” to “specification” and then to “design” and “development” phases. All of those tasks are happening in parallel, all the time. As our user researchers and product designers continue their own iterative processes, the “ideal product” will become clearer and clearer. When presented with a new or revised product goal, the engineering team needs to be ready and able to quickly move toward that evolved goal.

Getting Technical

Today I’d like to talk about one way we enable this kind of flexibility through our engineering practices and technology choices. I work primarily on the front-end (the code actually running in your browser: HTML/CSS/Javascript), so that’s what I’ll be talking about2.

A few months ago, we were starting to build out a couple new products, and as is always the case when starting a new project, we had to decide whether to keep using our old tools, or make some changes. In particular, we had recently hired a number of front-end engineers who weren’t too keen on our Google Closure-based JavaScript code.

Closure: The Good, The Bad, and The Java

Closure has a lot of cool features, but its best feature by far is its compiler. Briefly, a compiler is the software that takes the easy-to-read code that you write and turns it into the small/fast code that runs in production. Closure’s compiler is extremely good at taking a large codebase—for example, our multi-product internal library along with the large standard library included with Closure—and pruning it down to only the code that is actually used by a program, and then smushing that code into an extremely small file. This feature has proven to be a huge win for our “pinger” code (the code that runs on our clients’ websites) since that code is downloaded about 10,000 times each second, and appeared on 71 million unique pages in the month of November. Making that code small is a win for everybody on the Internet, and the Closure Compiler does a tremendous job.

However, to achieve these awesome compilation characteristics, Closure requires the programmer to add a lot of special annotations to the code that are not normal to JavaScript coders. In effect, to the developer it “feels like writing Java,” which as we all know, is a terrible feeling3. Closure also suffers from a small and generally pretty inactive community, which makes it harder to find helpful resources and generally just less fun to use.

In the end (and after much urging from our newer hires), we felt that these drawbacks were significant enough that we should explore other options in the JavaScript space.

Weighing Alternatives

Several developers decided to spend a Hack Week (an every-7th-week tradition at Chartbeat) independently trying out a few different JavaScript frameworks/libraries that we thought looked promising. At the end of the week, every person who had tried AngularJS4 seemed to think it had a lot going for it. In a meeting of our front-end developers that went on for way too long, we hashed out the pluses and minuses of making a switch to Angular.

Changing technologies would mean a new learning curve—a short-term drop in productivity—for all of our front-end developers, so it wasn’t a decision we took lightly. On the other hand, those who had tried Angular during Hack Week were excited by its possibilities—we felt it would enable the creation of better features, with nicer/better code, and would boost productivity once we got over the initial hump. At the end of the meeting, we had decided to use Angular for our new projects moving forward, and even to abandon a Closure-based alpha version of one of our new products and rewrite it using Angular.

We continue to use Closure to maintain our legacy codebases and for our pinger code (where the benefits of Closure’s advanced compilation/compression are really huge) but all new projects are now using Angular.

AngularJS: Making HTML into an Application Language

In my mind, the biggest benefit of using Angular is its usage paradigm, derived from its core philosophy that HTML is a document language and what we want it to be is an application language. In short, where most other frameworks have you write vanilla HTML and then, through some code process, grab pieces of the document and “attach” behaviors to transform the static HTML document into user interface components, Angular in essence allows you to extend HTML by creating your own HTML tags for your user interface widgets. The tagline on the Angular homepage sums this paradigm up nicely: “HTML enhanced for web apps!”

To illustrate the difference, under the more traditional paradigm, we would probably create our graph by having some placeholder for it in our HTML document, like:

Then, in our JavaScript code, we’d have to explicitly find that piece of the HTML document, and insert a graph drawing into it. Our graph might have labeled X and Y axes showing, 3 different lines of different colors tracking different properties over time, etc. All of the configuration for this graph would probably be embedded in the JavaScript code: everything from the very existence of this graph—we have to know to actually find it on the page and insert the drawing!—to how many lines, what data the lines should graph, which axes to draw and how to label them, etc. Any changes to the graph will likely involve finding and changing JavaScript code, and will almost certainly require a “programmer” type of person.

Not Your Grandfather’s HTML

Using Angular, we’d have an HTML document more like this (simplified a bit here):

If you’re thinking, “that’s not HTML anymore! What are these graph, line, and axis elements?”—well, that’s the point, Angular allows us to “extend HTML” to create those elements! In our JavaScript code, we would write code (called Angular “directives”) to implement the graph, axis, and line components. Those components would provide generic graphing capabilities, and they would receive their configuration from the attributes in the HTML document—for instance, the line with name="typical-week"  above would know that it needs to plot the data contained in model.series.typicalWeek , as configured by the line-data  attribute. Our JavaScript code doesn’t even really have to know that the visitor graph exists! We have turned HTML into an application language that’s allowing us to piece the view of our application together in a really nice way, by placing and configuring our user interface components directly in the HTML.

3 Graph Variations
3 different stream graphs using the same model data but different HTML templates. The model contains several data series, and each template displays a different stream graph by choosing a different set of series.

Now, I’m glossing over a number of technical details here, but hopefully this gets the general idea across. The flexibility gains over a traditional setup should be pretty clear: when a suit decides we should blow away a graph and create a different one with different info, it’s entirely possible that we only have to change the HTML to make it happen! The level of technical proficiency required to do this kind of change is now lower as well—it’s much more likely that a designer (or even a suit!) can actually make the change without a developer and prototype or explore new ideas. This kind of flexibility would be possible without Angular of course, but Angular especially encourages it by its very philosophy of “HTML enhanced for web apps!”

Closing Thoughts

This post has just scratched the surface of what our front-end engineering team is doing to increase and streamline our responsiveness to shifting goals throughout product development. One final note regarding this continuous iteration process: make sure you hire the right people. Our developers, designers, and managers have a mutual respect and trust in each other’s abilities. Without that trust, constantly shifting goals can very easily lead to frustration and disappointment.

More in-depth technical information will be appearing on our engineering blog more frequently, so make sure to check that out in the coming months if you’re interested in the details!

  1. As developers we just love to think of ourselves as rebels, although if I’m being honest about suits here, it was actually the development team at Chartbeat that had a tradition called “Menswear Mondays.” It involved blazers. Also, our CEO seems to only have one outfit, and it’s not a suit, but jeans, a white button-down, and cowboy boots. It must be a… British thing? []
  2. Our back-end engineers also have all sorts of cool stuff going on. For instance, Vadim embedded a Lua interpreter in our real-time database so that we can quickly prototype new APIs! []
  3. Especially when you don’t have Eclipse to make the experience flow nicely. Yes, I programmed Java for a while. Don’t flame me, bro. []
  4. For more on Angular, checkout the official site and this blog post from our own Harry Wolff. []

The goal of product interface design is to develop a product’s personality (the new Chartbeat Publishing is friendly, trustworthy, fast, modern), and tell a story (publishers can build and retain a loyal audience from our data). Everything about a product’s design relates back to its personality and story, including the visual style, the interaction design, and the language. This isn’t something we can get at the first go – it requires a lot of experimentation.

So at Chartbeat we have a process in place that allows us to rapidly try out ideas: not just at the design level, but at every stage of the project. We create a quick rough series of wireframes, and do the same for visual design sketches. Early on we prototype these designs in the browser (we love AngularJS over here), and even have a system that allows for quickly prototyping data in the backend (a custom LUA scriptable real-time backend). At every step of the way, we’re testing and tweaking to make sure that our choices support the personality and story we’re trying to portray.

In the middle of all this endless iterating, we reached a point where we’re ready for an initial stable release. While we will keep nurturing and iterating on this product, here are four major design improvements that are in the new Chartbeat Publishing today.

Improved signaling


A major goal in rebuilding Chartbeat Publishing was to further reduce the burden of interpretation on our users, i.e., make the product – not our already very busy clients – do more of the heavy-lifting. That goal was realized by a couple of different approaches, especially figuring out ways to answer common client questions of “what does this number mean?” and “how well is my site doing right now compared to at other times?”.

We expanded the product’s efficacy by using our technology not just to report numbers to you, but to interpret numbers for you, too. For instance, now when you mouse over your Engaged Time section in the dashboard, a tooltip tells you how strongly your site is performing as compared to the past month – are you “on par” or “over-performing” – along with your site’s monthly average Engaged Time and its maximum average Engaged Time. We go one step further by pointing out which articles are potentially responsible for either an over-performing or under-performing Engaged Time. And at all times we call out which articles should be regarded as “good for your site’s health.”

I talk a little more about the subject of signaling and invisible design on my own site.
Next up: see how the product’s signaling starts even before you start processing your dashboard data – thanks to our strategic use of color.

Color isn’t just color

Color is now a fundamental signaling element in the dashboard – we’re moving away from color as a legend – allowing you to interpret what’s happening in the dashboard (and thus on your site), even more quickly than before. If you see green, your brain automatically picks up that something positive is happening, whereas anything red implies that something is underperforming or past its prime. By using these simple cues, paired with a baseline blue palette, users can navigate the product even more efficiently without having to refer to a legend.

General affordance


Our first version of the new Chartbeat Publishing dashboard was powerful in many regards. But we noticed that some dashboard elements, particularly a few crucial features related to building your loyal audience, were hard to discover. This was definitely not the client’s fault – it’s up to Design and UX to figure out how to make these things easy for clients to find. In our case, this issue had more to do with the fact that we had learned even more about the industry after users started beta-testing our first version of the new product.

We decided to make it really easy to find all our different types of filter and sorts we made available. The UI for sorting on Engaged Time is now as prominent as we think it is useful. Filtering by something like your “new” visitors are reading is really easy to find in the new dashboard. So you’re doing less guessing and more getting right to it. This easier-to-navigate interface allows us to expose more advanced features.

Things are more flexible than ever before


One of those features is multi-pivoting, which lets you combine different filters. In the original Chartbeat Publishing dashboard, you could click into a story and drill down into a particular story’s data. The new dashboard lets you pivot and manipulate the dashboard to pull out almost any specific data you want – whether it’s the number of mobile readers you have in Spokane, Washington, or which stories are attracting your most loyal visitors right now – thus increasing the number of actions you can take. Being able to do more within the dashboard allows you to surface the insights you need to inform your decisions and processes.

All in all

Our mission is to keep improving what we hope is an accessible dashboard that presents actionable insights. Right now we’re looking at how people are using the new Chartbeat Publishing, and we’ll take those learnings, along with whatever major needs arise in the industry, to inform the next batch of updates.