Creating a Vanilla UI Framework – Part I

If you read my previous post here, you’ll know that at Branded3, we have recently put a new way of working on the front end of projects into practice.

Our old method involved making use of the third party frameworks from Zurb and Twitter – those being Foundation and Bootstrap, which are both good responsive front end frameworks in their own rights. If they’re good and widely used, why stray from the herd? Hopefully by the end of this post, I’ll have convinced you that Vanilla is a better solution than those currently available.

Now we haven’t gone and reinvented the whole UI workflow (something we are in the process of!) and this is by no means ground-breaking.

I’m sure many people make use of the same technologies and possibly make better use of some! If you fall into that category, leave us a comment – we’re learning as much as you are in this fast-paced world of UI development.

The new tools which we utilize have been packaged up and baked into the platforms we develop on, so now have a set of repositories we can rapidly roll out for each new project.

The name Vanilla is well suited, as it’s a very basic structure in which a UI developer can work. It’s the bare bones of a project, which is a step away from the likes of Bootstrap and Zurb, which are bloated in comparison.

Most projects which are built using those third party frameworks only ever utilize a small portion of what’s available to use. Digging around to strip out what’s needed and not needed, on a project by project basis is both time consuming and quite frankly, very boring for a developer.

What is Vanilla and why is it a good idea?

The Vanilla framework we have created differs slightly depending on the platform, as you would imagine. In Sitecore, we have a shelf system for laying out content, and in this, we have a series of span classes we have applied to our layout shelf system. Our lead .net developer has this to say about our Vanilla solution for Sitecore:

“Sitecore Vanilla is a pre-installed version of Sitecore in its own repository, which is maintained like an active project. It is configured to a standard that we have set out in a way that we believe is the best for building sites on this platform.

It helps us to standardise everything and therefore offer standard features that don’t have to be built or imported each time. Whenever we start a new Sitecore build, we take the initial base from the Sitecore Vanilla repository, so within an hour, we can have a ready-made and checked-in solution ready to tailor to the client’s needs.”

Read more about our Vanilla Sitecore solution here.

Working from a solid groundwork in which we have put time and consideration into for each platform we develop on, initially took some time to design, develop and improve.

However, this ultimately saves us time on the initial setup and also means that we don’t have to write a lot of code that tends to repeat across projects. In this regard, we use our Vanilla framework like anyone would use Zurb or Bootstrap – as a time saving and consistency focused tool.

The benefit is that we don’t include anywhere near as much bloat as the common frameworks, and each platform has its own version of Vanilla – not as a one size fits all, but a customised springboard into whichever CMS platform a project needs to be built on.

Style guides

Similar to the logic behind having something like normalize.css in a project to give you a blank canvas across all browsers, we create a styleguide to save even more time. We have our designers work out a full UI element inventory – Anna Debenham has a great collection of resources on this subject here.

What we as UI developers want from a designed style guide is the ability to pre-populate our style guide in code with all the required UI elements of a project, including all their states. Again, this aids with rapid development, in knowing the classes you need upfront to style elements and knowing that all the elements you add to a page are styled in an organised way.

It also saves you from needlessly styling an element per section of the site you come to build.  A designed style guide should be an inventory of every single type of UI element and its hover/active/focus states all in one document. From this, we spend a day filling out the blanks and customising each element which is required as part of the project.

By the end of a style guide sprint, you should be able to look at a page which has been populated in the platform with all of its UI elements, and get a real feel for the design. It also provides the designers with an opportunity during the initial stage of a build to critique styles.

At this point of a project timeline, where we have a fully populated page of HTML elements, we can have a designer take a look and sign things off.

This means that a large box has been ticked in terms of work that goes into building a project up, and you can continue to rapidly develop, knowing that each time you place a button, it will be correctly styled and won’t need amending later on in the project.

Here is an example of a style guide from one of our designers.

Part II coming soon…

Source: Branded

The post Creating a Vanilla UI Framework – Part I appeared first on Jass V.