When we decided to update our company website, we wanted a site that shows our customers what we can do. With the help of Andy Clarke and the team at Stuff and Nonsense, we truly believe we've managed it.
Apart from a new brand and design, we've also had a radical rethink about site content and how we create it in Drupal. This article explores the rethink by talking to the designers, developers and editors responsible for building the new site.
Andy Clarke explains how and why Stuff and Nonsense went about redesigning the Code Enigma brand
Why did you take on Code Enigma as a client?
Really, really, we love working with people who are excited and enthusiastic about what they do. From the first time we spoke with Code Enigma, we knew that they’d be active participants in the design process. We also appreciated that Code Enigma made it clear that we had an open creative brief and that they’d no preconceived ideas or answers. This allowed us to think freely and ultimately resulted in a better, more creative and distinctive design.
What were your initial thoughts about Code Enigma’s ideas for the new site?
Like many companies—inside and outside the Drupal industry—Code Enigma’s previous website was written from their perspective and about what they do for clients. We think that it’s important for clients to identify with the experiences told in the stories that they read, so we wanted to base the structure of Code Enigma’s new website around those stories. We also felt that Code Enigma’s branding would benefit from a visual refresh, so we created an updated logo mark and colour palette and chose Omnes Pro from Brooklyn-based type designers Darden Studio to use across the new branding and website.
What did you see as the biggest challenge / hurdle to get over in order to encapsulate your and their ideas?
Although you might expect that the biggest challenges for a redesign like the one we worked on with Code Enigma would be creative or technical, the biggest issue is always writing good content. Code Enigma understood this and we were thrilled that they dedicated time and people to the task of writing content.
How did you set about the project?
We often start by designing the ‘atmosphere’ of a website or application, the colour, typography and texture that makes a design uniquely Code Enigma’s. We created a ‘design guide’ — think of this as a style guide, made at the beginning rather than at the end of the project — containing designs for all the content and functionality elements. The design of these elements will transcend layout and will appear the same on everything between smartphones and PCs.
We created look-and-feel designs, and flexible layouts that adapt to the capabilities of many devices and screen sizes. We created designs iteratively, predominantly using HTML and CSS in a browser, so we didn’t waste time mocking up every template as a graphic. Our design and development process was fluid and we moved constantly between designing flat visuals using graphics tools to writing HTML and CSS code and back again as we iterated.
How was it working with their in-house designer?
We knew that Code Enigma are experts with Drupal, but we weren’t prepared for how knowledgeable and experienced Code Enigma’s own designer/front-end developer Matt Fielding would be. Not only did Matt make an exceptional job of turning our ‘design code’ in to production code, he also implemented our design in ways that we hadn’t imagined and added interactive touches that bring our design to life.
What do you think of the results now the site is live?
There’s always a tense moment when you see a client’s implementation of a design for the first time, but with Code Enigma, we needn’t have worried. We’re very proud of the finished website and we can’t wait to add it to our portfolio and to write on our blog about the work that we made.
We needed the money. No, seriously, we really needed the money.
(Andy's alternative answer to why he took the job.)
Greg Harvey explains the content strategy that dictated technical requirements
We started out looking at other websites our competitors had up, but we quickly realised that while a lot of them were very nice, they all pretty said exactly the same thing. "We're great at Drupal, lots of people use us, read our blog..." That is pretty much the format. We didn't want to make just another website by another Drupal company telling the world we're really good at Drupal. In fact, we don't think that's even what matters to our customers.
My experience of working at Code Enigma, and even prior to that — since I've been in Drupal really — is that this business is all about relationships and how you interact with people and organisations. So we figured let's try to capture that. Let's turn the telescope. Instead of telling the world we're good at Drupal, because that ought to be a given with our page on Drupal.org, our team, and so on — instead let's get our customers to tell the world how we're good at helping them deal with solving complex business problems with free open source software. Let's get our customers to talk about their relationship with Code Enigma and why that's valuable to them. Because that's what we really do. We build understanding so we can go on to solve problems, it just happens we tend to mostly use Drupal to solve those problems.
The other thing we didn't like about our old site was that it was so heavily templated. Now the bizarre thing here of course is that templating content is what CMS's do, so fighting against that is tough — maybe even stupid — but we couldn't react with the old site. The structure was too rigid, the way things were laid out made it really hard make journeys, to curate pages and content. Everything felt very dry and automatic, because it was. With the new site we wanted to move away from that, we wanted minimal structure and total control. We didn't want the CMS to dictate what was on the front page, how people navigated the site, what was drawn to the front, we wanted total editorial control over all that so we could plan the experience. Maybe for a specific event, maybe to plug a particular service for a month or two — but we wanted the site to be fluid, and live and change, without needing a developer to come and alter Views in code or whatever.
I think the site has totally realised what we wanted. Andy did some lovely base work with the brand and a load of great templates, Matt made them work with pretty much any device you can think of (he has a house full!) and he also developed them a bit, creating new sections as we needed them, tweaking here and there where implementation was tricky. And Pascal has made a fantastically flexible Panels-based system in Drupal for us to pick and choose our templates and sections at will, it does exactly what we wanted.
Is it easy to use? Hell, no! What we asked for was crazy! We asked someone to take a CMS and remove any concept of pre-templating and let us just choose from a bunch of styles and layouts a designer came up with, mix and match infinite combinations, reverse colours, change logos, it's bonkers. But Pascal made it work and I'm really happy with the resulting site. It combines some pretty bleeding edge Panels in-place-editing stuff with the "Planer" work (based on Semantic Panels) that Matt and James pioneered, which is what allows it to be so flexible. That's also why it's a bit painful to edit, but that's because we made it that way. It's exactly what we asked for. We decided we wanted every page to be a delicately crafted thing, now we have to get crafting. I'm fine with that, I have the tools, I'm a happy chap!
Essentially, I guess once you've made the decision that your content must be fabulous, and you must invest the time in good photography, interviews, really think about layouts, how they hang together (look closely, this site even has a concept of facing pages — that was Andy!) you basically have to accept there are no quick wins any more. There is no "throw it up there". Because that would be crying shame. So the interface matters less, you're going to spend a chunk of time making it perfect whether the interface is clunky or not. Laying out beautiful pages just takes time.
Will we re-use it? That's a good question. I can imagine some of our customers would just *love* this system. Others would get themselves in a total mess in no time. Others still would watch a demo, hate it and demand it be taken outside and shot. I think the answer is yes, we should totally re-use it, but we should only apply it where we're talking about use cases *exactly* like ours - high visual polish, total editorial control, small amounts of content being generated, editors with lots of time to spend to get it perfect, and people who really care about the quality of their content. Otherwise it's wasted and probably inappropriate.
If you have a boutique magazine site, for example, that produced reasonably low volumes of content but had design-savvy editors with time to spend and the want to make perfect pages, this system is just brilliant for you. It would also power image-driven sites like The Great Discontent perfectly, which is no surprise, as we drew a lot of information from that site — we love the format. You get the idea. There's potential here, it puts the power of responsive web design into the hands of people like Steve and I, who know almost nothing about it, and allows us to actually do a pretty good job of producing really good looking pages, which is quite amazing if you think about it. But it's not for everyone in its present form.
That said, one of the really cool things about it is the way you can build a page and then say "hey, keep this one, I like it" and have it for a template later. I think there are components there that, in the future, could be really powerful. The ability to let one role fiddle with structure and have another role only able to choose preset layouts and do in place text and photo editing — that's really interesting. It basically gets rid of the need for content types entirely, which is ground-breaking stuff. So I don't know — watch this space!
What was the brief you were faced with?
It wasn't a very long nor very complicated brief at first sight. We wanted to import some of our old content, but mainly it was about re-starting from scratch. The tricky part was the flexibility requirements: each piece of content could be using its very own custom layout, while still retaining the right markup to fit in the style and grid provided by the prototype that was built from the designs.
What did you think about it?
My first reaction, half-kidding, has been more or less 'Well, just use an html editor, you'll get all the freedom you need'. More seriously, I could foresee some troubles with so much freedom in content editing, both on the technical and editorial side. But we were all aware of it from the beginning, and knew there was a risk of falling into the 'wysiwig' syndrome.
How did you get the idea for how to solve the technical challenges?
I'm a big fan of Panels (and ctools-based tools in general), so Panelizer had been my first choice. However, it didn't quite fit our needs as is, so we gathered with other members of the team to explore the possible solution we had. Several ideas were thrown around, amongst which notably was creating some custom plugins to use within a wysiwyg editor and be able to build the entire page from there. In the end, a panels-based approach still seemed the only most suitable to everyone so that we could give maximum flexibility whilst still respecting the semantic markup produced by Andy and Matt.
Coincidentally, I was working, as part of my 'Labs days' at Code Enigma, on a panels 'flexible' layout. My initial idea was to have something very similar to the 'builder' layout provided by panels, but without any notion of columns or rows, replacing those with placeholders/wrappers that could be styled to anything, be it semantic html or no markup at all. So I through that in the mix too, and it evolved into a kind of In Place Editor.
What were the biggest headaches?
There's been quite some technical challenges, and I had a lot of fun! One of the tricky parts has been to get all of the 'main' modules to work together : internationalization, revisoning and panelizer are known not to play well together. I ended up with a mix of i18n, ERS and Panelizer, all "glued" together by some fiddling at presave time. But the most difficult is directly tied to the flexibility requirement: as you need to be able to add as many components as needed to the node, but we still wanted to use nodes The solution has been to only use one field of each needed type (text, image, entity_reference, etc), all set to an unlimited cardinality. That was deliberately looking for troubles!
For example, it led to huge problems in image handling: be it the core image module, media or visual select file, all existing modules had the same caveat of using a custom handling of 'multiple' fields. However, the way I ended up setup the pseudo in-place editing of content required to be able to edit each individual field item separately. It also meant we couldn't use FAPE, as it only acts on the whole entity content.
What you'd like to see on the roadmap?
There are some obvious bits: the current editor-side solution needs some improvements both in terms of UX and performances. Feedback and feature requests are welcome. But the main action to take now, I think, is step back a bit, and see what can be contributed back: there are some parts that probably belong to patches to contrib modules instead of custom code, e.g. the glue between Panelizer and ERS, I know from the issue queue we're not alone there. ;-)
So I'd like to refactor properly the main custom modules, and see what could be deferred to existing projects and what could constitute a project by itself.
What challenges did you face converting Andy's design prototype for use in Drupal?
I could have continued using Hammer as Andy did but I preferred to use Middleman. It offers more out the box functionality such as optimising images, use auto-prefixing scripts, and it works really fast. I can see impact of changes really quickly because Middleman is running its own server:socket so I can connect and refresh really quickly. So that meant a certain amount of refactoring.
I also had to be sure that whatever is being built will run on iPad, iPhone, multiple browsers, and other devices so there was loads of testing using virtual machines, hardware devices like Android, plus I’ve got three iPhones, two iPads, and a Samsung Galaxy. Having my own setup makes it easy to do continuous testing. Admittedly, the responsive breakpoints are based around content rather than devices as such but you still need to test on popular view ports.
I rewrote the CSS into a different structure to be SMACSS/SASS compatible. Essentially the model is base styles, resets, layouts, modules, components, partials. Then I stripped out the gridset with hardcoded percentages and rebuilt using Singularity, writing a partial file for the grid system. With a very modular grid system it makes it easy to re-use in different ways. For example, we don’t want a three col and a four col page. Editors can actually choose grid for the content and then they can flip the grid by just adding a couple of classes. Throughout I was also trying to do this with as little markup as possible so I removed quite a few classes.
Adopting a rigorous approach meant changing the semantics for how the header works so that the banner belongs to the article rather than being a page furniture component. CSS checks if there’s an image and changes padding etc. to allow for editors deciding on a page-by-page to do without banners.
The system is incredibly flexible because Pascal has done an amazing job following the style guide and design patterns I provided. Throughout it uses class names to avoid visual assumptions and stay content oriented, although editors can override these within the interface using styles such as “narrow sidebar”.
The other technical challenge was how to achieve wedge shaped images. Only SVG allows razor-sharp line and we can’t get all images in that format so we use CSS for a background image with fallbacks for older browsers.
Looking forward I want to improve responsive image handling, think about how we search and surface content, and look for more optimisations around page-weight. On the edit side I think we can improve the interface around Panels to give a nicer user experience for editors.