Gmail makes the future of email look a whole lot brighter!

The last couple of months have seen some exciting announcements, which look set to change email development forever.

Gmail now supports media queries

Google has started the process of releasing a number of updates for its family of email apps online, as well as its dedicated Android and iOS apps. These updates will not only bring it into the 21st century and allow email designers to have more control over how their messages are rendered, but it will vastly improve Gmail’s ability to render CSS style rules in HTML emails and ensure that CSS styles are not stripped out.

One of the benefits of this is that CSS rules can be defined once and will cascade automatically to the correct elements when rendering, just like CSS was always designed to do and how it’s worked in web browsers since the late 90s. Developers have previously had to ‘inline’ style rules on to every individual element in order make emails look any good for Gmail users, leading to bloated, difficult-to-read code. While developers will likely still need to inline styles for a while (there are still email clients that don’t render styles in <style> tags reliably), this latest news hints at a future where inlining isn’t necessary, taking one of the more ‘trickier’ steps out of the email development process (different inlining tools work in subtly different ways, as do automated inliners built into apps such as Mailchimp and Campaign Monitor).

The second benefit of this is that it will be possible to use @media queries within <style> tags to adjust the styling of an email to suit the user's current device. In recent years, email developers have had to develop entirely new solutions for optimising the layout of emails in Gmail and other mobile email apps without @media query support. The most popular of these solutions is known as ‘fluid-hybrid design’. Andy even developed and shared his own version of the technique to help developers apply it more easily. But even when simplified, in comparison with standard ‘responsive design’ techniques, fluid-hybrid is far trickier to master and comes with its own set of quirks and limitations.

While there are still plenty of other email apps without @media query support, Gmail is by far the most popular (with a huge 16% market share), so Google’s planned changes mean a drastic reduce in the need for fluid-hybrid. Whether that means it will fade into complete obscurity, remains to be seen. As long as it remains useful for targeting other less-capable email apps, fluid-hybrid may still have a future.

Litmus partners with Microsoft

Litmus announced in August that it was partnering with Microsoft to ensure that future versions of Outlook would give email developers and users a better time.

Microsoft Outlook (in all its guises, from Outlook 2003, right to up to the new Outlook.com) has always been a ‘thorn’ in the side of email developers all over the world. Having to use the Microsoft Word rendering engine to render HTML emails throws up all kinds of unique and complicated bugs for developers to work around, meaning that they have to code HTML emails using tables for layout - just like they did in the 90s. It has always been the weak link of the email world, making it incredibly difficult for the industry to move forward, so hopefully Google’s latest news could change everything!
While developers will still be tied to creating emails that work in older iterations of Outlook for a while (we can’t forget about those users just yet - every recipient is important), it’s certainly good news that Microsoft is now listening to email developers, and at least intend to make things better for them in future.

To summarise

Email as a marketing tool has seen unprecedented growth over recent years, but these announcements signify a shift in attitude by the big players of the email industry. This means that email developers can hopefully spend less time trying to solve abstract rendering bugs and spend more time creating beautifully designed, engaging experiences for more recipients.

There are still plenty of other email app developers out there that aren’t yet prioritising the same things, but with Gmail and Outlook aligning their attitudes with Apple (the Mail app that comes with iOS, which has had fantastic support for modern CSS and media queries for years), industry standards are set at a level that other developers simply cannot afford to ignore.

In the words of 1993 UK chart-toppers D:Ream, “Things can only get better!”.

Advice for anyone starting out as a web developer

The experience for many junior web developers can be quite similar when you first enter the industry, though the first few months may consist of a mixture of mild gratification and abject fear.

After a while, you may have begun to master a few languages, built some fancy websites and even worked on several applications. It’s at this stage, as a web developer, it becomes dangerously easy to get stuck in your comfort zone. You either begin to spend longer on tasks than you really should do, or spend so long labouring over the technical aspects of an application, that you forget about the end user’s experience.

To help you avoid a few of the most common pitfalls you might face, the friendly folk in our web team have compiled a list of three gems of advice that they wish they’d known when they started out.

1. Don't reinvent the wheel

It's something you've heard uncountable times before, but with development, it's easy to forget. Search for open source packages or frameworks that suit your needs; because nine-times-out-of-ten, that niche approach you were thinking of making can be drastically simplified by using something already well written, tested, supported and documented.

2. Whatever language you're using, use a linter

A linter will automatically check your code for stylistic or programming errors, such as unused imports or undefined variables - something that will save you hours of banging your head on the table trying to find that one misspelt variable.

3. Don’t second-guess your end users

Development should be based on real user's needs as a result of user research. Don't waste your time developing features or functionality as a result of guessing what your users want. Building that super-nice feature because you think it might be useful might be a fun challenge, but it risks never being used if you didn't ask users what they need first.

The A-Z of life at RKH | Django

D is for Django in the A-Z of life at RKH.

Named after the famous 8-fingered guitarist, Django Reinhardt, Django is our digital team's development framework of choice - we use it to build and run almost all of our websites and apps. You might not have heard of it, but without it the likes of Instagram, Pinterest and our very own Police.uk website wouldn't exist.

Django provides a common set of tools to help build new websites and apps, which is great because our development team works on a LOT of different projects. Thanks to Django and the rules and conventions it introduces, somebody that has worked on one of our apps can easily jump in and work on another without wasting time having to completely re-learn how it works.

Django also does a lot of the essential heavy lifting techie stuff associated with building websites and apps automatically: handling browser requests, securing user accounts, validating user input and letting designers work on page templates without breaking anything. It does all of this in an efficient, safe and secure way, meaning our team can focus on cleverer and more innovative ideas instead of the underlying grunt work.

Whilst Django itself is developer-friendly, fast and secure, it is the fact that it is open source and supported by a community of thousands of other developers around the world that really makes it shine. If we run into a problem, somebody else has probably run into it and will have shared their solution. Likewise, if we have solved a particular problem, we can share it with the community so that everybody else benefits too.

We use Django for the majority of our web projects because it handles the stuff we always need in ways we can rely on, and frees up the team to focus on our specialities, the value we can provide for our clients.

If you're interested in learning Django for yourself, here's a great tutorial.

Thank you for the music… and the framework!

The A-Z of life at RKH | Agile

Our digital team are very busy people. As well as being frighteningly intelligent, they’re also a very organised bunch of folks, utilising a number of tools and techniques that help them build high-quality products and services for clients from a range of sectors. To kick off our A-Z of life at RKH, we’ve chosen a critical working method and overused buzzword - Agile.

Agile is the project management methodology adopted by our Digital Account Director, Harshul, which helps our digital team build online services quickly and focuses on defined objectives. Testing occurs throughout a project, so that work can quickly adapt based on the feedback given by both the client and the project manager.

In comparison to Waterfall methods, the Agile approach allows for constant feedback throughout the entire process, instead of when the project is nearing its end. With the Agile approach, the planning, designing and testing phases all happen at the same time. This is most effective when building digital services, as it allows teams to modify or rework what they’re building should any unforeseen or external forces arise.

Our web team usually work over periods of time known as ‘Sprints’, which involve 2-3 weeks of working hard to provide a specific list of deliverables. After feedback and review, this then followed by continuous periods of sprints, which is both valuable and very intense.

It's a hugely beneficial way of working because the team constantly learns and improves what they’re working on, all at the same time. It also provides clients with a clear overview of what can be expected, updates on any ongoing work and providing an indication of what will be finally delivered.

Join us on our social accounts to stay updated on the A-Z of life at RKH and find out how weird and wonderful agency life can be.

Musings on the Northern User Experience Conference

The golden rule for every businessman is this: “Put yourself in your customer’s place.”
- Orison Swett Marden

Over the years, the word research has gained a bad reputation. Many businesses and entrepreneurs hear the word mentioned and instantly come back with a list of better things they could do with their precious time and money.

Say, for instance, that you’ve been having issues with a certain way of doing something. You go on to develop a new method that resolves these issues and launch it to the public. Sounds like a brilliant money making scheme! But was anyone else experiencing the same problems as you? How do you really know what you’ve created is exactly what is needed if you haven’t asked the people who could end up using it?

The same principle applies to websites. In order to make a website user-friendly, you first need to know what’s friendly for its target market. Conducting research will help you learn why users make certain choices and how they behave in their environment. It helps you gain a better understanding of your audience and determine how your product or service fits into their lives.

As the online world continues to grow, so does the value of a good website - and by good I mean a site that is aware of its users’ needs and has taken these into account throughout its development. This movement towards research was certainly noticeable at the recent Northern User Experience Conference (#NUX4) in Manchester, which was sold out for the first time in the event’s history.

The underlying message behind the various talks was that better products and websites can be developed through the use of effective research. For some of you reading this post, User Research might be a completely new concept that you haven’t really ever considered, others might be UX pros; either way, here are a few things that I think everyone can reflect on…

Fall in love with problems before falling in love with solutions

Now on the face of it, that statement doesn’t seem terribly optimistic, but if you think about it, unless your idea solves a real problem, success is highly unlikely. Tomer Sharon’s talk focussed on the importance of having an idea that solves a real problem and then developing that idea using and implementing feedback from real people. Abandoning assumptions and observing real life will enable you to create something far more relevant for your audience than if you go it alone.

Pre-empt common problems

Unfortunately the working world is not always plain sailing and the same issues will often occur time and time again, affecting your working relationship with the client and having a real cost on the project. For instance, with UX being a relatively new phenomenon, as an agency we need to help clients understand the added value this research will bring to their project.

Evangia Grinblo gave some great advice on how to resolve some of these common blockers. By categorising the different ‘kinds’ of issue you might face and creating a knowledge base for dealing with these types of problems, you’ll be in a far better position to resolve them earlier on when you next face them; paving the way for a happier, more productive relationship, that both parties will gain from.

Don't leave anyone out

Categorising users is sometimes necessary, but if you’re exposing that in your product or website, you’ll alienate people that feel like they don’t fit. Sara Wachter-Boettcher’s talk focussed on being inclusive and catering for all your users, and not just writing off certain people because they don’t fit your idea of a ‘common user’. These people are normally the most important as they’re highlighting that there’s something wrong with your solution that needs addressing.

So to sum up: always question what you’re creating, make sure you’re doing the right thing in the right way, welcome feedback and criticism - it’ll help you in the long run - and don’t leave anyone out. It’s worth the extra effort… I promise.