James Murtagh

24 August 2015

Birds, Bees, and Honeycomb

Had I ever been asked the question “What animal would you like to be and why?” (apparently it was a common interview brainteaser), I would have answered “A penguin”. I like water, I also like sardines. I don’t care much for flying (in fact, the older I get, the more frightening a prospect that is), nor do I worry about the cold. I work best in teams of capable individuals who I can swim with and learn from. And I’m also pretty rubbish with my feet on land.

Ask me the same question about web code and the answer would be “Bees”. Whereas individual creativity should be fostered in a team of people, a group of websites are easier to manage if they’re built around a core set of patterns and practices. Birds’ nests evolve freely, scattered around the place. A bee hive, on the other hand, is formed of interconnected cells, supporting each other and built of the same stuff.

What’s the point of all this?

I’m getting there.

Redgate’s websites have evolved more like bird nests, owned by separate teams, than a beehive. This approach has meant that the same type of work has often been repeated across sites (eg, implementing a slideshow component), and makes responding to industry changes like Google’s mobile-friendly algorithm slow.

Carrying out work also typically requires a deep knowledge of how the sites are assembled and how they function. Furthermore, the sites have taken on separate brand characteristics, rather than being sub-brands of Redgate.

Today, the management of Redgate’s front-end website code is the responsibility of a single team – the web team – and we’re moving away from maintaining a disparate network of sites to carrying out development in a more efficient and joined up way.

The key to managing – and more importantly developing – the code of several different sites from a central position is to implement a front-end web framework. Having a framework underpinning our sites channels our dev resources, introduces a focus on building global elements, and ensures that all of our websites scale on all devices. This saves huge chunks of time.

Great stuff – show me the framework

There are plenty of frameworks out there to choose from – Twitter Bootstrap probably being the most famous … but we chose to develop our own to give us greater control.

The reason is that our sites serve a number of different functions – from education, community, and marketing, to customer support, documentation, and licensing – so our framework needs to be flexible.

We’ve taken the Redgate.com base code and stripped it back to component parts that can be used widely across our sites – things like buttons, typography, tables, etc. As we’ve done so, we’ve documented it, building up a front-end reference website, code library, and style guide.

It’s our intention that this underpins all of our websites, with any additional styles and components that are needed built on top of the base. We’ll standardise on HTML/PHP where we can and, where there’s a requirement to use another front-end technology such as ASP.NET, the style guide will provide the necessary guidance.

The result will be a network of sites instantly recognisable as ‘Redgate’, not because they carry the Redgate logo, but because they adhere to the same patterns and practices, and have a familiar look and feel, much the same as when you move between MS Office apps.

We’ll also be able to move faster, developing from a much wider pool of feedback – making a change to the way we handle comments, for example, on Simple-Talk can be rolled into the Redgate blog, the forums, etc, quickly and easily.

Where do bees come into it again?

We originally called the framework and style guide ‘Ingeniously Simple Web’, because it’s intended as a tool for maintaining consistency across our websites, encouraging us to develop with a global mind set, and bringing about a consistent brand and user experience.

But let’s face it, the name is pretty flat. It lacks the sparkle of design systems such as Material Design, Origami, and Primer, which are not just pretty names, but great metaphors for what the systems aspire to do.

Our system was based on interconnected blocks, sharing code, and building on top of the base. When we started thinking of a new name, Honeycomb was a natural choice, and where people easily forgot ISW, Honeycomb stuck. It was sweet.

Our websites are a small part in our customers’ journey, and there was another team looking at the experience across a much wider range of touch points, through our websites, installers, product UIs, email notifications, etc.

Honeycomb has consequently become the framework for all design, across our many channels, unifying our contact with our customers into one seamless Redgate experience. A design system owned by all of us, that defines what a Redgate experience means for a customer, whether they’re reading a document, using a product, or browsing our website. It will enable us to focus our design capacity on areas that can push our apps to be even better, rather than reinventing the wheel. And it will aim to provide a frictionless and enjoyable experience to our users.

So don’t think ‘Ingeniously Simple Web’. Think Honeycomb. And don’t think Honeycomb = web. Honeycomb’s a system for everything we do – products, websites, posters, you name it. You’ll be hearing a lot more about it in the future, and you – and our customers – will be seeing the advantages everywhere.