This is based on an article that appears in .Net Magazine May 2017
As progress continues to accelerate, Sush Kelly warns of the dangers of being seduced by every next big thing.
Progress in web design techniques shows no signs of slowing up. As the proponents of the early web are staggering round with 1000 yard stares you can't help but feel a little overawed by the plethora of techniques and frameworks available nowadays.
People are championing the new ways which are about to change the way we work once again. Flexbox (already available) and more importantly CSS Grid. Rachel Andrew and Jen Simmons have been encouraging developers to look at this technologies now in readiness for their arrival.
There have been murmurings and posts in recent months from some of the current web industries founders such as Andy Clarke of Stuff and Nonsense and Jeffrey Zeldman asking if it really needs to be this complicated and whether web it losing its soul or becoming reliant on a standard output. Have we all become enslaved to the frameworks and tools available to us?
It is hard to deny this, I don’t think there has been a time in my career where there has been more choice (and opinion) in the way you should build digital projects.
We are long past html, css and a little javascript, now there are css pre processors, js frameworks and the components that make up a web project now encompass much more such as optimisation, CDN delivery and SEO to name just a few.
I have been working in websites since the year 2000, meaning I cut my teeth on the long forgotten techniques such as tables and shims, all amongst the 'browser wars' that make the current browser situation seem oh so compatible by contrast! As a Digital Director at a creative agency in Leamington Spa it is on my shoulders to make sure we use the right technology on client work and invest time wisely with regards to what we learn and in due course adapt into our processes.
We are a small company of 12 and as such I am not detached from the actual builds, client liaison and the management of the resources we have to deliver, it keeps me right in the middle of the woes that the Developers, clients and Project Managers all have in the project lifecycle.
Not like that… like this.
The talks and conferences advocate best practice and cutting edge tech, why we should be using x,y and z. This is 100% needed, after all, the web industry is relatively young and we are still defining the standards of the industry to an extent. The problem is this can lead to you feeling inadequate or somehow failing if you are not actively using these technologies day to day in your work, it is a lucky few who get to make their living pushing those boundaries and telling us all about them. Don’t get me wrong, it is essential to have these people pushing the bleeding edge but it can result in an urge to jump into these methods too early, which can be the worst thing to do on live client work.
We want long, productive relationships with clients, and if you are successful in this regard will be returning to work on sites months later. Changing how you build sites means having to readjust and remember more skills. As much as good commenting and a readme file will help there is a responsibility not to deliver a piece of work that is outdated in months or worse unsupported incase of future development.
“It’s important to only take on board advancements that are an improvement on what came before. But when the churn of technology is so quick that we have interns who have never even had to use a float, it becomes a real balancing act.”
I completely understand how designers and developers want to adopt the next great thing, I feel the same compulsion and it is actually one of the things that has kept me in the industry so long. The fact is though that I have to think about the longevity of the plugin/library/software as if it won't stand the test of time or worse ends up failing or losing support then the responsibility falls on us.
There can be times where it seems the right idea from a development point of view but the client refuses to use that method, this can be frustrating if you can see the potential benefits but bigger companies especially will have IT standards that 3rd party work must comply to.
Educating Juniors
Junior developers have such a thirst for knowledge, it is often an inspiration to more senior team members when they arrive in the studio eager to show a new method or technique that is emerging and how it might be used on a project.
You want your staff to grow and develop and be able to work on things together, so again we need to make sure that we are only taking on board advancements that are an improvement on what came before. But when the churn of technology is so quick that we have interns and junior designers who have never even had to use a float and do not know life before Bootstrap it becomes a real balancing act. A good example of this is moving from LESS to SCSS and also from Grunt to Gulp. Both these technologies are similar but suitably different to mean returning to a project using Less/Grunt become an exercise in re learning and in the cases of our Juniors/Interns learning a new (old) technology from scratch.
Flex and CSS Grids are the current darlings of front end talk. CSS Grid has the potential to revolutionise the way we will lay websites out in the future. At the moment is it still hidden in the latest browsers although you can access it if you enable experimental features on the likes of Chrome. We cannot use it in live work for this reason though with an imminent launch date it could be as big a shift in web development practice and the shift from tables to divs and floats.
We are using Flex on live work now but only in ways that are a benefit, for example for ordering content in responsive layouts or vertically centering items. To try to use Flex for a full site at the moment with IOS/Safari's flakey handling of it would be a challenge that just may not be financially viable on live work.
Embracing the old
Clients, especially larger companies quite likely won't be running the latest browsers or could have restrictions on their web access which could affect your build, and if it turns out the main stakeholder is using IE on an old laptop the site better work on it or the project won't get signed off.
Sometimes a client will have a good idea of what they want, or an incumbent system or technology that you need to work with. A key point for us as an agency is being adaptive to these needs and working with them rather than dismissing what they have and trying to force them down the route we would prefer to go. Sometimes this may mean us having to extend an existing codebase and thus keep within the technology used.
We are much stricter now on tieing down sign off devices and so on but over the years have had our fingers burnt on more than one occasion where we ran with a new way of doing something with good intentions only for it to cause issues as we tried to get the site signed off. It just serves to remind us that there are so many device /user combos that it just isn't ok that a given method will only work on certain browsers. Although you can make workarounds and shims there often isn't budget to do this and when a client doesn't have the resources then you need to go with the solution that will please everyone.
When it comes down to it the main aim of the studio is to produce great forward thinking work, being fully open to new methods but also picking the right time/project to use them. It is a tricky balancing act but one that gives me a great feeling of satisfaction, especially when a new process finally becomes “the standard” on live projects.