Easyart Developers

Front-end optimisation

2014-08-15T15:27:59+00:00 by John Pash

Here at Easyart we are obsessed with speed. We constantly monitor the website’s dataflow from server response time all the way through to the end user experience. In our office, within view of the developers is a dashboard which immediately alerts us to any slowdowns or performance changes on the platform.

We take advantage of the great tools provided by New Relic and webpagetest.org and pipe them through a Geckoboard dashboard.

During a recent “speed-up sprint” we got stuck in to the numbers to try and find where the bottlenecks were and what we could do to fix them. So we ran a few tests on one of our product pages using various browsers in a few different locations around the world (thanks to webpagetest.org). The results showed that we should be focusing on front-end performance rather than the server/database/back-end (more on that later).

That waterfall chart certainly doesn’t look like the work of a team who “are obsessed with speed”! Not to worry, that’s the purpose of this exercise. So time to roll up our sleeves and find out just what’s going on here. We try to adhere to best-practices by gzipping content, using a CDN for assets etc. But the problem turned out to be even more simple to diagnose.

Requests!

There were a whopping 140 requests with a total download size of 1.3MB. So it was decided that reducing these would give the biggest return on investment. It turns out that many of these requests were coming from 3rd party scripts which download further scripts and tracking images. In particular, the popular addthis.com sharing button was a serious offender. This information is good to know, but we can’t just go removing things without a discussion with the marketing department first. So that will have to come later. Let’s clean up our own back yard first.

Images and lazy loading

On our target page we are loading 16 “related prints” which means 16 requests. We decided to “lazy load” them, meaning they won’t download until the user scrolls down the page. Strictly this won’t have any effect on total download size, but it will free up the user’s bandwidth and CPU for other things. Such as the Backbone app that powers this page.

Backbone and lazy coding

In the Backbone app we have a modal which displays a custom framing interface, complete with dozens of framing options. We were creating this view - and downloading the images it containted - every time the app booted. But not every visitor sees this modal, so why waste the bandwidth?

The reason for this oversight is because in a previous design, the custom framing module was on the page, seen by everyone. But later it was moved into a modal, and the code wasn’t refactored with optimisation in mind. So by now creating the view on demand (user clicks the change frame option) we save a few more image requests. Lesson learned: when things change, clean up after yourself.

Modals should only appear when requested

Further down the page is more 3rd party code (ugh) which displays a widget of recent reviews. This code downloaded even more js code, some css and even a webfont! So we changed this to download on when requested (onClick). Then we found 2 more modals of our own that were hard-coded into every page waiting for someone to find the magic link that would spring them into life. It’s easy to code, but not very efficient. These were also changed to onClick events.

Sprite-ify all the things!

The main “mega menu” for art Themes has 12 tiny thumbnails which represent each category. A prime candidate for a sprite sheet. This one change alone would save 11 requests at the cost of a slightly larger css file. But the trade-off is worth it. But why stop with these 12? We had a look at every site asset in the header/footer and elsewhere, and started adding them to the master sprite sheet. But as you may know, jpgs tend to be suited to photographic images and pngs work better for large blocks of colour and sometimes require transparency. So we decided to have the best of both worlds and make one of each (thank you Sprite Factory). This means two sprite requests, but better optimisation of the images themselves. Not to mention the quality of the images won’t suffer as much as they would if we tried to force a jpg-type image into a png.

Results

So what were the results of all this tuning and tweaking?

Speed Improvement

	Requests	Download Size	Time
Before	140	1.3MB	12.2s
After	53	698kb	3.2s
Diff	62%	46%	74%

Unexpected win

After the work was complete, tested and pushed to production and the victory celebration was about to start, we were alerted to the fact that Google Anlaytics wasn’t happy with the page speed! How could this be? Well the timing of this news was just a coincidence since it had nothing to do with the recent changes. What G was really complaining about was server response time. Something we blissfully ignored for this project. So back to New Relic to find the source of the problem.

What happened next could fill an entire blog post, but the long and short of it is: The amazing “Oj Gem”! Over 100ms saved on each and every JSON request from our back-end service.

iOS event bubbling

2014-06-06T10:41:44+00:00 by Steve Rydz

The great thing about being a web developer is that you get to learn new things all the time. This week, I learned something really simple, but it had a big impact:

iOS doesn’t respect event bubbling without a cursor style!

This amazed me. We have what we like to call popovers in various places on our main site, similar to these. Ours differ, in that we have a fullscreen, transparent div positioned behind them so the user can close them by clicking anywhere on the page. I discovered this wasn’t working in iOS.

The code looks something like this:

$(document).on("click", ".popover-overlay", function () {
    $(".popover-overlay").remove();
});

There didn’t seem to be anything wrong with the code and it worked everywhere else. We use similar looking code on other areas of the site and they were working in iOS. I was very confused at this point.

The difference between this specific example and the other places event bubbling is used was that the element we are targeting is not a link. It turns out that unless the element you are targeting has a cursor style applied, iOS won’t respect event bubbling.

After all that head scratching, the fix turned out to be:

.popover-overlay {
    cursor: pointer;
}

I couldn’t believe this. Especially as there is no visible cursor on iOS anyway!

Data-driven UX decisions

2014-05-17T15:08:52+00:00 by Nick Boyce

We all make countless decisions every day when we work. Which of the hundreds of reasonable things in my list will provide the highest value? How am I going to find the best solution for our customers? How will we know if we have even solved the problem?

Meanwhile, with every one of their interactions with you, your customers are constantly sending you signals that can be used to make better decisions. At Easyart we put a lot of effort into basing our decisions on data first, and opinions second. As Jim Barksdale, former CEO of Netscape famously said:

If we have data, let’s look at data. If all we have are opinions, let’s go with mine.

This post is about building better experiences for our customers through research and testing.

Research

Customer research

We must understand our customers in order to solve problems for them.

Daily survey

Our brilliant customer service team phones a small handful of customers and asks them five questions. The answers are recorded in a Google Doc.

Though it’s a small sample size, it provides useful qualitative information which helps us spot patterns in individual customer stories in a way that we could never get from an Analytics funnel or aggregate market report.

Market research

Periodically we conduct large-scale market research which provides us with aggregate information on our customer demographic. These are less frequent but a much higher sample size than our daily surveys.

Google Analytics, KISSmetrics, Crazy Egg and custom reporting

We use Google Analytics (from here on, GA) and KISSmetrics (from here on, KM) extensively to find out how our customers are interacting with our site.

Do and measure

Some things are not A/B testable, we don’t want to clog up the testing queue, or we’re confident enough about our hypothesis that we will accept measuring after it’s launched.

For every significant feature we create a GA annotation so we can do before-and-after analysis to check that everything went as expected. GA and KM provide different vantage points (GA tells you what’s happening. KM tells you who’s doing it), and we also use Crazy Egg for heatmap and scroll tracking.

We track click events on most of the elements we care about, so we can understand how users are using the site.

Funnels

Funnels are ways of modelling a user’s journey through the key parts of your site. We keep a regular eye on these to try to identify under-performing steps that might represent problems or opportunities.

Custom reporting

To find out very specific answers, we’ll run custom reports which might involve data wrangling in SQL or Excel. For example: finding out the average number of line items in our abandoned baskets, understanding the relative performance of the main navigation vs the various search functions or customers’ tendency to frame their print relative to the size of the print.

Testing

UserTesting.com

We use Usertesting.com to conduct remote user interviews. These allow us to observe people using the site as they follow a list of tasks. It gives us the “why” that is difficult to measure through metrics alone, and we predominantly use it to validate new UX ideas, as well as occasional competitor comparisons.

Watch the videos together as a team and share your findings.

It can be extremely humbling to you find out your brilliant idea makes no sense to the user, but it’s better that these lessons are learned together.

Test your iterations to gain confidence

Google Ventures' Jake Knapp puts the emotional journey of user testing perfectly in this post:

First session: “We’re geniuses!” or “We’re idiots!”

Sessions 2–4: “Oh, this is complicated…”

Studies 5-6: “There’s a pattern!”

By running new tests with each of our major iterations we can see quick improvement which usually results in us building enough confidence to launch (though we occasionally reject ideas that don’t test well).

These are not real customers

It should be noted that these are not your customers, nor are they in the same frame of mind that your customers will be, so don’t treat this as customer research.

A/B testing

A/B testing can give us the what to the user testing’s why, by providing a framework to validate a hypothesis.

Much has been written on the topic, and it’s easy to believe it can be used to unearth hidden conversion opportunities that will make you millions. The truth is, not everything is suitable for A/B testing, and there is a fine art to planning tests properly.

Start with a strong hypothesis

Don’t use a scattergun approach, this should be something you are confident about that is backed by data.

Ensure that the hypothesis is testable.

A good A/B testing candidate should be noticeable change, with decent traffic and an expectation for a double-digit improvement to a metric close to the area you are affecting (i.e. don’t expect a change on your category page will have a measurable effect on overall conversion through your checkout).

We usually calculate the test plan using something like experimentcalculator.com

Agree the success metric upfront.

Don’t leave it open to interpretation, don’t let ego get in the way, and be willing to lose. The truth can be humbling.

Use more than one source of data.

We use Optimizely to run the tests, but do most of our analysis through Google Analytics and KISSmetrics custom segments. This allows us to understand how users of each variation are behaving throughout their whole journey.

Go with your gut

We don’t make every decision using data. Sometimes it just isn’t possible, particularly with creative decisions, and in other times there isn’t a lot that can be learned by analysis.

There is never absolute truth in numbers, and it’s best to just go with your instincts and have the confidence to push forward.

Getting started with Jasmine on a Rails project

2014-03-21T15:08:52+00:00 by Steve Rydz

We’re big fans of TDD here at Easyart. So far this has only applied to our Ruby code, but with JavaScript increasingly becoming a bigger part of our technology stack, we needed to start testing that too.

Choosing the right tool

We chose Jasmine as our testing framework, partly because of its similarity to RSPEC, and also because its really easy to get started with.

You can get started with Jasmine fairly quickly. Their standalone distribution has everything you need to get up and running. Opening the included SpecRunner.html will run the example tests and show you the results. From here you can swap out the example files with your own.

Getting up and running on Rails

Once we settled on Jasmine, we needed a way to integrate it into our current workflow, as we don’t want to be running tests manually all the time.

Luckily, there is an official Jasmine gem. To add this to your project add the following to your gemfile:

group: development, :test do
    gem "jasmine"
end

To setup the file structure that the gem expects for your tests, run the following command from your CLI, which will set up all the necessary files and directory structure to begin testing your code:

rails g jasmine:install

Running the tests

There are two ways you can run your Jasmine tests. The first is to run the following rake task:

rake jasmine

This will fire up a web server, accessible at localhost:8888 where you will see an HTML document displaying the results of your tests.

You can also run the tests in continuous integration mode from the command line, which will show you the results in the terminal:

rake jasmine:ci

Writing the tests

As I mentioned before, Jasmine is easy to get started with, as long as you are reasonably comfortable with JavaScript, but if like me, you’re new to writing tests it can be hard to figure out where to start.

The key is to write code that is actually testable. The simplest way to do that is to ensure your code returns something. I attended a testing workshop a little over a year ago with Rebecca Murphey, and she described this as:

“Things don’t do things - things announce things”

She also advised to have the following question in mind when writing tests:

“Given this input, do I get this output?”

For more on testable JavaScript, I recommend starting with Rebecca’s A List Apart article.

Going forwards

So far we don’t have as much JavaScript code coverage as we would like, but with a little discipline we’ll eventually get to a place where we can be confident that our code is always working.

Improving our development cycle

2014-03-11T14:28:29+00:00 by Nick Boyce

I’ve been struggling to solve a problem for some time now. The agile (with a lower-case “a”) approach we use for software development and the long-term roadmaps we have as a business have always been too disconnected, but I never quite knew how to connect them.

Recently, inspired by a deeper understanding of the lean approaches, I think I’ve finally connected them together in these five steps. It’s still an emerging process, but I’m hopeful it will solve a number of problems.

Keep an inventory of hypotheses

We all have ideas for ways to improve the site. Some of them are bound to make a positive difference, others will make the site worse, and most will have no measurable effect at all.

We keep a spreadsheet of these ideas, documented as hypotheses (if I do x, y will happen), along with as much additional information as we have. This ideas backlog becomes our ammunition to improve the site. Importantly, these are not added to Basecamp, where the tasks live until they have been prioritised.

Establish themes

In order to prioritise the ideas backlog, I work with other managers to decide on a theme for each month. To establish the theme we might look at under-performing parts of the conversion funnel, goals in other parts of the business, tech roadmap etc.

Sometimes the theme might be very specific (increase percentage of framed products sold), or more generic (increase AOV or improve funnel conversion for search, product, cart, order complete).

Rallying the team around a focussed goal helps us dive deeper into interconnected ideas. We spend 60% of our development time working on tasks related to the theme, while the other 40% is reserved for fixing bugs, cost of doing business tasks, documentation, research etc.

Prioritise hypotheses around themes

Once the theme is established, we hold a workshop to prioritise the hypotheses from the backlog in the ways most likely to improve the target KPI.

These competing ideas will vary wildly in difficulty and will probably contradict each another. Using experiment mapping and PIE ranking we can prioritise these based on value.

Create tasks from prioritised hypotheses

Once priorities are established, tasks are added to the “Next up” or “Backlog” lists in Basecamp, along with the corresponding hypothesis. Depending on our level of confidence in the task, we may use a combination of data analysis, user testing and competitor analysis to research the best solution.

Tasks move through a Kanban-esque process through “In Progress” and “QA” through its lifecycle, collecting more and more information as it goes.

Validate hypothesis

Once in “QA”, a combination of user testing and split testing will be used to validate or invalidate our hypothesis.

Minor variations will take a long time to reach statistical confidence, so we only split test meaningful changes. We always agree on the measure of success upfront, but also cross-check side-effects with Analytics segments.

Once a conclusion is reached, the task is marked as complete, links to the task/discussion/tests added to the spreadsheet before it’s moved to a “completed tests” sheet, and annotations added to Analytics for before-and-after analysis.

With each test, we increase our shared understanding of what our customers want, which in turn generates high quality ideas for future testing.

A somewhat better auto-complete (part 2)

2014-02-17T09:55:52+00:00 by John Pash

This is part 2 of a post which tries to explain a method of enhancing an auto-complete search box to act in a similar way to the Google search box. » Read part one here «

A solution

Something that would work perfectly for this style of query would be to use a regular expression query with a lookahead assertion.

But wait, MySQL doesn’t support look(ahead|behind) assertions!, I hear you say. That’s ok, we’ll do it the hard way, in code.

The query

First we need to mangle the input into a query that will get us most of the way using plain old sql. For example, if the user enters the string pcr (perhaps looking for the print category report), we want to end up with the following:

select * from admin_pages where (
    page_description like '%p%' and 
    page_description like '%c%' and 
    page_description like '%r%' )

This will return all pages that have every one of those letters in the description in alphabetical order.

/admin/print_categories.php
/admin/product_sales_report.php
/admin/supplier_stocked_item_report.php

But there’s a problem. The ordering of letters matters. We only want pages that contain a p followed by 0 or more letters, then a c followed by 0 or more letters, followed by an r. No matter, this will at least give us something to start with. It’s better than stuffing the entire database table into memory for searching.

The code that constructs this query is below (I’ve removed any security/sanitisation code to avoid cluttering up the example.):

<?php
function page_desc_sql($s) {
    return "page_description like '%{$s}%'";
}

// a-z only please...
$query = preg_replace("/[^a-z]/", "", strtolower($_GET["q"]));

// build query
$s = implode(" and ", array_map("page_desc_sql", str_split($query)));

$sql = "
    select
        page_id,
        page_name,
        page_description
    from
        admin_pages
    where
        ({$s})
    order by page_description asc
";
?>

So now we have a list of pages ready to process. Let’s create that lookahead expression.

<?php
function page_regex($x) {
    return "(?={$x}).*";
}
$regex = "/" . implode(array_map("page_regex", str_split($query))) . "/i";
?>

This sets $regex to the string:
/(?=p).*(?=c).*(?=r).*/i

The final piece of the puzzle is to take the results and pass them through this regex, only returning the ones that match. Then output some json for the auto-complete to use.

<?php
    while ($q->next_record()) {
        $x = $q->get_row();

        if (preg_match($regex, $x["page_description"])) {
            $x["page_id"] = (int)$x["page_id"]; // Cast integer for json
            $x["url"] = realpath(SECURE_WEB_SERVER_URL) . $x["url"];
            $data[] = $x;
        }
    }

    header('Content-type: application/json; charset=iso-8859-1');
    echo json_encode($data);
}
?>

Introducing Lean UX at Easyart

2014-02-16T22:19:31+00:00 by Nick Boyce

There is something of a revolution underway in the way that we approach user experience at Easyart. With Agile processes so important to the way we build software, we felt we were ready to implement Lean UX approaches to help solve some of our user experience problems. It’s early days but I thought I would share some of the things that have worked for us so far.

Note: I’ve added some notes on this to the tech handbook which is emerging at the moment, but I thought I would elaborate on some of the processes in this post.

Agree on outcomes before deciding on features

By starting with a KPI we want to affect, we can develop hypotheses which we believe will help us reach that goal, and have a clear-cut way of measuring success.

Use personas to guide decisions

Focussing on user needs helps us build a more human experience so we have developed three personas which we can use to step through different on-site journeys.

Shared understanding and hypotheses over design heroes

Getting stakeholders involved in the conception of ideas builds a shared understanding, which is invaluable for collaborating across departments and skill-sets. We’ve had some success with gut test exercises when working on new homepage visual design, group sketching design studio exercises to improve navigation and card sorting to agree on priorities.

Use the live styleguide to build pages from modules

Changing from a page-based approach to a component-based approach allows everyone to sketch pages, and our live style guide is the directory of available modules.

Validate as early as possible

Our opinions are not as important as customer feedback, so we try to validate our hypotheses as early as possible. We use Usertesting.com for user testing, and Optimizely for split testing.

We’re at the formative stages of this process at the moment, but I’m hopeful it’s going to make a big difference.

Consuming Wordpress as a service

2014-01-17T16:04:10+00:00 by Steve Fuller

Our Wordpress blog is a useful tool for publishing marketing information and one we wanted to keep in our new site as it provides useful information for customers as well as helping to keep the content of the site fresh.

We didn’t necessarily want all the features of Wordpress so beloved of developers the world over, just the content posts, assets and a means of querying the different categories we’d set up.

We used the JSON_API plugin to do the job. It installs into a wordpress instance and exposes a number of REST methods allowing our rails controller to fetch and parse the blog content efficiently (caching it for performance). The plugin doesn’t include any authentication options but if you only enable the get methods it’s no more public than a hosted Wordpress site.

There were a few small customizations to Wordpress we added - essentially to disable frontend access so that the content only appears in the context of our main website. Splitting the content management off into a separate service like this both fits with the SOA structure of Easyart and means our editors can add and edit content without affecting anything that might be happening on the rest of the platform.

Adding dependencies to your ruby gem

2014-01-03T09:43:45+00:00 by Steve Rydz

A couple of days ago I wrote about turning your CSS into a ruby gem. Since then my colleague John suggested that I add Bourbon and Neat as dependencies, as the SCSS included in the gem will not work without them.

So, once again I was faced with a new challenge - and once again it turned out to be fairly simple in the end.

I won’t go into details about the different kinds of dependencies you can use in a gem, the rubygems guide does a better job of that than I would, but the process is the same either way.

In your <gem name>.gemspec file, you just need to add the following:

    spec.add_dependency "bourbon", ">= 3.1.4"
    spec.add_dependency "neat", ">= 1.3.0"

Obviously the name and version number of the gems you include here will be whatever you are using on your project.

The next, and final step is to go to lib/<gem name>.rb and require your dependencies at the top of the file, underneath your <gem name>/version require statement:

    require "bourbon"
    require "neat"

And that’s it. Next time you (or someone else) uses your gem, the dependencies will be installed without having to include them separately.

Turn your CSS into a ruby gem

2013-12-31T11:26:25+00:00 by Steve Rydz

In our never-ending mission to make our codebase more maintainable, we decided to package up our shared CSS into a gem so we can use it on all of our projects easily, without having to worry about things going out of sync.

This seemed daunting to me, as I’d never done anything like this before, but after some reading and googling, I found it wasn’t actually that complicated. Here’s how I did it:

What you’ll need

Ensure rubygems is up to date by running gem update --system from your terminal
Install bundler by running gem install bundler
A github repo for the gem
An account on Rubygems

Creating the gem

Note: I’ve called my gem craven, so wherever you see this, you should replace it with the name of your gem.

You can use bundler to create the scaffolding for your gem. All you have to do is run:

    bundle gem craven

Believe it or not, this is almost good-to-go, but we need to do a small amount of config first.

Open the file craven/lib/craven.rb and edit it so it looks like this:

    require "craven/version"

    module Craven
        class Engine < Rails::Engine
        end
    end

Now open the file craven/craven.gemspec and fill out any sections containing TODO:. I also set the homepage to my github repo:

    spec.homepage = "http://github.com/easyart/craven

Adding your assets

Now you can add your assets to the gem. Assuming your assets are intended to be used as a library, you should use the vendor directory structure, so all your stylesheets are included in craven/vendor/assets/stylesheets/craven/.

Bumping the version number

Now you are almost ready to publish your gem, but each time you do, you will need to bump up the version of your gem, otherwise it will fail. You can do this in craven/lib/craven/version.rb.

Publishing the gem

Now for the exciting part - you’re about to publish your first ruby gem. To do this, just run:

    bundle exec rake release

This will publish the gem and push your changed to github. The first time you do this you will be prompted to fill out some credentials. From then on, all you will have to do is run the above command to publish changes to your gem.

Welcoming Steve Fuller

2013-11-24T22:57:45+00:00 by Nick Boyce

We’re excited to welcome Steve Fuller to the Easyart tech team, as a result of our acquisition of assets from Picture Cabinet Ltd. Steve was responsible for building Picture Cabinet’s platform that powers a large number of print on demand sites, apps and kiosks and will undoubtably be a valuable addition to the team.

A somewhat better auto-complete

2013-11-12T17:37:22+00:00 by John Pash

Summary

Known by many names; the auto-complete, typeahead, search suggestion or incremental search box is an invaluable feature of any website. An example of it’s use would be to find the latest news about Lance Armstrong. If you Google only the partial words “lan” and “arm” Google will be smart enough to fill in the blanks.

The project

The project I’m about to explain was done for an internal administration menu here at Easyart.

Over the years our admin has grown so large that a simple list of pages was simply too long to navigate. Even after grouping and hiding them under dropdown menus we thought there must be a quicker way of getting to a specific page.

An auto-complete input field would fit the bill.

A typical auto-complete setup

A typical setup might use Twitter’s Typeahead library which does an ajax call to a server which receives the partial search term and returns matching records. The results are displayed in real-time as a list of options and are updated on each keypress.

But there’s a problem

Firstly, you need to know the exact spelling of the words you are after. Many auto-complete libraries search from the beginning of words. If you miszpel your target term, you are out of luck. Good luck to sports writers wanting to find Jhonny Peralta’s batting average on your Dominican Major League baseball blog.

Also, if you have many records that start with the same phrase, and your auto-complete only shows the top 10, how do you find the one that you know is there but is hidden at number 15?

A better way to search

If you’ve ever used the Sublime Text editor you’ll be familiar with the “search anywhere” paradigm. To find a file, normally you would go to the search box and type filename.txt, then hit search, then off it would go to hunt down your file. But with “search anywhere” you can find what you want in a fraction of the time.

For example, to search the Rails source code for the file “active_record_callbacks.rb” you could type:

“arb” which matches “active_record_callbacks.rb”
“reccall” which matches “active_record_callbacks.rb”
“arec” which matches “active_record_callbacks.rb”

There are only two rules:

All letters must be in the name of the item (obviously)
Letters must appear in the correct order

So how do we do this in code?

The typical auto-complete setup will take the input and (after sanitising of course) ask the database with a “like” query to find matches.

select * from table_name where description like "%QUERY%";

This does an ok job, but it’s not perfect. It’s just not as flexible or fast as it could be.

Our solution

Positive zero-length lookahead assertions of course!

Come back for Part Two of this post for the code.

Setting Up Google Tag Manager with Optimizely

2013-10-16T14:07:47+00:00 by John Pash

Summary

We’ve recently moved over to using Google Tag Manager (GTM) on the redesign of Worldgallery. The promise of being able to “update your website tags…without bugging the IT folks.” was too hard to pass up. The reality of GTM, however, has proven to be something all together different.

We also use Optimizely quite heavily on the new site. And the easy integration with Google Analytics(GA) via Custom Variables mean that we can easily segment the Optimizely visitors by buckets. For instance, we can run a report that gives us “Ecommerce value of all visitors who saw Version A of the checkout page” or “Time on page for visitors who saw Version B of a certain landing page”. This greatly enhances the default reporting from Optimizely.

The Problem

Now that Google Tag Manager is responsible for loading all javascript on the page, we need to be sure that they get executed in the correct order. And that order is 1) Optimizely followed by 2) Google Analytics

By default, GTM does what it does as and when it sees fit. So we can’t be sure that the tags will fire as needed. However the fix for this particular problem has already been solved.

In a nutshell:

Load the Optimizely code in a GTM Custom HTML Tag.
Then set a dataLayer variable in that tag which says “OK - Ready to go”
That then triggers the GA pageview to fire. Simple!

But that wasn’t enough to make it work…

Yes, we could fire the GA pageview at the right time - after Optimizely has done it’s thing. But for some reason the Custom Variables still weren’t being sent along with the request.

The Solution

Fast forward about 30 hours of head-scratching and a large handful of experiments. When finally the missing piece of the puzzle was found.

There is a poorly documented feature of GTM for the Tracker Name setting. Reading this would lead one to believe that all this setting does is allow you to “name the tracker object yourself”.

What isn’t mentioned is that by turning on this setting (which can be found under Advanced Settings for the Page View tag) you effectively make the tracker name public. This is your UA-XXXXXX-X number. Without this information Optimizely is not able to set the Custom Variable correctly.

Conclusion

If you use Google Tag Manager along with Optimizely and want to take advantage of Google Analytics Custom Variable segmentation - pause for breath - then you need to:

Tick the box next Tracker Name under Advanced Settings (but don’t fill anything in the text box!)
Follow these instructions to ensure the correct load order of scripts
GOTO PUB

On technical debt, complexity and opportunity cost

2013-10-12T14:57:13+00:00 by Nick Boyce

In reading What CTOs Fear Most, it’s clear that managing priorities is a common fear amongst technical managers.

The Easyart technical team is in the midst of redeveloping a platform that has been running for well over a decade, we are continually faced with difficult decisions about what features are worth migrating, and how they compete for resources with new features.

In our circumstance, retaining a feature is actually a new development task which is competing with every other task. Most of the existing features are there for good reason, but it’s worth challeging the idea that every old feature is going to have more business value than the new features they are competing with.

Just because we can, it doesn’t mean we should. Just because a feature exists, removing it doesn’t necessarily make the product poorer. This point of view can be unpopular but the opportunity to shed some technical debt and rationalise our offering can make the hard work worthwhile.

Julie Zhuo, Product design director at Facebook makes the point well in her fantastic blog post The Tax of New (paraphrased here):

Run that line of thinking too many times and you get death by a thousand paper cuts. This is how good, simple products become quite the opposite.

The tax that comes with introducing any new feature into your product is high. I cannot stress this enough. Sure, maybe the new feature isn’t hard to build, maybe it only takes a couple days and a handful of people, maybe it can be shipped and delivered by next week.

Perhaps you will continue to develop and evolve it. Even if you don’t (maybe your plan was just to launch it and move on), the fact of its existence will inevitably create more work for you. You will get user requests and bugs about it. You will spend time thinking idly about ways to make it better. It will likely pop up in the context of your next redesign or code rearchitecture.

Another great article on the topic by Yammer’s CTO, Kris Gale, on technical debt and complexity:

For years, the two things that most frustrated me to hear from product managers were “how hard would it be…” and “can’t you just…” It took me quite a while to figure out why I had such a strong, visceral reaction to these phrases. The answer seems obvious now: The work of implementing a feature initially is often a tiny fraction of the work to support that feature over the lifetime of a product, and yes, we can “just” code any logic someone dreams up. What might take two weeks right now adds a marginal cost to every engineering project we’ll take on in this product in the future. In fact, I’d argue that the initial time spent implementing a feature is one of the least interesting data points to consider when weighing the cost and benefit of a feature.

And this brilliant rant by Des Traynor argues that there is simply no such thing as a small change:

Agreeing to features is deceptively easy. Coding them rarely is. Maintaining them can be a nightmare. When you’re striving for quality, there are no small changes.

When you release a feature it’s not the end of the job, it’s just the beginning!

Thankfully none of this means we should avoid new ideas or innovation, we just need to put some process around our decisions to ensure that new features are providing value, not just technical debt.

For existing features, study the data. If this feature is providing real business value, it’s worth retaining and developing further. If not, consider removing it.

For new features, it’s important to define success criteria upfront. If the feature doesn’t meet the measure of success you’ve defined, remove it. And if it does, we know the debt is worth taking on. Ideally these metrics should be published so that later down the line when someone asks “why do we have this feature”, there is an answer to point to.

Adding these processes requires great discipline, but it provides a confidence that every new feature is providing real value to the company.

Update: some discussion on Hacker News

Launching Kubrick, part 1

2013-08-20T12:45:14+00:00 by Nick Boyce

After a period of beta testing, user testing and painful analysis, last week we migrated WorldGallery.co.uk to Kubrick, the new platform we’ve been working on in the London office. Kubrick’s primary objectives are textbook e-commerce, but the technology and processes are a bit more interesting (which I will write about later)

Improving conversion rate

When you have a product catalogue as extensive as WorldGallery, it’s a challenge to help users find the product they want to find. I think this is particularly true of art products which are often difficult to categories.

The primary focus has been a new category structure, and adding the capability for users to navigate directly to artwork, artist or category pages via a new search auto-suggest feature. The result is a more curated user experience.

Key tech: Rails, Sinatra, ElasticSearch, JSON

Improving AOV

We have a massive range of frames and a brilliant team of master framers, and frankly we need to do a better job of getting our customers interested in frames. To do this, we’ve integrated framing directly into the main product page and made it near-instantaneous to navigate between various types of unframed, canvas or framed products.

Key tech: Backbone, JSON

Increase traffic

We’ve vastly simplified the structure of the site (focussing on artworks, categories, artists and artworks), resulting in one authoritative URL for each page (rather than rewrites which can result in multiple URLs for a single entity).

For example, the “Modern Art” category used to be available via a number of URLs like these:

/mt/Modern-Art-Prints-51-2.html‎
/category/modern-modern-59.html‎

All of these should now redirect to the one “true” modern art category: /art-prints/modern-art. This is better for users and better for Google.

Key tech: Rails, Rack::Rewrite

We also had some secondary goals in this development:

Make the site mobile-friendly for the 25% (and rising) of users that access our sites on tablets or mobile
Improve engagement (measured in time on site, number of page views and return visits)
Improved monitoring
Automated testing on everything
Increased speed of development

We’re already seeing some positive results and look forward to migrating some of our other sites over.

A Decision Journal

2013-08-11T13:09:37+00:00 by Nick Boyce

Nobel Laureate Daniel Kahneman:

Somewhat surprisingly, few organizations keep track of what’s decided and why.

This seems idiotic when you consider that often thousands of dollars are spent making a decision. Of the few that do keep track of decisions, fewer will be honest about what’s actually discussed.

This one of the reasons I think it’s worth spending work hours blogging. To distill ideas and decisions and share them with the organisation and your peers.

Via the wonderful Farnam Street.

Design For Disaster and other interesting links

2013-08-04T15:16:38+00:00 by Nick Boyce

Steve brought Jeffrey Veen’s Design For Disaster talk to my attention last week and I’m still thinking about it.

Veen is a real veteran of the web and an impressive storyteller. In this talk he recounts a specific disaster in Typekit’s history, and how procedures set up before and after, as well as parts of the company culture had an effect on its outcome.

Some more bits and pieces I’ve enjoyed recently:

In Lieu of Money, Toyota Donates Efficiency to New York Charity
Shipping beats perfection. Be open. Share your work. Anybody can fix anything. Development philosophy at Khan Academy.
108 Years of Herman Miller (in 108 Seconds)
There’s nothing like a tidy codebase
HTTP logic tree, illustrated
“I’m adding a meeting” should really be “I’m subtracting an hour from your life.”
“42 Rules to Lead by from the Man Who Defined Google’s Product Strategy”
“The Secret to Your Success? Make Others Successful”

Heroku Fork

2013-07-24T22:04:28+00:00 by Nick Boyce

I’ve been meaning to try the fork feature on Heroku for a while.

It does exactly what you expect, but that’s what’s so brilliant about it. It’s taken be less than 2 minutes to set up a staging environment for one of our apps in the EU region. Here’s what’s involved:

Clone an existing app, optionally choosing a region. This will also add your add-ons to the forked app at the same payment tier so keep an eye out for this.

heroku fork -a yourapp yourapp-staging --region eu

Creating fork yourapp-staging... done
Copying slug... done
Adding airbrake:developer... done
Adding memcachier:100... done
Adding scheduler:standard... done
Copying config vars... done
Fork complete, view it at http://yourapp-staging.herokuapp.com/

Get the forked app’s Git repo information so you can push code to it.

heroku info -a yourapp-staging

=== yourapp-staging
Addons:        memcachier:dev
               scheduler:standard

Git URL:       git@heroku.com:yourapp-staging.git
Owner Email:   nick@nickboyce.com
Region:        eu
Stack:         cedar
Tier:          Legacy
Web URL:       http://yourapp-staging.herokuapp.com/

Add a new git remote so you can push to the new app.

git remote add staging git@heroku.com:yourapp-staging.git

Push a branch to your new app.

git push staging custom-framing:master

You’re done!

Lazy loading Facebook buttons

2013-07-12T16:13:45+00:00 by Steve Rydz

We recently did the WordPress work for the Art Everywhere project, and one of the requirements of the project was to include a Facebook like button for each artwork on the Choose Artworks page.

That page has around 100 artworks on it so immediately I heard alarm bells, until I remembered the Socialite plugin. This allows you to lazy-loading the Facebook buttons.

No matter what, we didn’t want all of those Facebook buttons to load at the same time, even if the rest of the page had already loaded, so we decided we would load them in on hover.

Initially we struggled to get this working how we wanted, as all the buttons would load when you hovered over any of the buttons. Finally Nick found the solution:

$(".artwork-info").hover(function () {
    Socialite.load(this);
});

It turns out, all we had to do was pass this to the Socialite.load function. So, if ever you find yourself having to implement similar functionality, you know what to do.

Some wisdom from Adam Wiggins

2013-06-02T16:04:53+00:00 by Nick Boyce

This week Adam Wiggins announced that he has stepped down as CTO of Heroku to pursue other opportunities.

At Easyart we’re big fans of Heroku (it’s used extensively for our new platform), and Adam’s general approach to modern web software design, so I thought it might be a good opportunity to review some of his nuggets of wisdom.

The Twelve-Factor App

A manifesto for modern web software design and the principles. It’s clearly the concepts from which the Heroku ecosystem is formed, but the principles can be applied to any modern web application platform stack.

My Heroku Values

A few bits and pieces from this post:

Make it real. Ideas are cheap. Make a prototype, sketch a CLI session, draw a wireframe. Discussions around concrete examples, not handy-waving abstractions. Don’t say you did something, provide a URL that proves it.

Ship it. Nothing is real until it’s being used by a real user. This doesn’t mean you make a prototype in the morning and blog about it in the evening. It means you find one person you believe your product will help and try to get them to use it.

Divide and conqueor. Big, hard problems become easy if you cut them into small pieces. How do you eat the elephant? One bite at a time. If a problems seems hard, think about how you can cut it into two smaller, easier problems. If one of those problems is still too hard, cut it in half again.

Throw things away. It’s not the code that is valuable, it’s the understanding you’ve gained from building it.

Decision-making via ownership, not consensus or authority. Every product, feature, software component, web page, business deal, blog post, and so on should have a single owner. Many people may collaborate on it, but the owner is “the buck stops here” and makes the final call on what happens with the owned thing.

It will be interesting to see what he turns his hand to next.

JSONAPI.org

2013-05-05T14:00:34+00:00 by Nick Boyce

I was interested to see jsonapi.org spring up on the web recently. Though it’s authored by Ember’s team, the references to Ember have been moved from the homepage to the history section, and it’s clear that the ambition is to set a standard for API compatibility between servers and clients.

Overall I applaud the ambition and it’s clearly written by clever people. That said, I believe consuming the proposed data structures is more complicated unless you’re using a compatible library.

Consider these examples…

If the value of a resource key is a JSON object, the value represents a single document. If the value of a resource key is a JSON array, the value represents a list of documents.

Isn’t it better to have the URL scheme define if you are looking at a document or collection? i.e. GET /resource is a collection and GET /resource/document is a document?

To save HTTP requests, it may be convenient to send related documents along with the requested documents.

For example:

{
  "posts": [{
    "id": "1",
    "title": "Rails is Omakase",
    "rels": {
      "author": 9
    }
  }],
  "people": [{
    "id": "9",
    "name": "@d2h"
  }]
}

So to list the post title and author name would be something like (pseudo code):

{posts.each (post)}
  {post.title} by {people.where(id: post.rels.author).name}
{end}

Now, that’s pseudo-code, and in reality it would depend on what language or framework you are using as to how easy that “where” statement is. It’s definitely going to be a lot more complicated than my example to do it in vanilla JavaScript. I’d suggest that nesting the documents is much easier:

{
  "posts": [{
    "id": "1",
    "title": "Rails is Omakase",
    "author": {
      "id": "9",
      "name": "@d2h"
    }
  }]
}

And it can be consumed like this:

{posts.each (post)}
  {post.title} by {post.author.name}
{end}

Yes, it’s imperfect and can result in more duplication and less flexibility, but I think for a lot of cases that isn’t an issue.

Notes from Industry Conference

2013-04-29T10:06:25+00:00 by Steve Rydz

Last week I attended Industry, organised by Gavin Elliott. I must say Gavin did a great job and it was a great conference. Here are my notes from the talks:

Rachel Andrew - “All of a sudden… no luck!” Things we have learned while supporting Perch.

Slides

There were some good points this talk, such as how email doesn’t scale well for support and how important it is to add features that benefit the majority of your customers, not the noisy minority. Also, Rachel described how engagement with customers makes it easier to determine what you should be doing. Essentially, customer support is your best source of market research.

This led me to think that as well as user testing, we should be engaging more with our customer services team to determine where we can improve things for our customers.

Harry Roberts - Architecting scalable CSS

Slides

I was looking forward to this talk as I am in the early stages of putting together the CSS for our new platform. Harry addressed a lot of things I have been thinking about recently.

He talked about breaking code into the smallest possible blocks, and how each block should do one thing well. Blocks can then be combined if needed. A great methodology for this is BEM which stands for Block-Element-Modifier. I also liked the idea of a shame.css file for hacks and quick fixes.

Christopher Murphy - We are navigators

This talk focused on the importance of education in the industry and how important our mentors can be.

Ashley Baxter - Changing a stagnant industry

I wasn’t really sure what to expect from this talk, and it was hard to believe this was Ashley’s first time speaking at a conference.

Ashley clearly has a lot of drive and has achieved some amazing things purely because she is passionate about what she does. I guess the main take away from this is not to let anything stand in your way and if you don’t like the way something is, don’t complain about it, make it better.

Noah Stokes - $50'000 mistakes

Noah has had quite an impressive career, working at Apple and also turning down job offers from the likes of Google, but it hasn’t all been a smooth ride. His story shows that with hard work and dedication, you can achieve anything.

Rasika Krishna - Cross-cultural UX

I’ve had my fair share of working on sites for other cultures. I’ve worked on Arabic, Chinese and Russian sites before and at Easyart we have French, German and Swedish sites as well as our UK ones, but it was really interesting to hear about how different other cultures can be.

I couldn’t agree more with Rasika’s point about it not being enough just running some text through Google Translate or switching the text-direction. I was also surprised to learn that in Malaysia, you need Government sign-off before launching a website.

Josh Brewer - Redesigning Twitter

Josh talked us through the most recent redesign of Twitter and the challenges they faced. There were a few takeaways from this talk, such as the importance of scaling features to meet a deadline, iterating in code early on in the design process and using version control for your PSD’s for collaboration (for this Josh recommended SVN as it handles binary files better than Git).

Jeremy Keith - What we talk about when we talk about the web

Jeremy raised some great points in this talk, some of which we really shouldn’t need to be told anymore, but it was a great overview of how the web works and what we can do to make it better.

The idea that the web is its own medium resounded with me, and that we should not be trying to replicate print. Jeremy also reminded us all about progressive enhancement and how it does not mean designing for the lowest common denominator. The principles behind progressive enhancement and mobile-first go hand-in-hand.

Making Ideas Happen

2013-04-25T10:14:16+00:00 by Nick Boyce

A couple of years ago I had the pleasure of seeing Scott Belsky (of Behance and now Adobe fame speak about his book Making Ideas Happen at the Like Minds Business Book Club).

It’s a fantastic book which celebrates some of the things I value most - collaboration, creativity and getting things done! Here are my some of the passages I highlighted on my Kindle.

On collaboration and creative process

…among the hundreds of successful creatives I’ve interviewed, a fearless approach to sharing ideas is one of the most common attributes. Why? Because having the idea is just one tiny step along the road to making that idea happen.

Regardless of where you are in your career—and what stage your ideas are in—you should not only accept feedback, you should seek it out. Managers, coworkers, and clients have a responsibility to share feedback, and you should encourage them to do so.

“The genius sketch is a myth. Architecture is made by a team of committed people who work together… . Success usually has more to do with dumb determination than with genius.”

…people thrive when their judgment and autonomy are respected.

As you cultivate your team’s immune system, you will want to differentiate between skeptics and cynics.

Share Ownership of Your Ideas The more people who lie awake in bed thinking about your idea, the better. But people only obsess about ideas when they feel a sense of ownership.

Collaboration brings small sparks together to generate breakthrough innovation.

Harvard Business Review cited a recent MIT study showing that employees with the most extensive personal online networks were 7 percent more productive than their colleagues, and those with the most cohesive face-to-face networks were 30 percent more productive. Clearly, our respective communities—both online and offline—play a critical role in helping us refine our ideas, stay focused, and execute to completion.

Have a Tempered Tolerance for Change

…intersection of creative energy and organizational prowess where great ideas become actions and ultimately revolutionary achievements.

On getting things done

…successful creative entity must be comfortable alternating between these two creative phases: ideation and execution.

The way you organize projects, prioritize, and manage your energy is arguably more important than the quality of the ideas you wish to pursue.

Accountability, one of the most crucial benefits of engaging with your community, is what binds you to the relentless pursuit of your ideas.

Action Steps are specific things you must do to move an idea forward. The more clear and concrete an Action Step is, the less friction you will encounter trying to do it. If an Action Step is vague or complicated, you will probably skip over it to others on your list that are more straightforward. To avoid this, start each Action Step with a verb: Call programmer to discuss … Install new software for … Research the possibility of … Mock up a sample of the … Update XYZ document for … Address issue of …

An unowned Action Step will never be taken. Every Action Step must be owned by a single person. While some Action Steps may involve the input of different people, accountability must reside in one individual’s hands at the end of the day.

Aside from friendly questioning along the lines of “Did you capture that?” some teams take a few minutes at the end of every meeting to go around the table and allow each person to recite the Action Steps that he or she captured.

Actions are truly “delegated” only when they are accepted. Regardless of your method for managing Action Steps, it is vital that you (and your project partners) never accept an Action Step unless it is clear and able to be executed.

…minimize (or quit) all communication applications during certain periods of your day.

Constant motion is the key to execution.

Constraints serve as kindling for execution. When you’re not given constraints, you must seek them.

Especially amidst heavy, burdensome projects with hundreds of Action Steps and milestones, it is emotionally invigorating to surround yourself with progress. Why throw away the evidence of your achievements when you can create an inspiring monument to getting stuff done? When you make incremental progress, celebrate it and feature it. Surround yourself with it.

And this fantastic quote from British author A. A. Milne

“Good judgment comes from experience, and experience—well, that comes from poor judgment.”

Transitioning to Bourbon

2013-04-22T11:01:48+00:00 by Steve Rydz

With the project we’re currently working on, I was tasked with taking the lead on the front-end side of things. Previously we used Bootstrap, with our styles applied on top, but this was no longer a good fit for a number of reasons:

Large amounts of unused CSS
Components had to be overwritten to fit our designs
The grid system wasn’t particularly flexible

My gut feel was that we need our own framework, but before we went down that road, I took a look at some other options.

At one point we tried Foundation, mainly because the grid system seemed to be quite clever, but there were a number of reasons why that also didn’t work:

Once again, large amounts of unused CSS
Changing font sizes altered the grid system
Browser support doesn’t reach back as far as we need it to

I decided to piece together our own framework, but to save time I wanted a reliable and flexible grid system, oh, and it had to be twelve columns.

After trying out numerous pre-built grid systems and finding none of them worked as we wanted, I was ready to give up and build it myself, until my colleague Nick discovered Neat.

Neat is the grid system that accompanies Bourbon, a solid collection of Sass mixins and utilities. After trying it out for an hour or so, I decided this was what we needed.

The great thing about using bourbon and neat is that only the styles we are actually using will be included in our compiled CSS, and we can also easily use our own classes keeping both our HTML and CSS as clean as possible from presentational class names.

I was now ready to piece together our framework. I already had some styles which were a mix of our own global styles, some bootstrap components (alerts, wells, labels etc), and a few other bits and pieces. These are now kept in their own github repo, and will be included as a git submodule going forward.

Here is a broad outline of how we now structure our CSS:

Bourbon: Up-to-date CSS3 mixins
Neat: Stable and flexible grid system
Config: Variables to customize aspects of each site
Craven: Collection of styles inc. normalize, bootstrap components and global styles
Site specific: Any styles specific to each site

So far we’ve found this to be a maintainable way to structure our CSS, and we’re hoping once we port it across all of our sites it will continue to be so.

Why don't other industries use version control?

2013-04-21T12:40:10+00:00 by Nick Boyce

It’s easy to take version control for granted when you work in software development as it’s such an integral part of the process. But it’s virtually non-existent in other technical industries.

Recently, when Github launched their new online STL viewer, I asked some friends who work with product and game design if they used version control for their source files. These are a few (edited) parts of that conversation.

Product designer 1: What is a version control for my source files?

Product designer 2: I think he means some way of ensuring that everyone is looking / working on the latest file?

Game designer: Version control can be hella hard for some people to understand… like their mind breaks when it’s explained to them.

Product designer 2: Well, all the major 3D / 2D design packages - especially the parametric ones - do this in some form. Although it’s all controlled by the software. The packages are expensive and generally these part management components add to the price.

Product designer 1: We’ve never used these tools at (redacted - major Australian electrical manufacturer) it would be so difficult to get our factories to abide by the procedures. Generally you just run an assembly and swap out old parts for new as it develops. Pretty sure the engineering departments at (redacted - major European electrical manufacturer) had a dedicated admin guy who would administer the 3D files. BEST JOB EVER."

There are a number of companies that are trying to solve this problem for designers (like Pixelapse, LayerVault and Beanstalk via their design preview feature), but that’s just really scratching the surface. I can’t help but think that the benefits that would be a massive if there was a meaningful (and non-proprietary) way to incorporate version control into more development processes.

Easyart-flavoured agile

2013-04-16T12:41:43+00:00 by Nick Boyce

We decided to try out kanban/agile for the development of our new Kubrick platform. None of the team had much experience with agile and we all agreed from the beginning that we didn’t want to take a strict approach to it, but would like to try it out and see how it fits with us. This is what we ended up with.

The board

Our board has columns for Icebox (someday), backlog (someday soon), todo (next two weeks), in progress (now), QA (done but needs review) and done.

We use actual, real post-its. This has numerous positive side-effects: visibility of progress throughout the office, avoiding more software (we’re big Basecamp users here at Easyart), and taking pride in the “done” list. The negative aspects of this: no visibility on progress outside of the office (we have offices in London and Newhaven, and some staff working from home), no ability to comment or add details to the task and of course the questionable legibility of my handwriting.

Action tickets are either small (pink, ¼ day) or medium (yellow ½ day) tasks. Anything longer than that needs to be broken down or to become a discovery ticket. Discovery tickets (green, no time allocated) help us keep an eye on the more mysterious parts of the project, or various technologies, refactors or improvements that could be useful for us. They can usually be broken down either by workshopping the specific issue, or by spending 2 or so hours researching. Mostly they will spawn new action tickets, but sometimes the discovery is a dead-end.

Processes

We do daily stand ups at 9:15. We actually drag the whiteboard into the meeting room every day to have our stand-ups. I tend to waffle on, so these can sometimes run longer than 5 mins, but we do try to keep them short. These only happen Wed-Fri (which I’ll make the subject of another post).

No locked-in sprints. Being flexible about the amount of work in a sprint is very un-Agile and makes it difficult to measure the overall velocity and predict milestones, but so far that hasn’t been a massive issue.

Pair programming. This has been invaluable for us, both to increase our skills and share knowledge.

Weekly wraps. Stakeholders are invited to a recurring meeting every Friday at 4, where we demo the week’s progress. This is useful both for the team (who might not have been involved in each others' work) and the stakeholders (to get a clear sense of progress). It’s also usually paired with a well-earned beer and move the “done” tickets to the wall.

No user stories. Without user stories our process can hardly be called “agile”, but as we’re so far building a platform with no external customers we’re yet to find a place for user stories. I think in time we will.

What we still have to work out

Where does design and creative fit in?. I’ve found it challenging to work with design creative tasks within this process. Tasks like “design hero module for homepage” or “include links to related categories on product page” are fine, but we keep finding ourselves with tasks like “refactor homepage”, which is not very useful. So far I’m yet to find a compelling model for including design tasks in the agile workflow.

Git tricks

2013-03-01T13:45:40+00:00 by Nick Boyce

About a year or so ago, I started keeping notes of my most-used Git tricks. I still refer back to them as I am so terrible at remembering commands (particularly unintuitive ones like deleting remote branches), so I thought they might be useful for others too.

Keep git from tracking permission changes to files git config core.filemode false

Restore a branch to the remote version (i.e. if you have pulled an incorrect remote branch) git fetch git reset –hard origin/master

Restore a single file to a version on another branch git checkout branch_name path/to-file

Search for a string in the commit history: git show :/search_string

Amend the last commit message: git commit –amend -m “New commit message”

Toggle between branches git checkout -

colourise all git commands git config –global color.ui true

Use mergetool git mergetool -t opendiff

Delete a branch remotely git push origin :newfeature

Delete a branch locally git branch -d newfeature

Delete branches that don’t exist on remote git remote prune origin

This one is Github-specific: You can compare commit ranges by appending compare like so… compare/master…someotherbranch compare/master@{yesterday}…master compare/master@{2.days.ago}…master compare/master@{2012-05-01}…master

Links for the week

2013-02-17T21:07:40+00:00 by Nick Boyce

Unofficial documentation for the Tesla REST (ish) API. I never expected to see something like GET /vehicles/{id}/command/honk_horn in a car!
2013 trends in interactive design. Hint: mobile-first and bold, flat designs.
No more ‘mobile’. The term ‘mobile’ is as good as useless these days, so we may need some new terms to define what we actually mean.
A really long Scoble interview with the co-founders of Path. Some really interesting insights from seasoned technology veterans.
Design for continuous experimentation. Etsy’s Dan McKinley talks about some of the successes, failures and processes at Etsy.

And a quote on branding:

The consumer now appears to believe that the brand should earn its public attention the way all of us must. Say boring, repetitive stuff and you suffer the punishment that every bad conversationalist faces. First, we ignore you. Then, we exclude you.

Grant McCracken in the Harvard Business Review.

Links for the week

2013-02-10T12:08:35+00:00 by Nick Boyce

It’s been a busy week for the tech team at Easyart this week (more on that later), but I’ve got a backlog of some interesting links in my Evernote that I want to share.

The 90 day plan. We try to do quarterly plans here, but this has inspired me to do better.
Developer creates Github issues for his house.
Anil Dash: All dashboards should be feeds. I don’t entirely agree but he makes an interesting case.
Hessian is a pre-made brand, for sale for $18,000.
Multicolr Search Lab.

And this quote from Justin Kan’s article Experienced Hires Will Save You From Yourself:

My general rule of thumb at Exec has been that as a founder, you should do the first version of everything yourself. Build the first product, test the first sales channels. By doing things yourself, you can quickly discover if they will pay dividends (or if it is time to move on to the next experiment). Once you discover something worth doing, then hire a professional to come in and clean up the mess you’ve made.

Mobile continues to grow

2013-02-03T20:35:39+00:00 by Nick Boyce

Looking back some of our metrics for Easyart.com for 2012, this one stood out:

92% more mobile transactions YOY

Coupled with our responsive design and performance improvements (like improving our average page speed by 40%), we’ve also increased our mobile conversion rate significantly over 2012 and hope to see that trend continue in 2013.

Links This Week

2013-01-26T10:38:06+00:00 by Nick Boyce

Here’s some things that popped up on my radar this week:

Slideshow with 15 years of the Apple homepage
LayerVault have had a lovely redesign.
Abe Burmeister: How I Built A Fashion Brand With No Experience, Just Punk Rock Spirit (And The Web). Inspiring presentation on the story behind Outlier.
howdoi looks like a really useful way to get inline help in the terminal for a number of languages
Redesigning Google: how Larry Page engineered a beautiful revolution. An in-depth article on Google’s new focus on design.
Skinny Ties and responsive eCommerce. Case study on a responsive redesign of an ecommerce store.
Reminder: Design is still about words
The Great Discontent’s profile on Jessica Walsh. Surprisingly I’d never seen this site before, but I’ll definitely be keeping an eye on it.

I’ve also been making my way through some of the talks from last year’s Bacon conference. The three I have watched so far have all been top-notch:

Personality in Code

2013-01-25T15:03:54+00:00 by Nick Boyce

I liked this nice little post-install message from HTTParty:

Post-install message from httparty:
When you HTTParty, you must party hard!

Code can have personality too!

Front-end performance for web designers and front-end developers

2013-01-21T17:04:02+00:00 by Steve Rydz

I read a very thorough post on front-end performance earlier today by Harry Roberts of CSS Wizardry fame. If you are involved in front-end development then go read it:

Front-end performance for web designers and front-end developers

On SOA

2013-01-19T00:00:00+00:00 by Nick Boyce

I finally got around to reading Paul Dix’s Service-Oriented Design with Ruby and Rails over the new year break. Having worked on a number of services for a platform at my previous job, I was very familiar with the benefits (and drawbacks) of service-oriented architecture but it really concreted my understanding of what SOA could do for our organisation.

I’ve since been devouring articles on the topic, and have listed a few below that I have particularly enjoyed.

SOA for the Little Guys. This article does an amazing job of introducing SOA concepts right through to code examples.
Notes on Distributed Systems for Young Bloods. Hugely detailed post, with a focus on pitfalls of the SOA approach. Failure at some point in the system is inevitable.
Refactor Your Monolithic Rails App to a SOA (particularly slides 11-25)
Service Oriented Architecture at Square. A really interesting presentation from Square’s Chris Hunt on their SOA approach.
Abstracting Features Into Custom Reverse Proxies. Another video from Rubyconf on custom proxies to front and normalise multiple services.
Amazon Architecture. When you view a page on Amazon there are famously more than 100 services that are accessed to build it. This old post on the High Scalability blog outlines Amazon’s SOA approach.
Scalability Best Practices: Lessons from eBay. Detailed article on Ebay’s architecture from Randy Shoup.
LinkedIn Architecture. Outline of the evolution of LinkedIn from a monolithic app to a service-oriented approach. Slides are also available.

Links from the week

2013-01-10T00:00:00+00:00 by Nick Boyce

Thought it might be nice to start the year with a quote from from the Getting Real book:

There’s plenty of time to be a perfectionist. Just do it later.

Here’s a few links I’ve enjoyed over the new year break.

Enabling Lean with Tech: lessons learned applying lean at PayPal. An interesting slide deck from Bill Scott about how PayPal used a JavaScript-based stack and open source methodologies to set themselves free from their legacy technology stack and allow faster prototyping.
My Workflow: Never having to leave DevTools. Remy Sharp demonstrates some of the newer features of Webkit Inspector which allow much more deveklopment to happen inside the browser.
A Personal Annual Report. Jehiah Czebotar collected metrics about his activities throughout the year and presented an interesting report.
Building a Design-Driven Culture. Being design-driven means treating design as a partner (and a leader) in the product creation process. Look at your feature roadmap right now. Are there major initiatives and ideas that were generated directly from your designer or design team? If yes, was design in the room when the other items were created and prioritized? Congratulations, you’re design-driven.
The New York Times Skimmer looks like it’s had a significant upgrade since I last saw it. It’s a really impressive JavaScript front-end to the NYT content – complete with multiple themes and keyboard shortcuts – and by the looks of it, it’s also available bundled as a Chrome web app.

Using git flow

2013-01-09T15:46:43+00:00 by Steve Rydz

For the past couple of weeks I’ve been using a tool called Git Flow. In it’s own words, git flow is A collection of Git extensions to provide high-level repository operations for Vincent Driessen’s branching model.

If you’re already familiar with Git on the command line then getting up and running with git flow will take you no time at all.

Installation

The full installation instructions can be found here but for the purposes of this article I am going to assume you are on a Mac and using homebrew.

You can use homebrew to install git flow:

    $ brew install git-flow

That’s all it takes.

Initialising a project

To use git flow, you will need to already have a git project set up. So, to get started, just navigate to your project (in Terminal) and type the following:

    $ git flow init

It will then ask you a few questions regarding what to name your various branches. Unless you have good reason, I would stick to the defaults.

Going with the flow

So now you have initialised git flow within your project, you want to get going.

The assumption here is that your master branch is always deployable and your develop branch is where you would make small changes that will be release fairly quickly.

The feature I use most is feature branches. Essentially a branch called feature/ is created and when complete, merged into your develop branch. To start a new feature branch just type:

    $ git flow feature start <feature-name>

Obviously feature name will be whatever you want to call your new feature. You can then start working on your feature and commit as you normally would. To set up a remote branch so others can collaborate just use the publish command:

    $ git flow feature publish <feature-name>

Once you are ready to merge your new feature, just use the finish command:

    $ git flow feature finish <feature-name>

This will merge your feature into your develop branch and delete your local branch too. If you want/need to delete the remote branch then just type:

    $ git push origin :feature/<feature-name>

More resources

Hopefully this article has convinced you that using git flow is worthwhile and got you intrigued enough to find out more.

Some more git flow resources:

Is London the most popular city for Github users?

2012-12-20T00:00:00+00:00 by Nick Boyce

Interesting review of 2012 from Github in The Octoverse in 2012:

Since the beginning of the year, we’ve seen a doubling in activity, with pushes alone responsible for over 60% of the events in a given day. On a typical weekday, 10k people sign up for a GitHub account, and our users:

push 140GB of new data

create 25k repositories and 7k pull requests

push to 125k repositories

Best of all:

10k people create their very first repository

Apart from their impressive growth, this little fact caught my eye:

The top 10 countries visiting GitHub.com are: United States, Germany, United Kingdom, China, Japan, France, India, Canada, Russia and Brazil. The top 10 cities are: London, San Francisco, New York, Paris, Moscow, Beijing, Berlin, Bangalore, Sydney and Toronto.

London is the #1 city for Github users? Go London!

Why have I failed?

2012-12-19T00:00:00+00:00 by Nick Boyce

One of the things I most like about hacker culture is the acceptance (almost celebration) of failure as an essential part of a the path to success.

This post, and the accompanying discussion on Hacker News had a few quotes I really liked:

As soon as you believe you’re the smartest man in the room, you’re in the wrong room

And this one:

My job is not programming. My job is delivering value using programming.

Conventions

2012-12-13T00:00:00+00:00 by Nick Boyce

Part of the way the team has evolved this year has required putting more emphasis on consistent coding conventions and procedures to make our collaboration smoother. Here are a few notes.

Javascript

Google’s Javascript style guide, plus some JSHint config.

CSS/Less

Our own internal styleguide.

HTML

Our own internal styleguide.

Ruby

Nothing yet, but probably the Github Ruby Styleguide in the future.

Git branching

We use something vaguely between git-flow and “Github flow”. In essence, master is always deployable, develop is a shared staging branch, and feature branches are created for major or disruptive features. I could see us moving to git-flow next year.

Project naming

We decided to name our projects after film directors. So far Romero (our internal CSS framework), Kubrick (our next-generation platform in development) and Eastwood (an experimental Backbone-based product page) are active, but I am sure more will sprint to life in 2013.

It’s pretty lean so far, but we’re making refinements all the time.

This Week On The Interwebs

2012-12-07T00:00:00+00:00 by Nick Boyce

I’ve been enjoying the Art.sy engineering team’s blog. Their approach and technology stack are spookily similar to what we have in store for the next generation of the platform at Easyart. Even their blog runs on Jekyll just like this one!

As usual, I’ve spent a fair bit of time on Quora this week. The question What is Spotify’s architecture? had an interesting answer from Spotify developer Niklas Gustavsson. They have around 100 backend services, most of which handle only a single task.

Paul Irish’s Javascript Development Workflow of 2013 has a lot of good tips. Things are moving so quickly in this space it’s hard to keep up, so I find myself watching more and more presentations at home where I would have otherwise been watching TV.

HTTP Headers For Fun & Profit lists some interesting HTTP headers returned by popular sites.

There’s a great post called Why Google Went Offline Today and a Bit about How the Internet Works over on the CloudFlare blog from a while back that sheds some light on how some of the underlying mechanics of the internetw work.

The best interface is no interface is very much an approach we are trying to head towards with some of the product customisation screens we’ll launch in 2013. I’m really excited about what next year has in store.

Finally, this post is my first one created and edited in Prose. It’s a really neat tool to create and edit code in Github repos in the browser, and is perfectly suited to (infact, created for) Jekyll blogs like this one.

A prediction for 2013

2012-12-03T18:25:14+00:00 by Nick Boyce

A humble prediction:

Traffic to Easyart.com from 7" Android devices is going to have a noticeable bump after Christmas.

Google and Amazon are both pushing their tablet products hard this gifting season, and both have pretty compelling products at a great price point. Even I – a dedicated Apple nut – have just bought a Nexus, and I’m going to retire my first generation iPad to the giant eBay in the sky.

When the postman handed the package over, he said “all I am doing is delivering Googles”. That being the case, we’d better get our skates on and set some new breakpoints in our responsive CSS!

Working with Grunt

2012-11-27T10:54:10+00:00 by Steve Rydz

A few weeks ago I attended a series of tooling workshops in Brighton. One of the workshops was focused around build process, and particularly Grunt.

Currently we use CodeKit to compile our Less and JavaScript files so we end up with concatenated, minified versions of each. So far this has worked well but we have found it difficult to keep things synchronised between team members.

Soon after returning from the workshops I started to investigate Grunt in more detail and we put a plan in place on how we could use it to aid our build process.

What we came up with was the following file structure:

    Site_Name/
        |__ public/
        |           |__ static/
        |           |           |__ css/
        |           |           |__ js/
        |           |           |__ img/
        |           |
        |           |__ index.html
        |
        |__ spec/
        |
        |__ static-src/
        |           |__ less/
        |           |__ js/
        |
        |__ grunt.js
        |__ README.md

public

The public directory contains anything public facing, including all static assets such as stylesheets, scripts and images. Anything in the static/css/ and static/js/ directories is compiled from static-src/.

spec

The spec directory contains our selenium tests.

static-src

This is where we keep all of our pre-compiled files.

Compiling LESS

Our Less files are broken down into modules. There is a master file that imports all dependencies. This master file is then compiled into CSS, minified and placed in the static/css/ directory.

Compiling JavaScript

Just like our Less files, all our JavaScript is broken down into modules. These are then concatenated to a master JavaScript file which is placed in the static/js/ directory. We also create a minified version for production which sits alongside the master file in the static/js/ directory.

Enter Grunt

Grunt makes the process of performing all of the above tasks very simple. Everything is defined inside our grunt.js file:

module.exports = function(grunt) {

  grunt.initConfig({
    lint: {
      files: ['static-src/js/*.js']
    },
    less: {
      development: {
        options: {
          paths: ['static-src/less/'],
          yuicompress: true
        },
        files: {
          'public/static/css/master.css': 'static-src/less/master.less'
        }
      }
    },
    concat: {
      dist: {
        src: [
          'static-src/js/lib/jquery/jquery.js',
          'static-src/js/lib/jquery/jquery.cookie.js',
          'static-src/js/app.js'
        ],
        dest: 'public/static/js/master.js'
      }
    },
    min: {
      dist: {
        src: 'public/static/js/master.js',
        dest: 'public/static/js/master.min.js'
      }
    },
    watch: {
      files: ['static-src/js/*.js', 'static-src/less/*.less'],
      tasks: 'default'
    }
  });

  grunt.loadNpmTasks('grunt-contrib-less');

  grunt.registerTask('default', 'lint less concat min');

};

Extending Grunt

Grunt is very extensible and here we are using it in it’s most basic form using (with the exception of Less) only it’s built-in tasks. The goal here was to become less reliant on a third-part app such as CodeKit in favour of a platform that we can easily build upon.

Going forward, this is likely to be the way we do things. We will no doubt build on this in time, making use of more advanced features, and maybe even build some tasks of our own, but even as it stands, this is a good position for us to be in.

Links - week 46

2012-11-22T22:12:38+00:00 by Nick Boyce

Outside of the madness that is Christmas season at Easyart Towers, here are a few nuggets I’ve enjoyed on the interwebs this week.

The animated and excitable Addy Osmani’s talk on The New And Improved Developer Toolbelt from Fronteers 2012 outlines some interesting tools for modern front end development, but I don’t see us using Yoeman anytime soon (it’s too magic!).
I’d seen this one before, and perhaps I am using it as a cheatsheet for his book that I haven’t quite finished reading yet, but Dan Pink’s TED lecture on the mismatch between what science knows about motivation and what business does is utterly fascinating.
Some useful links in The Web engineer’s online toolbox that I’ll be sure to come back to
Another one I re-read is The evolution of SoundCloud’s architecture as it’s relevant to some thinking I am doing at the moment.
I’m really excited about what’s happening at GDS. It seems impossibly progressive for a government to assemble a really clever group of designers and (Ruby) developers to build a new integrated web platform, and to make the whole thing open source and on Github!
I could almost see this list of Useful Talks And Videos From Web Design Conferences replacing TV for me for a while, if only by Boxee would switch back on!

The breakpoint podcasts

2012-11-19T10:28:10+00:00 by Steve Rydz

Lately I’ve been enjoying a new video series from the Google Developers channel called The Breakpoint with Paul Irish and Addy Osmani, which focuses on front-end developer tools.

So far there have been three episodes and I highly recommend checking them out:

London JS - Create the web

2012-11-13T10:35:41+00:00 by Steve Rydz

Last night I attended London JS — Create the web, which was hosted at Forward Technology.

The first talk was by Jack Franklin and was called Optimising JavaScript.

It was only a short talk but Jack presented some interesting finds regarding how to do common things with JavaScript quickly. To see some examples of this go checkout his slides.

The second talk was more of a presentation on some of Adobes new products by Michael Chaize and Terrance Ryan.

It really looks like Adobe have stepped up their game and are now developing more web focused tools. They seem to be doing a lot with animation, but from the sound of their laptop fans I’m not sure the world is ready for that yet.

The two tools that impressed me were the yet-to-be-released Reflow and Brackets.

Reflow is a responsive design application which allows you to set breakpoints and rearrange the design accordingly. Effectively you are editing DOM elements rather than Photoshop layers. I really think a tool like this will help get designers thinking responsively, causing us developers a few less headaches in the process.

Brackets is an open source HTML, CSS and JavaScript editor. It has been designed to be lightweight, front-end focused and extensible. It is built entirely in HTML, CSS and JavaScript and therefore easy to customise and extend with your own plugins. One feature I particularly liked was the ability to select an element from a HTML file and edit the CSS properties for that element without opening another file.

Unfortunately I had to leave before Sam Duttons WebRTC talk so I can’t say anything about that.

I did come away with a free foldable me which I did put together late last night but have yet to photograph.

Links - Week 45

2012-11-12T13:38:29+00:00 by Nick Boyce

Interesting stuff from around the internet last week

Full Frontal Tooling

2012-11-07T20:25:51+00:00 by Steve Rydz

I’ve just got back from the Full Frontal Tooling Workshops in Brighton, so I thought I’d best write about my experience whilst it’s still fresh in my mind.

The set up

There were six different workshops in total, with Remy Sharp, Rebecca Murphey and Jake Archibald each leading two sessions. They were structured so participants could attend any four of the workshops throughout the day. The topics were:

Modularizing your JavaScript with RequireJS — Rebecca Murphey
Writing Testable JavaScript — Rebecca Murphey
Massive git — Jake Archibald
It’s your Sass on the line — Jake Archibald
Debugging — Remy Sharp
Build Process — Remy Sharp

What to choose?

I chose the require.js, testable JavaScript, debugging and build process workshops. I didn’t opt for the git workshop as I use it daily and am relatively comfortable with it and the same goes for Sass (although we currently use LESS at Easyart). Whilst I’m sure they were great workshops, I felt I would benefit a lot more from the others, especially as they addressed topics that I have become very interested in lately.

Modularizing your JavaScript with RequireJS

We started with an existing project, which had several script tags linking to various JavaScript files such as jQuery, Backbone, Underscore and more. Rebecca then showed us how to use require.js and the AMD format to manage our dependencies and modules, and then going on to build the project with a simple command.

This got me thinking about the way our JavaScript is structured, and whilst it has certainly seen improvement over the past six months or so, it could be taken a stage further by introducing require.js into our process.

Writing Testable JavaScript

We have been focusing on Test-driven development quite a lot lately and have also identified that we need to be doing unit tests on our JavaScript so this topic was particularly relevant to me.

Rebecca introduced us to QUnit and explained the thought-process behind unit testing and writing testable JavaScript.

When carrying out unit tests, we are essentially asking the following question:

Given this input, do I get this output?

— Rebecca Murphey

This sounds simple, and really it is. The main thing to get your head around is writing JavaScript that is actually testable. Rebecca showed us some typical jQuery code, which was distinctly lacking in functions or output, and explained how it was very difficult to test, and went on to explain how to write JavaScript that actually returns something so we can test it.

Things don’t do things — Things announce things

— Rebecca Murphey

The process of writing good tests should be to make them fail first, and then write the necessary code to make them pass. Well written tests not only ensure that your code is actually working, they help you to write better code.

One point that stood out to me in this workshop was not to get too hung up on testing edge cases. Make your tests as thorough as they need to be and then if an edge case does occur, write the test, then fix the problem.

Later, we were briefly introduced to Mocha, a more advanced testing framework, and also shown how to integrate testing with grunt.js.

Debugging

Being a developer, I’m no stranger to the Chrome developer tools but I’ve never really used them to their full potential.

During this workshop, Remy introduced us to the concept of step debugging and setting breakpoints. I had come across breakpoints before but wasn’t really sure how I could use them to debug code so I found this really helpful.

Something Remy said, which I have heard quite a lot, is that if you are using alerts for debugging you should stop right now. console.log is your friend.

After a run through of the various tabs in the Chrome developer tools, Remy talked to us about mobile debugging.

Debugging code in mobile browsers can be a nightmare, but Remy showed us something called weinre, which basically listens to your ip address and binds itself to it, allowing you to open the developer tools on your machine and debug in your mobile browser.

One thing that was stressed was the importance of testing on real devices. Emulators are fine for getting a quick overview but if you are doing any mobile specific work, get real phones.

Build Process

This workshop was based around a tool called Grunt, which is, in its own words, a task-based command line build tool for JavaScript projects.

Grunt is very powerful and can take care of a lot of otherwise mundane tasks for you such as:

Concatenating files
Generating project scaffolding
Linting your code
Minifying your code
Running unit tests
Starting a static web server

These are just the built-in tasks. Grunt is still very new but despite this, there are already over 200 plugins available.

This got me thinking about our build process and how it could be streamlined using this tool. We currently compile, concatenate and minify our Less files using CodeKit, the same goes for our JavaScript which we also run through JSHint. This works for us, but can sometimes feel cumbersome.

The possibilities with Grunt are endless and I also feel like it would give us more control over our projects so it is definitely something I will investigate adding to our process.

Conclusion

I really felt like I got a lot out of these workshops today. It was a lot of information to take in but the key points all came across. I really liked the format and 90 minutes seems to be about the perfect length for workshop sessions of this kind.

I don’t know if Remy is planning to do something similar next year but if he does I hope I will be lucky enough to attend once more.

This weekend's reading and viewing

2012-11-04T10:37:55+00:00 by Nick Boyce

After a week focussed on product development, user experience and design, I’ve been geeking out with a bunch of articles, podcasts and videos this weekend.

The importance of user testing

2012-10-22T11:35:21+00:00 by Steve Rydz

When developing a customer facing site, such as Easyart.com, is it very important to be aware of your users perspective. The recommended way to do this is something known as user testing.

What is user testing

User testing is essentially watching how people use your website/application. Traditionally, this is done by arranging a session for people to come and use your site, where they would be given tasks to complete. The process is recorded and then analysed to see what could be improved.

Mostly due to time and budget constraints, this isn’t always easy to accomplish, but luckily there is now a whole host of affordable services that help us solve this problem.

Choosing a service

When choosing a service for any reason, the important thing is to establish exactly what you need from it. We did some research on user testing and decided that we would need a video of the session along with the audio, and the ability to ask follow-up questions. The service that seemed to be the best fit for us was usertesting.com.

Setting up the test

To kick off the test, we needed a set of tasks. We called this a user journey, and set a list of tasks for the participants of the test to follow, demonstrating the areas we knew we needed to work on.

Getting the feedback

Within the hour, all three of the tests we set-up had been completed and we had access to the videos. Over the next couple of days we watched these videos, listened to the commentaries and read the answers to our follow-up questions, taking notes the whole time.

Almost immediately we identified some key areas that we needed to work on and have already started working on solutions to improve our customers experience on our site.

Going forward

From now on, we plan to run user tests regularly, as we have found it provides a valuable insight into how our site is used and how it can be improved.

User testing will make your site better and usertesting.com is a great tool for helping you achieve this.

Highlights from Dublin Web Summit 2012

2012-10-21T11:16:00+00:00 by Nick Boyce

This week thousands fellow web makers, CEOs, VCs and geeks descended on Dublin for the Dublin Web Summit. They had done an amazing job of promoting the event - there were flags on the mains streets, front-page coverage in papers and loads of media reporting live from the event (to the point where the wifi was almost useless!). The event itself had four stages, an expo room with startups from all over the world, and startup pitching stages. The overall highlight had to be DWS By Night, where they had taken over a whole street of pubs and clubs with free drinks for attendees. There were bound to be some sore heads on Thursday morning!

Startup pitching stages

Though the calibre of speakers on the stages was second to none (in Europe at least), I spent a lot of time on the startup pitching stages seeing what was happening in the startup world. Some highlights from the pitching stages and stands:

Copygr.am. Tools for Instagram, and photographic prints. The design is lovely, but the prints are too expensive.
Fabsie. Designer flatpack furniture manufactured on demand from crowdsourced manufacturers. I was really impressed by this but wonder how far they can go with the aesthetic they are locked into with laser cut wood.
Resump. “ResumUp is a service which shows you who and what you need to know to achieve all your career goals.” It helps you visualise your skills and connects you with people who are already in your network to progress your career.
Atoomba. Basically IFTT for your (Android) mobile.
Smart Things. These guys won the pitching competition for their impressive system to connect devices to the internet. This (or something like it) is going to be a big deal.
Tictail. Quick and easy online stores with a killer UI. I tried it out and had as store online in 2minutes, and actually enjoyed the process. The resulting stores are just OK but the creation process is really impressive.

Chris Poole 4chan, Founder

The subheading of this talk was something like how I unwittingly became a sysadmin, and was a story of how 4chan serves 600m page views a month and 1m new posts a day on five second-hand servers - each of which is a single point of failure - and no full-time staff.

By looking at the numbers that Google Analytics (which fires in the client via JavaScript) and Cloudflare (which was the entry point to the web request) were reporting, he realised that that half of their traffic was coming from web scrapers and third-party extensions, so it was only then that they added an API (which now serves 50m requests a day).

This was a really interesting talk with some refreshingly honest views, but it does go against a lot of things I believe as a software engineer, and I very much doubt that he has taken the same approach with his VC-funded startup Canv.as

Curating the e-commerce revolution

A panel discussion with:

Chris Morton, Ceo & Co-Founder of Lyst
Diego Berdakin, President of BeachMint
Shauna Mei, Founder AHAlife.com
Carl Fritjofsson, Co-Founder & COO Wrapp
Olivia Gossett, founder of ILWYW.com

The basic theme of the discussion was that in online fashion retail, customers expect recommendations and a back-story (and increasingly customisation) in order to connect with the product. There seemed to be general agreement that the Net a Porter “shop the story” approach is a model that works well.

Amazon’s approach is to fulfil commands (you search for TVs, you get TVs), but is terrible for serendipitous discovery. “You never go to a grocery store and bring back only what was on your list”.

Serendipity through content. Create desire through stories and context.

Here’s a recording of the panel (watch from 1:47:40)

More highlights in brief

The BBC’s Chief Architect, News and Knowledge Gary O'Connor on BBC’s dipping their toe in the water of cloud computing. An interesting perspective on the challenges in selling it into ops (they had no choice really, because they had to scale to accommodate London 2012 coverage), selecting a provider (AWS).
Mike McCue, Founder and CEO of Flipboard with MG Siegler, TechCrunch. I didn’t really consider Flipboard to be important to publishing, but I have changed my mind now.
Mozilla Chairman Mitchell Baker provided some interesting insights into the state of the web at the moment and Mozilla’s mission to keep it open.
Patrick Collison from Stripe was really interesting talk about how they got started, their challenges and growth.

Most of the event should be available on this Livestream page.

Some notes from WebPerfDays

2012-10-05T00:00:00+00:00 by Nick Boyce

I’m just back from WebPerfDays at Facebook’s London engineering offices in Covent Garden. It was a really great day out, with some great presenters.

A few notes…

Joshua Bixby is a really good presenter and I’ll be following his blog.
Not all performace stats apply to all companies. There were several examples cited of how reducing page load time had either no discernable effect, or even a negative impact (though they were very specific cases).
“Mortal companies” have different problems to the Googles, Facebooks and Amazons of the world.
Using a CDN doesn’t guarantee those assets are delivered to the user faster. Our measurements would suggest otherwise, but a second look at the data would be wise.
97% of mobile response time is on the front end!
I like the concept of a “poverty line” in performance. i.e. if a metric is below a certain threshold it’s “poor”.
A significant percentage of mobile users prefer the full site rather than a mobile version.
Simply cleaning up code and doing all the things you already know you should be doing will get you 80% of the way to where you need to get to with front-end code.
We should check out writegoodcode.com.
After you optimise your front-end code, you have to be be vigilant about maitaining the gains you have made.
Other people probably have more difficult performance problems to solve than us. Seatwave have to cope for massive (60x) request peaks in requests in a matter of seconds (i.e. when their TVC is aired in the middle of X-Factor or a new concert goes on sale).
We should take a close look on the performance of our third party dependencies. They are generally recognised as evil when it comes to web performance.
Lonely Planet have a really great DevOps culture in their company (see their (dev blog)[http://devops.lonelyplanet.com/]) where metrics are king and web performance is recognised as a priority throughout the whole organisation. * They have gone some way to replacing “HiPPO” (Highest Paid Person’s Opinion) with real data.
Webpagetest.org is a tool that a lot of web performance experts seem to refer to.
Facebook have problems that are extremely unique, and fascinating from an observer’s standpoint, but intimidatingly complex from a developer’s. Sławek Biel did a really interesting presentation about how Facebook optimises its data access.
Overall, it’s just reminded me that we need to continue to focus on performance as part of what we do.

Update: Some of the presentations are now available online.

Basecamp at Easyart

2012-08-01T00:00:00+00:00 by Nick Boyce

We’re big fans of Basecamp here at Easyart. It’s very close to replacing email for our internal discussions. Here’s what we like:

It’s open. I might have a discussion with one person, but others can be aware of what’s going on by overhearing the discussion in the project or in the daily recap. It’s also easy to see who is over subscribed.
Distance is less important. We have two sites, numerous people that work from home, and a number of contractors. Using Basecamp is our primary means of communication makes collaboration more effective no matter where you are located.
It’s incredibly simple and fun to use. It does a small amount of things – to-dos, text documents, discussions, files – really well (we use Google for calendars). I had been meaning to write an internal document on how to use Basecamp but it has never been necessary!
It’s totally usable by email only. Some of our busier people use it purely through email, while others use a combination of online and email.

A few things would make it even more useful:

Mentions. Sometimes the amount of email Basecamp generates is overwhelming, and unless you are assigned to a task you might never know that someone is waiting for a response from you.
A proper CalDAV calendar. We need to be able to create events from other apps and devices if the calendar is going to be useful for us.
A way to “loop in” other collaborators into a task or discussion, on the site. The only way to do this at the moment is to loop them in on email only.
Chat integration. We switched from Campfire to Flowdock back in March, but because most of the action is now in Basecamp, we don’t use chat as much. It would be nice to be able to send one-liners in Basecamp without starting new discussions.

Flickr's liquid photo layout

2012-07-31T00:00:00+00:00 by Nick Boyce

Spotted this interesting piece on Flickr’s code blog about the thought behind their new liquid photo page, which is very relevant to some of the things we are thinking about at the moment.

The lesson of jam sandwiches for service developers and marketeers

2012-06-02T00:00:00+00:00 by Nick Boyce

Colin Strong from GfK did a great presentation at Digital Shoreditch yesterday on behavioural economics called The lesson of jam sandwiches for service developers and marketeers which ties in with a lot of things we’ve been discussing internally. Here are my takeaways:

Avoid choice overload

In the Jam sandwich study, customers were presented with 24 jams, which resulted in a 3% takeup. When the number of jams was reduced to 6, the takeup jumped to 30%. Reduce choice to increase conversions.

Decoy options

Introducing options in a product mix can have an effect on the percieved value of the other options. As an example, when consumers were shown three options for Economist subscriptions…

Online only for $59
Print only for $125
Print and online for $125

…nobody picked option 2 and 84% choose option 3. That’s because option 2 is acting as a decoy option 3 more attractive. When option 2 was removed, only 32% selected Option 3.

Encourage a sense of ownership

Once consumers feel they own an item they are reluctant to part with it. On Ebay, the highest bidder often starts thinking about possessing item, leading to more aggressive bidding. Amazon Prime’s limited trial makes customers focus on what they will lose if they cancel their subscription.

Social influence

Consumers are hugely influenced by the behaviour of others. Stock levels create a fear of missing out. I also think that positive social reinforcement - showing that other “real” people are buying an item - can be a huge influence also.

Create magic moments

Overall assessment is not key, only if the customer had a very positive or very negative experience. Create “positive peaks” through magic moments to leave a positive impression. Add something for free. It’s inexpensive and has a disproportionate impact on satisfaction.

Git-based deploys

2012-05-21T00:00:00+00:00 by Nick Boyce

Recently we’ve switched from FTP to git to deploy changes to our live sites. Here’s what our workflow looks like for functional changes (content amends use steps1,2,5,7,8):

Make changes on VMs on develop branch
Commit and push develop branch to Github
Pull develop branch to staging server
Review changes
Merge develop into master
Run Selenium tests
Push master to Github
Pull master into live server

By using a Git-centric workflow, it’s easier to guarantee that each application is running the same code, and we have the added safety of being able to roll back to previous versions.

Pulling changes onto live websites with millions of daily visitors makes me a little nervous, so I’ll usually use git fetch rather than git pull, like so:

$ git fetch

Pulls the remote master branch into a branch in the local repository called origin/master.

$ git diff --numstat master origin/master

Reports the affected files between master and the origin/master branch we pulled in the previous step.

$ git merge master origin/master

Merges the origin/master branch into master.

Using Selenium and Rspec for behaviour testing

2012-05-01T00:00:00+00:00 by Nick Boyce

We’ve been doing some restructuring here at Easyart, in order to set up a more Git-centric workflow for deployments. We wanted to make sure that we had some tests which would help us spot any problems while we made the transition.

I’m relatively comfortable with Rspec, so it was a natural starting point. But given that the sites themselves aren’t built in Ruby, I’m using Rspec to power Selenium Webdriver.

Here’s a sample test:

The Selenium::WebDriver object makes writing these tests pretty simple. These are the main methods we use:

find_element and find_elements
get (or navigate.to, which I think are identical)
title

That’s pretty much it! These are the methods in the Selenium::WebDriver::Element object we are making the most use of:

text
click
send_keys

Here’s an example which makes use of these:

One thing that took some getting used to was using the Selenium::WebDriver::Wait object. When you do a click, you have to tell Selenium you want to wait for a certain condition to be true before moving on to the next live of code.

In this example, I’m waiting until the H1 tag contains the word “cart”:

I’m used Rspec for unit and request specs, but it’s advantageous to use a visible browser for this type of testing, as sometimes you can spot things with your eye that your tests won’t. Then you write the test to catch it.

Quick tip: Opening files in Sublime from Terminal

2012-04-27T00:00:00+00:00 by Steve Rydz

Sublime Text 2 has been my text editor of choice for almost a year now but as I find myself working from the command line more and more these days, I thought I’d share a quick tip I picked up from Nick, opening files from the command line.

Getting set up

To begin with, we need to ensure that the bin directory is specified in our path. Just paste the following into Terminal:

$ echo "export PATH=~/bin:$PATH" >> ~/.profile

Next up, we need to create the subl command. To do that just paste the following into Terminal:

$ ln -s "/Applications/Sublime Text 2.app/Contents/SharedSupport/bin/subl" ~/bin/subl

To make sure this is working, just type subl into Terminal and press enter. If you’ve followed the steps above then that should open up Sublime.

Using the command

We’ve already seen how the subl command can be used to open Sublime itself, however it can also be used to open files and directorys, among other things.

This command opens a directory called mySite:

$ subl ~/Documents/mySite

This command opens a file from the above directory called index.html:

$ subl ~/Documents/mySite/index.html

Taking it further

This only scratches the surface of what you can do with this type of command. To see other actions available, try typing subl –help into Terminal and pressing enter. This will give you a list of ways to use this command.

Note: This post is pretty much lifted from a post I wrote on my own blog last night:

http://steverydz.com/2012/04/27/sublime-text-2-opening-files-and-folders-from-the-command-line/

Codekit tip: Export project settings

2012-04-19T00:00:00+00:00 by Steve Rydz

A few weeks ago I wrote about getting to know CodeKit. As a team, we have been using this tool solidly since then and it is now hard to imagine not working without it.

We did have a couple of issues with it though. The first was that everytime we updated the app, we had to set up our project again. This has been fixed in a recent release.

The other issue was that when working as a team, we had to ensure that we all had the exact same set-up. CodeKit is very intelligent and recognised what we were trying to acheive most of the time but we still found ourselves having to update output directories etc.

As it turns out, there was one simple solution to both of these problems. It is possible to export a config file for each project with it’s settings. This file lives in the root directory of your project and every time you drag a project into CodeKit, it looks for this file automatically.

To export the configuration file, simply highlight the project you are currently working on, right click on it, hover over the ‘Project settings’ menu, then click ‘Export project configuration file’. CodeKit will then place that file in the root directory of your project. That’s all there is to it.

This approach has worked really well for us and taken the burden of having to constantly ensure we are all doing the same thing away from us. The other great thing about this is that we now have this config file in our GIT repository.

All we have to do if we change the way our project is set up or introduce something new is to export another file and because we are using GIT, we will all get the latest file when we pull down the latest code.

Note: According to the CodeKit website, the free, BETA version of the app expires tomorrow (20th April, 2012), and I have heard rumours that it will be on sale via the app store for around $20. This app is more than worth that amount and if this is the case, I will certainly be purchasing a license first thing.

Deploying static assets to S3 using s3cmd

2012-04-17T00:00:00+00:00 by Nick Boyce

I’ve been looking at ways to deploy our static assets to S3 as part of our Git workflow.

I want to be able to push to the master branch of a remote repo and have the changes deployed to S3, with predefined HTTP headers. Much like I’m used to pushing to Heroku with git push heroku master.

There are probably plenty of ways to do it - mounting S3 through Fuse, running Webdav servers, using Capistrano etc - but I found them too overkill for our needs.

So I’ve ended up writing a simple deploy script which lives at the root of the repo which uses s3cmd to sync between the local file system and our S3 bucket. It’s a snap to set up, and the result is a command that looks like this:

I store this file in the repo, so that each of us developers can execute it by just calling ./deploy.sh. As this process is outside of the Git workflow, I have to exclude the .git directory. Conveniently, s3cmd’s format for excluding files is the same as Git’s so you can pass in a .gitignore if you’re using one.

It’s not a true Git deploy (though it could be called via a Git Hook), but still a pretty neat solution.

Cheating isn't always a bad thing

2012-04-17T00:00:00+00:00 by John Pash

I read a thought-provoking comment today on High Scalability that got me thinking. It appeared in a post which attempted to sum up “7 Years of YouTube Scalability Lessons in 30 Minutes”. It shows a neat little trick that you can use to make it appear to the user that your site is faster than it really is. Read on…

Approximate Correctness - Cheat a Little

A real world example. If you write a comment and someone loads the page at the same time, they might not get it for 300-400ms, the user who is reading won’t care. The writer of the comment will care, so you make sure the user who wrote the comment will see it. So you cheat a little bit. Your system doesn’t have to have globally consistent transactions. That would be super expensive and overkill. Not every comment is a financial transaction. So know when you can cheat.

So basically you would update the page DOM in real-time, but send the actual comment post operation behind the scenes. It can take as long as it needs to complete. But in the meantime the commenter is happy to have such a quick experience. It’s a win-win!

High Scalability is a blog that exposes the architecture of some very well-known and highly trafficked websites. The posts are often written by the developers of those systems. So if you’ve ever wondered how Twitter stores 250,000,000 tweets a day using MySql (no NoSql here), then H.S. is the blog for you.

Front-end development requirements

2012-04-13T00:00:00+00:00 by Steve Rydz

It wasn’t that long ago when front-end development was considered to be nothing more than knowing HTML, CSS and jQuery. There wasn’t a great deal more to it, but the role has really developed over the past two years or so.

Yesterday I came across an article that does a great job of outlining what should be required of a front-end developer today. Go read it…

A unified coding style

2012-04-12T00:00:00+00:00 by Steve Rydz

Something we have been working on recently is finding a unified coding style that we are all comfortable with. The benefits of this are that any one of us can pick up a project and run with it as we are already familiar with the way the project has been set up.

Another aim of ours when authoring code is to be as efficient as possible, not just in terms of file size but in terms of maintainability also.

One tool we have been using to help us acheive this is LESS. Combining LESS with our own coding conventions, each of us can quickly find what we are looking for in our CSS and can also make changes quickly, knowing that what we are doing will be maintainable.

An example would be nesting. LESS allows you to nest selectors like so:

#header {
  overflow: hidden;

  h1 {
    font-size: 3em;
  }
}

As someone who doesn’t have a background in programming, I did find this initially confusing, but it soon begins to make sense and once you start working this way you will probably never want to go back.

This code will output as follows:

#header {
  overflow: hidden;
}

#header h1 {
  font-size: 3em;
}

Something else you will notice in the above snippet is that there is a blank line before the descendent selector, an no blank lines after the closing brakets. This is something we agreed upon as a standard because it makes code more readable.

It doesn’t matter what your coding conventions are, as long as they make sense to you and your team, but using them will increase productivity considerably and are worth the investment in time it takes to establish them.

Another thing that is worth doing, and again, something we are working on, is drafting a CSS styleguide. This is something that you can add to over time as and when you add new tools and methodologies into your process, such as we have, working with LESS and CodeKit.

The key thing to remember is that whatever you come up with, it needs to be something that your team can all get on board with, as the aim is to increase productivity and make things easier to maintain.

History state and the back button

2012-04-11T00:00:00+00:00 by Nick Boyce

I’ve been playing around with the HTML5 history API today, in order to make certain parts of our new product page bookmarkable. Here’s what we’re aiming for:

On page1.html, the user clicks an a tag which has a href value of page2.html
Instead of refreshing the page with the contents of framing.html, a panel in the page slides across to reveal the contents of page2.html in the current page
The URL changes to page2.html

This is relatively easy to achieve by intercepting these links, and replacing them with Javascript behavior and using the HTML5 History API to push a new URL into the address bar. So, as an example, the following code will find every a on the page and instead of navigating to the href, just push the state into the address bar.

So we can quite easily intercept links to page2.html (either based on their href attribute or a CSS class), push the href into the address bar and load the content into the current page in some fancy-pants way.

But say you want the back button to navigate the user from page2.html back to page1.html. This won’t work, because unless you tell it to do otherwise, the back button will change the address, but do nothing else.

This is where popstate comes in. Using popstate we can listen for changes in the address, and act upon them accordingly. So my code ended up looking something like this:

It’s also possible to pass objects and titles through to pushstate, but I won’t go into that for now as it’s not yet well supported by browsers. Simply finding out the address of the page was good enough to solve the immediate problem.

Resources:

http://diveintohtml5.info/history.html https://developer.mozilla.org/en/DOM/Manipulating_the_browser_history

Testing Rails JSON APIs with RSpec

2012-04-10T00:00:00+00:00 by Nick Boyce

I’ve spent some time in the last couple of weeks taking the learnings from an early API prototype, and starting a new Rails application from scratch, complete with RSpec tests. Here are some notes on some of our tools and methodologies.

Model specs

We’re overriding the as_json method in our models and we’re using json_spec to test the documents have the right structure.

Request specs

We have hundreds of lines of request specs, and no controller specs. Here is a simple example:

Because we’re getting an actual HTTP payload back (in the response variable) we can inspect whatever part of it that’s relevant to us. We know the structure of the responses should come back in a known format because we’re testing the to_json method in the class specs. So it’s just a matter of using JSON.parse on the response.body and testing it as a native Ruby object.

Of course, this means that we are trusting JSON.parse to behave reliably but that’s an assumption worth making. If we were really pedantic, we could check that each object in the response array matches the expected structure:

Though I’m not sure that’s actually testing anything meaningful.

Another great advantage is that it makes refactoring simple. As far as the specs are concerned, a request to is the same whether the heavy lifting is done in the model or the controller. This really helped me recently when I moved a bunch of logic from the controller to the model as I could let the specs tell me which parts starting misbehaving.

Update: An interesting post by DHH about over-testing.

On source control

2012-04-05T00:00:00+00:00 by Steve Rydz

Source control is fairly commonplace these days. Most people use the likes of GIT or SVN as part of their process, however there are still plenty of people out there who don’t use version control because they either don’t see a reason to or they don’t know where to start.

Until mid-way through last year, I fell into the latter category. I worked alone as a freelancer and made good use of Dropbox. The thing is, I was really missing out. It wasn’t until I started working as part of a team that I saw the real benefits.

I had tried to used these tools a few times, but quickly became overwhelmed by the magnitude of documentation that was presented to me. It all seemed to complicated and still, I couldn’t understand how I would benefit from this extra step in my workflow.

The thing is, once someone sat down with me and took me through what I needed to know about these systems, it almost became second nature. I have now got experience using both SVN and GIT and would highly recommend GIT over SVN to anyone, especially with the use of Github.

These days, particularly if you use a Mac (which I assume most developers do), there are some great, simple user interfaces for both GIT and SVN which will help you to get started and give you an understanding as to how these technologies work. Once you understand this, its really easy to learn the terminal commands.

The apps I would recommend are Versions for SVN and Github:Mac for GIT. Both are relatively self-explanatory but also have good documentation available.

Stick with it and you will wonder how you ever worked without this stuff. Personally, I would never start a project without using GIT now, even when working solo.

The importance of LESS

2012-03-26T00:00:00+00:00 by Steve Rydz

I recently wrote about CodeKit and how it has improved our workflow when using pre-processors, but at the time I didn’t allude to the reason that we would use such things. Whilst LESS and SASS are certainly gaining traction, there are many developers out there who just don’t see the point in using something like that.

I must admit, I too was sceptical when I started reading about this new-fangled way to write CSS. I was confident that my code was of a high standard, efficient and maintainable, and I also loved the hand-crafted feeling you get from hand-coding everything (including vendor pre-fixes). The thing is, I just could see how pre-processors could make my code any better.

Of course I was missing the point. In order to really get the most out of these tools, you need to be writing good quality code anyway. LESS will not make you a better developer, but it can make you more efficient.

The first thing that normally wins people over is the use of variables. How many times have you scrolled up and down that stylesheet, looking for that colour value? Well, not with LESS. Here’s another one. You want your box-shadows to be consistent, and you can’t remember the exact code you used. Again, you could spend a few minutes searching through your stylesheet, or you could just use LESS.

The point is, LESS is great for enabling you to work faster and it can really eliminate the tedious parts of the job too. Really, there is no reason to repeat ourselves in code, time after time. Why not use a tool that takes care of the repetitive tasks for you.

Now, what I have just talked about only scratches the surface of what LESS is capable of, and there is much of it that you might not find useful, and that»s fine. Take what you need from it, but don’t write it off until you have taken the time to see how it can really benefit your workflow.

Links and resources

Here are a few links and resources that will help you learn more about LESS:

On Naming Schemes

2012-03-23T00:00:00+00:00 by Nick Boyce

There has been some debate internally about how naming our systems and applications. On the surface it may seem trivial, I find having a naming scheme really helps for:

Discussing how systems relate to one another. It’s much easier to talk about Bootstrap than “The Twitter CSS Framework”. Significant advances in the application may result in new names, meaning less talk of “the new system” and “the old system”.
Organising Git repositories. Calling things “API” or “CSS framework” is boring and not specific enough to be useful.
Every project deserves a little personality of its own.

So, with that in mind, we have decided to use movie directors as the naming scheme for our systems, starting with our new API-driven platform, Kubrick. So if “there are only two hard things in Computer Science: cache invalidation and naming things”, perhaps we have reason to celebrate!

Getting to know Codekit

2012-03-23T00:00:00+00:00 by Steve Rydz

CSS pre-processors are all the rage these days, or so it would seem, but it can be a little complicated to get up and running with them, unless you’re using the right tools. Enter CodeKit. This little app does pretty much everything from compiling LESS, SASS, HAML and CoffeeScript to optimising images and allowing you to import JavaScript files into each other.

Since I started using LESS about six months ago I have been on the hunt for an app that can make the process of using it simple. That’s where CodeKit comes into it. Previously I had been using the LESS app and on a surface level found it worked well, but it was lacking a sense of intuitiveness. CodeKit just knows what I’m trying to do and doesn’t require much in the way of configuration, at least where LESS is concerned.

I will be writing more about how we use CodeKit at Easyart in the future, but for now I will simply say that if you are at all involved in front-end development then you should check out it out as you will surely find it will improve your workflow and potentially make you more productive.

Goodbye Campfire, Hello Flowdock

2012-03-22T00:00:00+00:00 by Nick Boyce

For a number of years I’ve really loved using Campfire for team chat and collaboration, but today I’ve cancelled our account. I’ve found that as time has gone on, and our team has grown, it’s become increasingly frustrating to use. My main issues are:

The timeline ends up with too much noise from Github commits and issues.
Search is clunky. You can only search using keywords, and you have to leave the room to do so.

Flowdock solves these problems by using one pane for chat, and another for “Team Inbox” and Search.

Team Inbox is by far the most useful feature. We use it for:

All Github activity. When new files are committed, you can mouse over for a full list of changes, and click to get to the Github commit page. When issues are opened or closed, they show too.
Inbox. We feed in the @easyartuk Twitter account (you can see one of the tweets in the bottom-right corner), and all emails to our developer account, and they’ll show up in our feed.

You can also comment on any of this activity contextually. So, for instance, I could comment on an email. Search is also really cool too, and you can filter by files, links, and attachments. Without leaving the chat.

It’s been a really useful tool for us, and I can’t see us going back to Campfire.