Summary
Alloy
A documented, readily-accessible, pre-tested, accessibility-verified, seo-optimised, repository of components that can be adopted and styled easily into projects.
StarterKit
A repository containing commonly used back-end components that can be re-used or adaptated to fit a project so that developer time can be spent developing bespoke systems rather than copy-pasting boilerplate. The code is written to be clear, concise and testable.
Previous ‘Alloy’
This was a very useful starter kit with lots of components, but suffered from being heavily styled, so it wasn’t very easily adaptable to new projects or integration into older projects. We have learnt a great deal from a Frontend development standpoint, and we’ve adapted and grown from the project.
New ‘Alloy’
We’ve separated the mechanics from design so that components are more easily adapted into different projects or designs. Components are labelled, documented, and their functions and accessibility tested.
We use the latest frontend systems and processes, which helps to keep us up to speed in development, training and knowledge.
Accessibility is SEO
Frontend use Alloy to create an initial static build of a project. Great Roast Dinner for example, was built using some parts of Alloy that we’d written specifically to conform the site to minimum accessibility levels.
We’ve found that all accessibility criteria is aligned and dependent on SEO best practices, and vice versa. Google commends or penalises certain practices, and among SEO ranking is accessibility standards. Legal and moral obligations aside, clients are more sensitive to SEO ranking.
A static site exists throughout a project, so we can test and implement changes quicker than developing the backend programming. For example, theming of the GRD site involving checking colour contrasts and finding a suitably labelled set of guidelines for the client to use in Umbraco.
Smoother integration and cross collaboration
UX
UX-led development feeds into this. If it’s determined that for UX-reasons we implement an expandable card section (eg, LDC news page), Creative Team will see from Alloy that we’ll require good descriptive labels, content and clear interactive controls: these are/will be highlighted as requirements in each Alloy component.
Content and labelling requirements can be given to Account Managers who can request authorised copy/brand elements from the client ahead of time. LDC’s Top50 is a good example of this - in order to meet/improve SEO and increase general appeal to users, we needed descriptive headings and copy to explain what each section was. These were actually an accessibility requirement, which happened to be beneficial to SEO - a very common theme.
Future Components
Where an Alloy component doesn’t already exist, we can construct it either as part of the project build or independently as part of Alloy development, or base it off an existing component.
With a readily accessible central repository, this means the component development can be split: ie, one frontend developer can make a new component, while another can begin on other aspects of the project build. This happended recently with LDC’s microsite, where we needed pre-made Tabs and Accordions functionality, using modern practices, accessibility and SEO.
Timings
When estimating projects we break them down into pages and components. Where we have pre-made components, we can re-use them and factor that into the accounted time (as they’ll still need styling).
Working on, and with, Alloy
We are building a comprehensive and documented system. Documented so that any frontend developer (new or established) can see how things work, improve, adapt, and learn from any component.
New team members and collaborators can read the documentation or contribute, and get up to speed.
Progressive Enhancement
We’re using progressive enhancement so that the components continue to work in older browsers (with reduced functionality) and newer browsers that support newer technology features can use them.
Legacy code - a particular example is LDC, which still has legacy code targetting very specific browsers like Internet Explorer 8, which increases bloat in the page code for everyone, and makes it difficult to implement new features without breaking others. At the time, we compromised features and forced them to work in all browsers including IE8, rather than letting older browsers prioritise content and leave the technical/presentation for newer browsers.
Optimisation for future browsers (Bundles, Features, and Polyfills)
The Alloy build system can and will output ‘bundles’ (feature-specific enhancements) and ‘polyfills’ (features not built into older browsers that they download only if needed).
This affects the way we make components, and requires understanding by clients that some older browsers don’t support some features (“it’s looks different”).
We’ve heavily optimised the way we build static-sites, primarily the HTML and CSS, and are expanding that to Javascript.
Project rebuilds / upgrades
We’ve already used the newer Alloy system and components in Food for Life, LDC, Brandon Trust, and others. Older projects benefit from better-optimised output, and it makes it easier to develop and apply new techniques or features to projects. We can also see how things have changed (or why) so we spend less time resolving issues.
If we update a component in future, we have a lasting, documented history of how it morphed between versions, so we can more easily update older Alloy-versioned projects.
Inspiration
We want to avoid stagnation of design. UX-led design will produce better creations and a high quality user experience. Where we implement existing components, we can more easily adapt them to the new design, or create new components if required.
This means both the creative team and the frontend team can collaboratively concentrate more on creativity, usability, accessibility and inspiration, rather than starting from scratch on each project.
Previous ‘Starter Kit’
Previous implementations of the Starter Kit have been Umbraco focused and were often tightly coupled to the version of Alloy in use at the time, which made it difficult for Frontend to begin development without Backend involvement (and vice versa).
A reliance on jQuery and AngularJS also meant that the Starter Kit quickly became outdated, and any experimentation with new technologies typically required a deep knowledge of both the Front and Backend aspects of the system.
New ‘Starter Kit’
The Starter Kit contains many systems, services and tools that can be swapped in or out as required for a project. By building many small components, we aim to encourage re-use and testability.
Flexibility
The Starter Kit currently comes in two ‘flavours’ - Core and Umbraco.
Starter Kit Core contains platform-agnostic systems while the Umbraco version contains functionality specifically for Umbraco builds. The platform-agnostic systems should aid in speeding up the development of Umbraco, Sitecore and custom-developed websites.
The Umbraco Starter Kit contains a fully fledged website albeit without any bells and whistles. These common ‘out of the box’ systems can be easily removed if not needed, swapped out for other implementations or modified where necessary.
Azure DevOps
Integration with Azure DevOps has given us the ability to automate builds, deployments and the creation of nuget packages.
Unit Testing
We are unit testing where possible to ensure that Starter Kit systems are not accidentally broken by code changes. This is automated during build processes and emails are sent when tests fail giving ownership and accountability to the codebase.
Collaboration
This implementation of the Starter Kit aims to completely remove the dependency between Frontend and Backend systems by simply dealing with core responsibilities.
The Starter Kit begins as a ‘white site’ containing completely unstyled and unsemantic HTML, allowing Backend to focus on the functionality and logic of the system, and Frontend to focus on the website build.
An integration step towards the end of a project is required for the Backend and Frontend implementations to be merged together.
Other Advantages
Outside of the obvious advantages of robustness, cutting down on repetition, and testing, the Starter Kit also ensures that core website elements are not forgotten about, such as sitemaps, error pages, logging and cookies. It also encourages a consistency in approach and acts as a role model with the repository containing best practice implementations of systems and design patterns.