Author Archives: Joe Saunders

“What CMS?” is the wrong question

When I meet new customers, I often relate a story about CMS work.

It goes like this:

A decade or so ago, CMS projects used to make up the majority of Isotoma’s output.
These days the number is much lower. There are a few reasons for this but the main one is that back in the day, CMS work used to be hard. The projects were complex, expensive and fragile.
As an illustration of how much things have changed, the other day I built a website for my sister’s business using Squarespace. It took longer for me to upload photos to the gallery than it did to plan, build, populate and deploy the entire site.

This peppy anecdote disguises the fact that there is complexity still in CMS work; projects that involve content management have the ability to stymie organisations and put their digital roadmap back years – but almost all of this complexity resides outside of CMS platform choice.
This post looks into why that is.

“What CMS should I use?” is a boring question.

People still tend to start with the question “What platform are we going to use?” because, historically, it’s been a really important one. Back in the day, progress was slow and the costs of being wrong were astronomically high.

These days though, compared to some of the other decisions you need to make, platform choice is a relative doddle.

Why do I say this? Because the CMS market is commoditised, modern and highly competitive.

  • There are free/open source solutions that are as good as (or better than) anything you pay through the nose for
  • There’s a huge number of agencies who will compete with each other for your business and this keeps prices constantly low
  • The majority of features you could ever want from a content management system are now standardised and distributed across the marketplace. Anyone telling you otherwise is selling you something
  • As features increase; costs shrink. As costs shrink, the traditional organisational worries about sunk costs and having a product that’s wrong become less important

Indeed from a given list of modern, open source content management systems, you’d have to be going some to get a bad fit for 99% of organisations.

So having made a broad and eye-catching statement like that, let me now run through a brief list of actual interesting questions to ask about your CMS project.

1. What is my content strategy?

Back in the day, agencies would be asked by their customers “Will the section headings be editable by admins?” and then we’d go to quite a lot of trouble to make sure that the section headings were in fact editable by admins.

What agencies should have been doing instead was investigating why the section headings needed to be editable in the first place.

If you nail the content strategy – if you develop content and a structure that speaks to the requirements of your actual customers – then the need to make structural changes to your site should be, while not removed entirely, at least put on a slower and more predictable timetable.

2. Who is driving this project?

This is somewhat related to content strategy but deserves its own section. One of the reasons that a content strategy is needed is that the fundamental question “Who is the audience for this site?” can have multiple, arguably correct answers depending on who inside the organisation you ask.

And sometimes the reason that you have multiple answers to the question is because two (or more!) departments or individuals within the customer’s organisation have competing opinions about the fundamentals of the project: what it’s for, what the outcomes and priorities should be… etc.

Resolving these tensions can be difficult, even for members of the customer’s team. For employees of an outside agency the difficulty increases exponentially but, worst of all is when an attempt is made to solve a problem like this with the top down application of a technology choice. Drupal has many skills but senior management negotiation is not one of them.

3. Who are the audiences for this new CMS?

Is this a site made to make the company look attractive to customers? Or is this a site that is designed to make an internal task easier for the admins of the site? Or both? None of these answers are wrong but failing to ask the question can result in tens of thousands of pounds being spent on something of little demonstrable value to the customer.

So in summary then…

Asking the above questions is a far better use of your time in the run up to starting a project than asking questions about Wagtail vs WordPress.

You can take this one step further and use the same approach in selecting an agency: When you first engage with them, do they talk about the platform and technology choice or about how they’re going to help you increase your reach, or implement a content strategy? Or how they’ll help affect change within your organisation?

We’re on the Government G-Cloud 9 Marketplace

Good news, everyone! Isotoma are pleased to announce that our services are now available to public sector bodies for procurement via the G-Cloud 9 portal.

This means that you can find Isotoma’s services on the Digital Marketplace including cloud hosting, software and support. The Digital Marketplace is the new online platform that all public sector organisations can use to find and buy UK government approved cloud-based services.

We already deliver our services to organisations around the world. With this new accreditation, Isotoma is ready to deliver our best-in-industry services to even more public sector bodies.

Here’s an outline of the Isotoma services available on the G-Cloud 9 Digital Marketplace. Don’t hesitate to get in touch if we can provide more info.

Why the hell is my project over-running?

As a project manager, I rank a C+ at best. That’s why I work in sales where the damage I can do is more limited. However, where I differ from a lot of not-very-good project managers is that I know exactly how bad I am and am happy to share my hard won experience with you all. Lucky old you, eh?

The topic for today is the most-asked question in agencies up and down the land: Why is my project over-running and what can I do about it? (It’s kind of a companion piece to Andy’s previous post “How do I know my developers are on track?”)

One of the reasons why this question is so often asked is that it is a defining feature of so many digital projects. Managing overrun is often one of the key tasks of any senior management team within an agency. This blog post is an not an attempt to exhaustively catalogue all the reasons why it happens. Instead I thought it’d be useful to discuss some of the less discussed reasons.

Let’s start with an easy one:

The estimate wasn’t an estimate

There are as many ways to generate an estimate as there are uses for that estimate. All bodies will develop their own idiosyncratic approach and – fun! – multiple approaches to estimation can also exist within an organisation at one time.

This tendency often leads to confusion or amnesia about what the estimate was for in the first place. Two extreme examples here are an internal estimate of developer effort and an estimate of price meant for an external, customer audience. The developers might estimate, say, a 6 week build for a given feature At the same time, for reasons of political expediency, you might only want to charge for 4 of those.

There’s nothing necessarily wrong or even surprising about a calculation like that, but it’s vitally important that you have the organisational memory to remember that the devs need 6 weeks in the resource planning and reporting areas of your business. In a month’s time when you’re looking back on the project and reporting its profit/loss, what tools are available for you to track this information beyond your fallible, over-worked brain?

How much are you losing to churn?

There are countless posts on the damaging effect that context-switching can have on a development team. If you’re delivering work into a team of generalist developers who are having to switch from one project to another over the course of a day, then you’re going to be having an impact on productivity from the get go. I can think of countless examples from my day to day life where an hour of timesheeted development somehow managed to cost a whole day of my precious budget.

So we all instinctively know this – but what I see agencies do again and again is both fail to develop tools and processes to compensate for this tendency *or* build any of this into planning. Spending time and resource developing ways to automate the build/deploy process, for example, can save a ton of tooth-grinding right at the most stressful moment of the ‘task-switching’ process.

The only other solution is to plan projects sensitively enough that the plans take into account the workload of other projects and/or assign an amount of ‘dead time’ to a developer on the assumption that they’re going to be doing nothing profitable for a proportion of the project.

From a commercial point of view, this is a more or less indefensible position. From a practical point of view it borders on the hilariously implausible. (Show me an agency with a resource planning horizon of more than 4 weeks and I will show you the authors of the greatest work of fiction the world has ever seen.)

And speaking of which…

Your developers have an outside-context problem?

This is really common across the industry but is particularly true where you’ve got a team of middle-weight generalists – which is where dev teams in marcoms agencies naturally tend to gravitate.

The problem goes like this: The client asks for something new. You’ve never built it before but you’ve built something like it. The team diligently estimate the project based on the thing you’ve built before and everything is going fine until, suddenly, horribly, it isn’t. The differences that seemed so small from a distance are, up close, suddenly yawning and irreconcilable. This thing isn’t like the other thing at all. This thing is like nothing the team have seen before. It’s an outside context problem; outside the context of the team to estimate, deliver or support.

And now, not only are your estimates wrong, but you’re two thirds of the way through the budget and three quarters of the way through the allotted time.

There are a number of related issues here – and they really need to be unpicked in a longer post – but briefly it can be incredibly difficult to spot these things before you’re in their grip.

The short-term obvious preventative here is to review progress against budgets religiously and provide your teams with enough space and time to estimate properly in the first place, however there is a more long term and harder to spot solution too.

You need to foster an internal atmosphere where teams can feel both empowered enough to speak up when things are going wrong and can be sensitive enough to human weakness to know when “I don’t know how to estimate this” is the only correct answer.

In my experience, even senior devs can have a tendency to nail themselves to the crosses they manufacture in the project initiation stages. (I’ve seen management help make these crosses too.) In a healthy company there should be no need for this.

Get help

Watch now, reader, as I pivot effortlessly into an advert for my company’s services here: Mid-sized, mid-weight dev teams are, by their nature, prone to making the kinds of mistakes outlined above; it’s the downside of fast-moving, flexible team.

As a software agency of some 13 years age, we have seen pretty much all the ways that a digital project can go wrong and we’re happy to use this knowledge to help make sure that yours don’t. Our team of developers and project managers is experienced and mature enough to be able to give accurate, actionable advice that will be good for the duration of the project.

If you want to give us a shout email me, Joe or pop along to our contact page.

When to WordPress; When not to WordPress.

We like Postlight. They’re really good at talking about the reasons they do things and exposing these conversations to the world. In Gina Trapani’s recent post (Director of Engineering at Postlight), she gives some really useful advice on when and when not to use WordPress.

I thought it’d be useful to delve into this topic a little and expose some of the conversations we’ve had at Isotoma over the years. We’ve done a lot of what you might call ‘complex content management system’ projects in the past and, as a matter of policy, one of the first things we do when we start talking to potential customers about this kind of thing is ask “Why aren’t we doing this in WordPress?”

This is one of the most valuable questions an organisation can ask themselves when they start heading down the road to a new website. Trapani’s excellent article basically identifies 3 key reasons why WordPress represents excellent value:

  1. You can deliver a high number of features for a very low financial outlay
  2. It’s commoditised and therefore supportable and by a large number of agencies who will compete on price for your business
  3. It’s super easy to use and thus, easy to hire for

Complexity issues

For us though, there’s a more implicit reason to ask the question ‘Why not WordPress?’
The more customised a software project is, the more complex it becomes. The more complexity there is, the more risk and expense the customer is exposed to. Minimising exposure to risk and reducing expense are always desirable project outcomes for everyone involved in the project – though that’s rarely an explicit requirement.

So all of a sudden, just understanding these issues and asking the question “Why aren’t we using WordPress?” becomes a really valuable question for an organisation to ask.

Good reasons not to choose WordPress

Through asking that question, you’ll discover that there are many valid reasons not to use WordPress. I thought it might be illuminating to unpack some of the most frequent ones we come across. So I thought back to projects we’ve delivered recently and teased out some reasons why we or our customers chose not to use WordPress.

1. When the edge case is the project

If you overlay your CMS requirements onto the features WordPress offers, you’ll almost always find a Venn Diagram that looks a lot like this:
wordpress-Venn

The bits that jut out at the side? That’s where the expense lives. Delivering these requirements – making WordPress do something it doesn’t already do, or stop doing something it does – can get expensive fast. In our experience, extending any CMS to make it behave more like another product is a sign that you’re using the wrong tool for the job.

In fact, a simpler way of thinking about it is to redo the Venn diagram:

wordpress-venn-02

If you can cut those expensive requirements then fantastic. We’d always urge you to do so.
But ask this question while you do:

What’s the cost if I need to come back to these requirements in 18 months and deliver them in the chosen platform?

  • Is it hard?
  • What kind of hard is it?

Is it the kind of hard where someone can tell you what the next steps are? Or the kind of hard where people just suck their teeth and stare off into the middle distance?

The difference between those two states can run into the thousands and thousands of pounds so it’s definitely worth having the conversation before you get stuck in.

If you can’t get rid of the edge cases; if, in fact, the edge cases *are* your project, then we’d usually agree that WordPress is not the way forward.

2. Because you need to build a business with content

We’ve worked with one particular customer since 2008 when they were gearing up to become a company whose primary purpose was delivering high quality content to an incredibly valuable group of subscribers. WordPress would have delivered almost all of their requirements back then but we urged them to go in a different direction. One of the reasons we did this was to ensure that they weren’t building a reliance on someone else’s platform into a critical area of their business.

WordPress and Automattic will always be helpful and committed partners and service providers. However, they are not your business and they have their own business plans which you have neither access to or influence on. For our customer, this was not an acceptable situation and mitigating that risk was worth the extra initial outlay.

3. Because vanity, vanity; all is vanity

There is nothing wrong with being a special snowflake. Differentiation is hard and can often be the silver bullet that gets you success where others fail. We understand if there are some intangibles that drive your choice of CMS and broadly support your right to be an agent in your own destiny. You don’t want to use WordPress because WordPress is WordPress?
Congratulations and welcome to Maverick Island. We own a hotel here. Try the veal.

Seriously though, organisational decision making is often irrational and that’s just the way it is. When this kind of thing happens though, it’s important to be able to tell that it’s happening. You should aim to be as clear as possible about which requirements are real requirements and which are actually just Things We Want Because We Want Them. Confusing one with the other is a sure-fire way to increase the cost of your project – both financial and psychic.

If you want to know more about migrating CMS’ and the different platforms available, just contact us or send an email to hello@isotoma.com. As you can probably tell, this is the kind of thing we like talking about.

4 Times That The Misery Of Creative Agencies Made Me Happy

Clickbait titles are fun, but bear with me, good people. I’m trying the make a point.

This report was wafted under my nose the other day. It makes for depressing, but not terribly surprising reading. The first paragraph pretty much nails it:

Anyone who’s spoken to me in a professional capacity for the last 3 months will probably recognise that Smith & Beta’s report is quantitative confirmation of what I’ve been going on about for ages. Each one of these makes me sad – but also, because I am a shallow, vapid person, I still get to feel happy that I’m right.

1) Good quality creative requires good quality technical implementation

Agencies lead with creative vision and lean on technical skills (internal & external) to deliver this vision. No one ever won a pitch by saying that the creative will be a strong C+ but it’s going to be implemented really well. Sadly, the opposite is almost always true. The industry is generally OK with taking an amazing creative idea and delivering it late, over-budget and on top of a pile of bodies of fallen colleagues.

2) This technical resource – where it exists within an agency – is often siloed and over-committed

Because of the way the creative industry works, creative resource is always going to be an expense the agency is happy to invest in. Investing in technical resource however; is a more expensive, slower, trickier business.

Similarly, investing in older, more skilled resource is always going to be a harder sell when there are countless thousands of young and exploitable juniors clamouring for your attention.

An agency trying to walk the line between capability and capacity in order to really call themselves “Full Service” will end up with a safe but middle of the road offer. Conversely, an agency who shoots for the moon and invests in highly specialised and/or highly senior team may find that they’ve painted themselves into a very expensive corner.

3) It’s hard to hire your way out of this problem

I mean, duh, obviously. It’s hard to hire your way out of any problem. Recruitment, training and increasing retention are sloooooow processes. And the problems that this report outlines are problems of the now.

(Side-note: In my role here at Isotoma, I often end up talking to agencies about projects that we can collaborate on. I’m usually talking about projects that might be coming up in, say, 6 months, but people actually want help RIGHT NOW.)

4) These problems when considered together, reduce the satisfaction of the customer and shorten the lifetime of the account

As abusive as the client/agency model can be, there’s a satisfyingly stark bottom line to it: “Do good work; get more work.” Note that this is distinct from “Pitch good creative; get more work.”

As I said above, no one ever won a pitch for outlining a competent implementation plan, but once the project is over and the smoke settles, the customer doesn’t just remember the pitch.

(If you’re really unlucky, the people who were in the pitch don’t even work for the customer anymore…)

The knife edge that a marcomms agency has to walk is being able to deliver creative vision *and* technical competence in a way that doesn’t fundamentally alter what the company is. Go too far in one direction and you’re unable to deliver anything profitably, go too far in the other and you’ve magically become a company that you don’t want to be.

So this is one of the reasons that Isotoma do what we do. We’re already a technical agency. We’re already geared up to help you estimate, deliver and, crucially, support a creative campaign. We’re good partners. And the better we get at ploughing this particular furrow, the better we’re able to help and complement agencies who’ve chosen to plough another.

And that makes me happy.

(See? I was being cynically provocative to attract clicks. And the pug at the top? The cherry on the cake, my friend. Truly I am a monster.)

 

The Key – back-fitting responsive design (with exciting graphs!)

As an industry we talk a lot about the importance of responsive design. There are a lot of oft-repeated facts about the huge rise in mobile usage, alongside tales of woe about the 70,000 different Android screen resolutions. Customers often say the word ‘responsive’ to us with a terrified, hunted expression. There’s a general impression that it’s a) incredibly vital but b) incredibly hard.

As to the former, it’s certainly becoming hard to justify sites not being responsive from the very beginning. 18 months ago, we’d often find ourselves reluctantly filing ‘responsive design’ along with all the other things that get shunted into ‘phase 2’ early in the project. Nowadays, not so much: Mailchimp reported recently that 60% of mail they send is opened on a mobile phone.

For the latter, there’s this blog post. We hope it demonstrates that retro-fitting responsive design can be simple to achieve and deliver measurable results immediately.

And, because there are graphs and graphs are super boring, we’ve had our Gwilym illustrate them with farm animals and mountaineers. Shut up; they’re great.

What were the principles behind the design?

We’re not really fans of change for change’s sake, and generally, when redesigning a site, we try to stick to the principle of not changing something unless it’s solving a problem, or a clear improvement.

In this redesign project we were working under certain constraints. We weren’t going to change how the sites worked or their information architecture. We were even planning on leaving the underlying HTML alone as much as possible. We ‘just’ had to bring the customer’s three websites clearly into the same family and provide a consistent experience for mobile.

In many ways, this was a dream project. How often does anyone get to revisit old work and fix the problems that have niggled at you since the project was completed? The fact that these changes would immediately benefit the thousands of school leaders and governors who use the sites every day was just the icing on the cake.

And, to heighten the stakes a little more, one of the sites in the redesign was The Key – a site that we built 7 years ago and which has been continually developed since it first went live. Its criticality to the customer cannot be overstated and the build was based on web standards that are almost as old as it’s possible to be on the internet.

What did we actually do?

The changes we made were actually very conservative.

Firstly, text sizes were increased across the board. In the 7 years since the site was first designed, monitor sizes and screen resolutions have increased, making text appear smaller as a result. You probably needed to lean in closer to the screen than was comfortable. We wanted the site to be easy to read from a natural viewing distance.

We retained the site’s ability to adapt automatically to whatever size screen you are using, without anything being cut off. But this now includes any device, from a palm-sized smartphone, to a notebook-sized tablet, up to desktop monitors. (And if your screen is gigantic, we prevent lines from getting too long.) The reading experience should be equally comfortable on any device.

On article pages, the article text used to compete for attention with the menu along the left. While seeing the other articles in the section is often useful, we wanted them to recede to the background when you’re not looking at them.

We wanted to retain the colourfulness that was a hallmark of the previous design. This is not only to be pleasing to the eye – colours are really helpful in guiding the eye around the page, making the different sections more distinct, and helping the most important elements stand out.

Finally, we removed some clutter. These sites have been in production for many years and any CMS used in anger over that kind of period will generate some extraneous bits and bobs. Our principle here was that if you don’t notice anything missing once we’ve removed it, then we’ve removed the right things.

What was the result?

The striking thing about the changes we made was not just the extent of the effect, but also the speed with which it was demonstrable. The following metrics were all taken in the first 4 weeks of the changes being live in production in August 2014.

The most significant change is the improvement in mobile usage on The Key for School Leaders. Page views went up – fast (and have stayed there.)

total-page-views1

 

Secondly, the bounce rate for mobile dropped significantly in the three months following the additions:

bounce-rate

Most interestingly for us, this sudden bounce in mobile numbers wasn’t from a new, unheard of group of users that The Key had never heard from before. The proportion of mobile users didn’t increase significantly in the month after the site was relaunched. The bump came almost exclusively from registered users who could suddenly now use the site the way they wanted to.

proportion

 

A note about hardness

What we did here wasn’t actually hard or complicated – it amounted to a few weeks work for Francois. I’ve probably spent longer on this blog post, to be honest. And so our take-away point is this: Agencies you work with should be delivering this by default for new work; should be proposing simple steps you can take to add it for legacy work or explaining why they can’t or won’t.

About usIsotoma is a bespoke software development company based in York and London specialising in web apps, mobile apps and product design. If you’d like to know more you can review our work or get in touch.

Hacking together a standing desk

We’ve had a few people in the office transition to standing desks recently and the process by which everyone achieved their goal has been quite interesting. Or at least interesting to me.

doug's deskDoug was the first to try it and ended up, as a lot of people do, taking the old ‘big pile of books’ approach. It’s cheap, quick and,so long as you’re using a solid and non-tottering pile of books, probably pretty safe. Luckily the Isotoma office has a pretty extensive library of books–which in Doug’s case have mostly been memorised.

(I wouldn’t let him tidy his desk before I took this photo. He wanted me to tell you.)

A different approach that David introduced (as far as I know) and which I’ve adopted is the music stand approach. It’s a wee bit more expensive and depends on you having the kind of job that doesn’t really involve paper or double monitors – but I love it. The bonus of this approach is you get to feel a little bit like a member of an nineties synth-rock band. Always a bonus.

But the canonical Isotoma standing desk was “Ikea-hacked” together by Tom. He went to town on it to such an extent that we made him do an intranet post about it:

I’ve had a couple of enquiries about the parts for my standing desk, so rather than send sporadic emails, I thought I’d just put it here.

8717637419_6b5bfa4fa8_o8717637485_65832cd578_o

I built my standing desk based on this article, which is great, and has assembly instructions and everything (although it’s pretty trivial to put together). The guy bought all the bits from IKEA for $22. But obviously we don’t live in America, and also I needed to double up on some of the parts due to my dual monitor setup, so here is the full parts list, with links to the UK IKEA website:

Also, you will need to find 4 screws to screw the brackets into the table legs because annoyingly, the brackets have holes drilled, but no screws to go in said holes.

Grand total: £29 (including £10 postage)

Oh and don’t forget, you’ll probably want some kind of chair to give your legs a rest every now and then (yes it’s hilarious that Tom still has a chair etc, but it does come in handy, even if it’s just for 2×30 minute spells during the day). I got a bar stool with a back from Barnitts 🙂

This concludes my blog post about standing desks. Please add photos of your sweet, customised desks below in the comments.

Just kidding.

About usIsotoma is a bespoke software development company based in York and London specialising in web apps, mobile apps and product design. If you’d like to know more you can review our work or get in touch.