Before we can start your integration we will need your graphic design in an acceptable format. Please read the following information to understand what we need - and what we don't need.
By adhering to our best practice guidelines the integration should progress smoothly and efficiently, without excessive queries, problems or misunderstandings.
Deliverables
For any integration we expect to receive:
- Wireframes for desktop, tablet and mobile versions of every major page type
- fully layered and named psds for desktop versions of every major page type (see guide below), including one showing default styling for all basic Easysite page elements (see list below)
- fully layered and named psds for tablet and mobile versions of one sample page (ie, home), showing any changes to the header and footer content and how the navigations will restyle responsively (including any drop down panels). We don't generally expect visuals for all of the responsive pages, as the wireframes should be sufficient to show how content collapes and restacks - hopefully in the obvious, logical way. Where there are exceptions to that, or any changes to content for RWD, it would be helpful to note them in the accompanying documentation
- Minimal accompanying documentation, just explaining any desired functionality which isn't obvious from the visuals or highlighting anything out of the ordinary/non-standard Easysite functionality.
Accompanying Documentation
We try and keep accompanying documentation to a minimum for a number of reasons:
- most of the time it should be fairly obvious what things are and how they work - though this varies depending how familiar the designer is with Easysite
- when we review the visuals we will make our own judgements on what modules/page elements would best suit the needs of that particular page - and then discuss with the client to make sure they're in agreement
- extra documentation increases the time it takes to review everything, as we will need to cross reference when the same information is supplied in multiple ways. For example, sometimes people like to supply a document detailing the css for general text, h1, h2, etc. But if those supplied values don't actually match what is shown on the visuals, then it can be counter-productive. If the psds are accurate it should be clear to us what font styling to use.
Guidelines on PSD management
- Any superfluous layers should be deleted, not just turned off, to keep the file size down and avoid confusion.
- Likewise, required layers should be visible (in case we assume that they are superfluous because they're turned off).
- Individual layers should not be flattened, especially text layers and navigation link effect layers. Text layers should remain editable as text so that the formatting information remains (font, size, weight, colour etc.).
- Associated layers should be grouped into logical folders, and folders grouped into over-arching HomePage or InnerPage folders to aid identification.
- All layers should be named appropriately, not just Layer 1, Layer 2, etc.
- Page elements such as logos should be on a transparent background (especially if they sit over header backgrounds with gradients etc).
- Colour schemes should be of sufficient contrast to meet Accessibility standards, and those colours should be as hexadecimal references rather than Pantones.
- Ensure that the PSD is created in 72dpi resolution (it is not acceptable to scale the PSD down from 300dpi to 72dpi).
Page Elements
The Page Elements visual shows default styling for a number of standard page elements:
- form
- default link/hover state
- search results
- horizontal rule
- headings 1-6
- default bullet list styling
- directory table
