Contributing to Framework

Please follow the below checklist before you pass on a new component for inclusion within the Abeille Assurances front-end Framework library:

Before you start, let’s be consistent…

If you do not have access to the sketch assets and require it please contact Toby Haynes or Tom Smith directly or by using the contact form.

Check the component doesn’t already exist in the Framework.
Provide a brief synopsis of why the new component is required, the need it’s fulfilling, and at least one contextual case of how it will be used.
Remember: the Framework is a collection of globally reusable UI components. If your use-case is unique and / or highly specific and not applicable in any other contexts, then it should not go into the Framework. This doesn’t mean it is redundant, just that it should remain outside of the Framework as a local component.

The Framework for Atoms and Molecules for re-use in your new component. This will avoid unnecessary duplication.
You’ve set up your document for pixel perfection (Preferences - Pixel Fitting - Select ‘Fit layers and points to pixel bounds’). This will ensure components and their constituent parts are composed of whole pixels only, and align to the pixel grid.
You have used the Art Boards within the Grid Section of the Master Sketch File to ensure your component conforms to the correct page grid.
Art Boards are named using the format: Description - Device - Discipline (eg. Tables - Desktop - Designs).

The component must work for all device types: mobile / tablet / desktop.
Consider how the content in your component re-orientates between device types, ie. the arrangement as defined by CSS positioning statements and the order of HTML in the document flow. JavaScript (JS) must not be used to create different layout configurations according to device type.
Ensure you include the non-JS solution if the component behaves or appears differently when JS isn’t running.; if the component is unchanged when JS isn’t running, please mark it as such.
Supply detailed annotation for any different states and/or any behaviours or transitions (eg. hover, focus, active).
If an unhappy path is a possibility (eg. text wrapping), supply a design variant for this (or show this in some way in your component).
You have considered the minimum and maximum number of units / content that could apply to your component, not just the number of units / content you are designing for right now. This will ensure your component is able to flex with different content in different contexts.

Spacing (paddings and margins) must be accurate and conform to the multiples of 5(px) rule. This increases to multiples of 10(px) for larger spaces, ie. 5, 10, 15, 20, 30, 40, 50, 60, 70, 80 (px) etc.; see the grid style guide page for more details.
Key lines are 1px wide rectangles not lines. Lines are problematic because:
- by default, Sketch places line axes on the pixel grid: 1px wide lines fill just half of the adjacent pixels (messing-up pixel fitting).
- line end-points default to non-butt cap; this results in misleading line-length dimensions.
Assets within the Sketch file are vectors, not rasters (and are therefore editable), photography being the exception. See "Quick tip: The difference between vector and raster" article for more details.
Text bounding boxes are set to their maximum length (Sketch typography attribute ‘alignment’ set to ‘Fixed’), not just the length of the copy in your doc (‘Auto’).
There’s visual harmony between your new component and existing components (that they use the same Visual Design Language); see the style guide section for more details.
All properties within the component meet the accessibility standards; see the accessibility standards pages for more details.

Your component’s layers are organised and grouped neatly, logically and descriptively; this aids sharing and reuse of the file.
Components do not contain redundant attributes - if they’re turned off, then they’re not needed, so please delete them. For example, if you’ve created a rectangle that doesn’t display a border, ensure this border attribute isn’t just unchecked but actually deleted.
If you’ve used symbols, ensure no symbol is duplicated. Use the the Sketch plugin ‘Merge Duplicate Symbol’ to help with this clean-up. (Not to be confused with the legitimate use and reuse of symbols within the design.)
If your component uses a symbol that pre-exists in the Master Sketch File, please copy its label verbatim, ie. use the EXACT SAME name and hierarchical structure. So if your component includes the ‘Get a quote’ button, label this ‘Buttons / Designs / Get a quote’. This makes merging into the Master Sketch File seamless.
Supply Sketch files only - Illustrator or Photoshop files won’t be accepted.
Wireframes aren’t required, as we reverse engineer these from the visual design.
The component has been signed-off by the Framework Visual Design Lead (Tom Smith).

If you need any further assistance, please contact Toby Haynes or Tom Smith directly or by using the contact form.