Archive for the ‘Development & Design’ Category

The Modern Front-End Workflow—From Start to Finish

January 30th, 2014 by Harry

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.

Start

modern-frontend-start

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.

Development

modern-frontend-develop

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.

Review

IMG_1083

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.

Deploy

modern-frontend-deploy

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.

Summary

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.

How Angular Lets Us Iterate Like Crazy

January 15th, 2014 by Nick

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. []

Things to Know About the New Chartbeat Publishing Design

December 11th, 2013 by Tom

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

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

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

flexible

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.

Data in Your Menu Bar—Meet the Chartbeat Notifier

December 4th, 2013 by Harry

chartbeat notifier

 

Hack Weeks at Chartbeat are always a time of joy. A time of joy for trying and learning new things. It's a great opportunity for everyone at the company to stretch their minds and tackle new challenges they wouldn't otherwise experience. We get to pair up with people we don't usually get a chance to work with, and we get to play around, creating things that sometimes become indispensable for our clients.

Two Hack Weeks ago I worked on a project called Chartbeat Notifier.  It was started by our former CTO Allan, and he had already completed a large chunk of it.  However it wasn't completely finished, nor was it in a state that we could share.  So I finished the Notifier, polishing the parts of the project that needed a little more TLC.

This most recent Hack Week, I pruned off the remaining rough edges and it is with great joy and pride that we are releasing the Chartbeat Notifier project as an open source project!

Chartbeat Notifier is a native Mac application that lives in your menu bar.  For your domain it can show one of two metrics in an always visible location:

 1. the number of concurrent visitors on your domain

2. the average Engaged Time of all the users on the domain

Either number will be always visible in your menu bar, and is continuously updated as the day goes on.

chartbeat notifier

 

Chartbeat Notifier also serves as a handy way to quickly jump into your dashboard.  Simply click on the Chartbeat menu bar icon and the 'Open Dashboard' link and you'll be taken directly to your dashboard.  Quick and easy, just the way we like to keep things.

There's only one thing that I love more than Hack Week, and that's when we are able to share our hacks back to the community.  Click on over to the Chartbeat Notifier project page and click the download link to get started!

PS- To see more of our great hacks in action, visit Chartbeat Labs.

Links We Like: Frontend Development and Design

September 20th, 2013 by Harry

javascript

Hello and welcome back to another fun roundup of new trends and technologies in the world of frontend development!

In this fast-paced field things are always in motion. I'm here to help you stay on top of what's new and what you need to know.

To start things off let's jump into a nice article that explores the what are the top languages used on GitHub in 2013 (so far). Compiled using Google BigQuery the results are in line with what you would expect of GitHub developers: JavaScript and Ruby take the top spots (first and second respective). What does surprise me is that Java is way up on the list at number 3. I suppose that should be expected given Android is built in Java.

Taking a detour into more tech-heavy articles, I came across this article which shared a tip on how to ignore library code while debugging in Chrome. Why is this cool? Well if you've ever been neck-deep in a call-stack trying to figure out a bug's origin you can sometimes get lost in the libraries you're using on the page (e.g. jQuery, Backbone, Angular). What this trick allows you to do is have these libraries excluded when debugging, allowing you to focus only on your code! Pretty handy!

Another handy trick is this break-on-access repository on GitHub. If you want to spy on when a property of an object is accessed or modified this library will allow you to enter the debugger at that point. Very handy for situations where you may not know when an object is being modified, but you know that it is being modified.

A fun Tumblr blog popped up over the past week, highlighting what applications could look like if they were designed for iOS 7. With iOS 7 released on September 18th you can bet you'll see its design ethos echoed across the internet. This is a nice way to prepare yourself.

Along with finding inspiration for how to design for iOS 7, take a look at this very comprehensive post about how to create a web app that looks like an iOS 7 native app. Especially useful if you're looking to create a Phonegap hybrid application. There are many tips, tricks, and nuanced details in this blog post that will prepare you for developing iOS 7-like web apps.

And there you have it! This week's roundup of what's new and what's being talked about on the world wide web. As you can tell, Apple still has quite the influence - punditry aside. The release of iOS 7 is only the start of ripples that will grow.

As always, keep learning and looking for what's new. I'll be here doing the same.

 

Harry also maintains a personal blog at harrywolff.com.