In the web design industry, developers have gained an unfortunate stereotype of being grumpy, overly-pragmatic naysayers, especially towards their designer counterparts. If you’re a designer, you’ve probably had the experience of coming up with a brilliant interaction for a site, only to have your hopes and dreams dashed when you consult the nerds tasked with building your masterpiece. Even the simplest of requests – like vertically centering some copy – seem to aggravate these cynics.
So, why do developers always say no?
Chances are that they have very legitimate reasons, but often these reasons are quite technical and difficult to explain. That being said, it’s very important for designers (and also managers!) to understand on some level the reasons why their brilliant ideas are being vetoed. It’s my goal here to close this knowledge gap between professionals. I’ll be focusing on web developers specifically, but most of these principles apply to all realms of programming.
Dear Developers – Stop Hatin’
Before I defend my fellow developers, I first need to call them out. In situations where a new feature is asked to be built by a non-developer, it can be quite easy for tempers to rise, egos to inflate and nerves to be strained without proper management of expectations. When we operate from such a defensive place, our gut reaction is to just say no.
But quite often, developers don’t know whether something is possible or not. It’s important in these moments to slow down and think.
There are a number of reasons (which I will go into shortly) as to why something might not be worth exploring. However, as a developer, it is worth letting the inquirer know exactly what constraints you might face, as well as all unknowns. This provides them with the best information, sets realistic expectations and abates adversarial responses.
With that noted, let’s examine the top 5 reasons why web developers say no.
Browser Compatibility
You saw this one coming, didn’t you? Not all browsers are created equal, and it’s never possible to have websites always look and operate exactly the same across the board. However, using the practices of graceful degradation, we can make websites look passable on outdated, less awesome browsers, albeit not the same.
Sometimes developers will turn down something because it’s not possible to pull it off in older browsers that they’ve been asked to support, and the alternative solution would require quite a bit of work. It’s important to know what browsers the majority of your visitors will be using, as support for these older versions often increases the level of effort for a project. If your target audience is not technically savvy or at a disadvantage technology wise, you might not want to skip the IE 8 support.
Scalability
Developers only write code for two people: themselves today, and themselves six months from now. Sometimes while a feature proposed sounds like a great idea, the amount of effort needed to make it scalable can be extremely involved. Sure, they could pull if off with a simple hack right now, but what about months down the line when managers are asking them to expand on it? Will it be a good solution then too?
JavaScript
Specifically talking about the front-end world, a lot of conflicts arise between designers and developers due to the amount of CSS and or JavaScript necessary to pull something off. These days, a lot of cool interactions are possible with CSS alone, which is almost always preferable, because it means less code. Because my aim with this blog post isn’t to deter designers from coming up with awesome ideas, here are some cool things that can be accomplished with CSS3 in modern browsers:
- Transitions
- Transformations (including 3D)
- Animations
- Gradients
- Dropdown Menus
- Image Blurring
- Text Blurring
- Text Shadows
- Box Shadows
CSS, while definitely code, is not a programming language. It lacks the power of a more complex language, and thus is limited in what it can accomplish. When styles alone can’t get the job done, JavaScript swoops in to the rescue. Adding JavaScript to a website can complicate things and increase the time needed for a project.
So how are you the designer supposed to know when something is complicated or not? While you can’t be expected to understand the in’s and out’s of code enough to estimate the level of effort required, here are a few things to keep in mind:
How Difficult is my Interaction?
All interactions are triggered by certain events. On the web, there are four main events that can trigger any given interaction:
Hover
Anything that needs to be triggered on hover can be accomplished with CSS alone, and while the typical usage might be a simple color change, you can get really creative with this. Tool tips and dropdown menus are some of the more complex ways of using hover events, but you can get pretty inventive, such as in this accordion style slider. Pretty much any combination of the above techniques can be used to create beautiful, fun hover effects.
Click
With a couple of exceptions, you can’t rely on CSS alone to build an interaction triggered by a click. This would include clicking on a link or button to reveal new content (without the page refreshing), clicking through an image slider, triggering a modal or lightbox gallery, etc, would require some JavaScript.
Resize
To clarify, this event generally refers to when the browser window is resized. This event is most handy when creating responsive solutions. CSS has a built in tool called media queries which create rules for how things should look at certain window sizes. So if on smaller screen sizes you want things to shrink and look differently, CSS is a great and simple solution to that.
However, if the changes you’re looking for drastically change the arrangement of the HTML elements on the page, you’ll need JavaScript to do the dirty work.
Scroll
Do you want something to happen when a user reaches a certain part of the page? How about one of those cool, subtle Y-axis animations you always see on single page responsive sites? CSS has no ability to measure how far down on the page a user has scrolled. Only JavaScript is privy to this information.
Time & Budget Constraints
One of the least enjoyable parts of being a developer is estimating time. Tasks that seem like they ought to be done in an hour or so can turn into week-long endeavors. It should be noted that this is the norm for all programming, and it says nothing about the skill level of the developer. A developer will be inclined to say no on a feature request – no matter how small – because while it might seem like a minor tweak, it is actually quite difficult, or has enough unknowns around it that it has the potential to take a much longer time than it’s worth.
When deadlines are quickly approaching, everyone looks at the developer as to why everything is taking so long, forgetting all the baby requests that were added along the way. This kind of scope creep can be detrimental to a project’s progress, which is why developers will give quite a bit of pushback on certain things.
Best Practices & Technical Debt
Think about what happens to a car that you don’t maintain. If you just continually used duct tape to patch things together as they wore out, eventually it would breakdown or become too difficult to fix, and eventually you’d just scrap the whole thing and buy a new one. The same principle applies to web and application development. If best practices aren’t followed and corners are cut, you accrue technical debt. If that debt is not paid off, your site will become harder and harder to modify and to use. Eventually it will become such a mess of a knot that the best solution will be to axe it completely and start over.
Designers & Developers Can Still Be Friends
All of the above being said, the key to any good designer-developer relationship is communication. It’s not a designer’s job to know what’s accomplishable and what’s not, and a developer should assume as much. Staying in frequent communication with an open mind is crucial.
All of these issues come from the fact that the web world presents significantly more problems than the print world ever had to accommodate for, and we’re all still in the process of feeling out the limits. But if designers learn to be comfortable within the boundaries of the browser, and developers with saying yes to new challenges, we’re going to vastly transform the web together, for the better.
