Common Design Practices
- Naming Conventions
- Modules
- Font Choice
- Affinity Designer
- Folder Structure
- Asset Preparation
- Button States
Naming Conventions
It is very important that all our files are consistently named. This makes it very clear to all members of staff what it is they are looking at and what to expect when navigating typical project folders.
Source Files
These files should take the format of:
[Client_Name]_[Desktop,Tablet,Mobile]_[Template_Name]_[Version].afdesign
An example might be:
We_Create_Digtial_Desktop_Homepage_002.afdesign
Website Assets
Whether you are exporting images, videos or documents, if the file is being used on the web we should always substitute spaces with dashes and files should always be in lowercase.
Furthermore, it is good practice to think about the filename from an SEO perspective for example a photo for an about us page named about-us.jpg
is fine but if we take 30 seconds longer to consider more descriptive filename, the client may receive have a better chance of performing better in search engines.
Modules
Modular design involves creating components of design and using a grid-based layout to construct our web pages. The designed components make up the overall template and are designed to be reused.
Reusing designed modules can be exclusive to one website or might be reused over many of our websites. A good first read might be: Modular Design the complete primer for beginners
We are building a library of our modular code, which will be available soon.
Font Choice
When possible we should use web safe fonts rather than relying on a CSS web font. You can see typical support for web safe fonts by going to CSS Font Stack
An alternative approach is to use the system default fonts, we’ve done this recently on Omniowl
If we need to use a CSS web font we should consult Google Fonts first. We have a TypeKit account, which we can use as an alternative.
Affinity Designer
Since 2014, we have been using Affinity Designer and Photo for all our design work. There were multiple reasons for the move away from Adobe, many of which you can read here.
Layers
To keep documents clean and tidy, you should use layers when appropriate. Layers should have short names, which should be clear and consistent.
Rasterising
If using multiple bitmap images in an Affinity Designer document, a file can become large in size very quickly. It is recommended that you rasterise images as you go to ensure we keep document sizes as low as possible. This makes it easier to store, share and access source files within the office or remotely.
Folder Structure
Almost every project we complete will have its own folder, which will contain the following folders::
-
Assets client/website visual files
- Client raw assets provided by client
- Website prepared assets provided by WCD ready for frontend development
-
Creative all source files
- Archive containing old versions of source files
- Documents all documents for the project
Asset Preparation
Preparing assets for a website is a very important process. If not done correctly, it may increase the page weight of a web page, which may have adverse affects.
File formats
It is tricky to sometimes know what type of file format to use on a web page. Here are some rules, which can be used when determining what format to use:
- JPG should be used if the subject is a photograph
- SVG should be used if the subject is a vector illustration
- PNG should be used if the subject is a bitmap illustration and no vector version is available
- GIF should be used if the subject is a bitmap illustration, no vector version is available and is smaller in size than PNG
Bitmap images
- JPG images should be exported at 100% quality using Affinity then optimised using a third party compression tool
- PNG images should be exported at PNG-8 if not transparent or PNG-24 if transparent. The graphic should be optimised using a third party compression tool
- GIF animations should be optimised using a third party compression tool
Vector SVG
With an increase in the use of retina screens, as well as the need to cut down the number of server requests and to keep page load down, SVGs have become very popular and provide a very sharp and clean alternative to traditional bitmap images.
- Remember to select the preset 'SVG (for web)' when saving a SVG file on Affinity; this will compress the file to ensure there is no whitespace in the file
- Unfortunately there are a couple of steps that need to be taken after saving an SVG before it is ready for the web including:
- Removing the opening line, which may look a little like
<?xml version="1.0" encoding="UTF-8" standalone="no"?><!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
- The changing attributes within the opening
<svg>
tag for example changing width and height from<svg width="100%" height="100%" viewBox="0 0 740 490">
to<svg width="740px" height="490px" viewBox="0 0 740 490">
-
A MUST: add the
preserveAspectRatio
attribute to the SVG itself, this will position the elements within the SVG (i.e. the<path ...>
). For example,<svg preserveAspectRatio="xMidYMax meet"
this will position the path to the bottom right. Please refer to the docs for visual and detailed examples
- Removing the opening line, which may look a little like
Animation
From time to time our websites will feature some element of animation. If animation is not possible using CSS, then a more 'low-tech' approach should be taken:
- GIF images can be used for very simple illustration like we've previously used on Lacey & Saltykov
- If the animation is somewhat more complex then you should opt for video files instead
- There are three video formats required between all the major browsers MP4, WEBM and OGV
- You should always export an uncompressed video before exporting for web, we tend to use Miro Video Converter or Compressor
Button States
It's important to remember that buttons are not static and devices behave differently for some states. Most importantly some users require different button states so it's important that we don't forget about these users.
The following are required when designing websites, however, there are a range of pseudo classes that you should be aware of::
Hover
- What happens when a desktop cursor hovers on top of a button? Should the button invert, should an underline appear?
- It's not possible to hover on a touch device but sometimes devices treat hover as a tap
- Plain links should always be underlined and that underline is removed on hover
Focus
- Most useful for those users who use the keyboard to navigate
- Focus provides a state, which makes it obvious what it is that is currently being used
- This is not limited to buttons and anchors but to inputs and textareas as well