#patternlibrary | Explore Tumblr posts and blogs

we-are-next · 10 years ago

Text

Why do we create Style Guides?

At Next, the style guides we create are the manifestations of our design systems. They provide our clients with the scalability to support their business or product into the future on the Web. A style guide helps to maintain the brand design and code consistency of the website as it grows over time. With the wide variety of devices that are now able to access the Internet, testing the design of your website can be challenging. Testing is easier with a style guide as you can view the individual parts of our designs, in isolation from an entire interface.

Because style guides begin with the basic elements of a design, it allows us to share our work in progress from the start. In using this open approach with our clients, they can see the progression of their website from early on in the project. It also enables them to give feedback at the point in the project when it is much easier for us to accommodate change.

Building blocks

Web pages comprise of basic elements combined and laid out to create a user interface. Dave Rupert used the analogy of LEGO in describing how they designed and built a website for one of their clients.

The majority of websites that you browse have many common elements. These include color palettes, typography, navigation and buttons to name a few. We ensure that these elements remain consistent throughout a website by building a style guide. This helps to provide a better user experience.

Our style guide contains all the individual parts of our design system. It also shows you how they get put together to create the templates which you see when you visit a website.

Consistency over time

Over time, a website will change. This could be content that needs updating, more pages or new features. Because there is an existing style guide, we are able to determine the scope of work required in a short space of time. Our clients are able to view the style guide as it evolves during this update phase.

Code

One of the patterns in our website’s style guide.

Our style guides contain snippets of HTML used to mark up elements and patterns, whilst defining the code style we use. This makes it easier for our developers, as well as external ones, to add to the code base and maintain it. It helps to ensure our standards to produce consistent HTML and CSS.

The pattern library we have in our boilerplate style guide is up to date with the latest recommendations of best practice on the Web. It enforces what we learn from a project and lets us carry it over to the next one. This saves us time as we’re not having to deal with common issues that occur on the Web. The benefit of this is having more time to focus on providing solutions for the needs of our clients.

Design

Source: Interface Inventory by Brad Frost.

Over time, it is likely that the people involved with the initial design and build of a website would have moved on. If there is not a clear guide to reference, people may have difficulty in continuing the original design system. This is how inconsistency can make it’s way into a website and provide for a less than ideal user experience.

Your experience with a website is likely to be frustrating when there are inconsistencies in the interface. By having a style guide, you can prevent this problem.

Working together

The biggest change we’ve seen at Next since we started to create style guides, is that everybody is much closer to the project. No longer is development a “black hole” with the final product shared right before a deadline is due.

It allows for easier communication about and understanding of what we create. Potential issues get flagged early on in the process. Another massive benefit of the style guide is that you view it in a web browser. This highlights the complexities of responsive web design in a multi-device world. Our clients can then view the design in their favourite browser. This helps them to see that websites will look different on different devices.

The style guide we created for FRANK.NET’s website.

Resources

If you want to find out more about style guides, you should check out Anna Debenham’s Website Style Guide Resources.

#styleguides #patternlibrary #designsystem #frontend #design #development

7 notes · View notes

drum-head · 9 years ago

Link

Haven’t tried but am basically ‘logging’ here for later reference.

#patternlibrary #styleguide

0 notes

rdjpalmer-blog · 10 years ago

Text

Preparing to write CSS

Quite recently I've been looking at how best to write Nudjed's CSS. I've looked at everything. Folder structure, CSS pre-processors, style guides and pattern librarys. You name it, I've looked at it (… probably). I thought it would be best to share the love, so here's a bunch of articles I've found helpful during this process.

Before we delve straight into the articles, here's the difference* between a style guide and a pattern library:

*I got these from a quick google.

Style guide

A style guide is a set of standards for the writing and design of documents, either for general use or for a specific publication, organization, or field. A style guide establishes and enforces style to improve communication. - Wikipedia

Pattern library

A pattern library is a collection of user interface design patterns. The site UI-Patterns described these user interface design patterns as: Recurring solutions that solve common design problems. - Paul Boag on boagworld

So in the context of this article, a style guide is a standard of how to write CSS. A pattern library is a library of components with their relevant mark up, CSS and JavaScript.

Lonely Planet

Ian Feather wrote a bunch of articles on Lonely Planet's frontend, a couple of which were super helpful during my exploration of CSS architecture.

Lonely Planet's CSS

Lonely Planet's “a maintainable ~~style guide~~ pattern library”

Lonely Planet's ~~style guide~~ pattern library

Note while Ian writes style guide, his articles talk about something much more akin to a pattern library than a style guide. Regardless, you can still get a great insight from them.

Mark Otto and GitHub

Mark's gone and written some great articles on GitHub's CSS. His insights kicked this all off, and given his prestige (Twitter, Bootstrap and GitHub!), you'd be crazy to ignore any of it.

Code guide: Standards for developing flexible, durable, and sustainable HTML and CSS.

GitHub's CSS

GitHub's style guide

Ghost

Following GitHub's and Lonely Planet's lead, Ghost's Paul Davis shared with us how Ghost writes CSS. A notable feature of Ghost's CSS is the reverse on common practices, such as semantic naming conventions and grid systems.

Medium

The great thing about Medium sharing their thoughts about their CSS is how deep Jacob makes the rabbit hole feel with such a pleasant read. Once you're done reading about the process he went through to “fix” their CSS, make sure you check their style guide.

Axiomatic CSS and Lobotomized Owls by Haydon Pickering

The previous articles are fantastic, but they're all missing something. Lobotomised Owls.

* + *

That's one badass selector name, with a selector to match. Seriously though, Axiomatic CSS and Lobotomized Owls is a must read. The principles Haydon speaks of here are going to provide the foundation of Nudjed's CSS.

If you're down with it, also check his effortless style presentation at CSS Day. I saw this first, and it was quite the eye opener.

Other resources

We could talk about this all day, and expect me to continue in a “how Nudjed writes CSS” post sometime soon. Meanwhile, heres a load of links to other resources around writing CSS, style guides and pattern libraries:

Pattern libraries

Pattern Lab

Pattern Lab's resource page

Getting started with Pattern Libraries by Anna Debenham

Mailchimp's Pattern Library

Style guides

Google's HTML style guide

Google's CSS style guide

BBC's HTML style guide

BBC's CSS style guide

csswizardy's cssguidelines

CSS-Tricks' style guide resources

#css #styleguide #patternlibrary #lonelyplanet #github #ghost #medium

0 notes

keirmoff · 11 years ago

Text

To Bootstrap, or not to Bootstrap?

Reading time: 5 mins

Back in June, I was working closely with another designer/developer on the front-end build of a sizeable website, when we came upon a tricky hurdle: a request to use Bootstrap.

For this particular project, we both felt that Bootstrap was not the best way forward, and wanted to understand why the request had been made and what we could do to recommend otherwise.

The below is taken from an email discussion I had with the other designer/developer, prior to discussing with the client - and which I thought might provide a useful insight not only for dev teams, but also clients when it comes to making decisions regarding the use of frameworks.

-- email starts --

INTERPRETATION

1) The code provided for the previous build of the site had created additional and on-going work for the in-house team with regards to browser/device support.

2) They are keen to avoid this happening again and believe Bootstrap could help prevent so.

3) They find Bootstrap reassuring because it is well-tested and appears predictable, reliable and robust - and has detailed documentation.

RESPONSE

So, as you said, we need to reassure them that our approach will deliver good, solid, reliable code that will not cause problems for integration and support.

1) Fit for purpose

I think it would be good to show some examples of style guides and pattern libraries to demonstrate that our approach involves creating a bespoke f/e framework that is fit for the specific purpose. This is aligned with the goals of Bootstrap - except ours should be leaner, faster and simpler.

2) Code quality

Whilst we will not have time to create exhaustive documentation, like Bootstrap, we will be providing developers notes and liberal code commenting which, coupled with the use of BEM (which Bootstrap does not use), will mean the code is easy to understand. My approach is heavily geared towards clarity for future development/developers - both front-end and back.

3) Compatibility

The browser support offered by Bootstrap is really not any wider than any good developer should aim for - so we will be aiming for a similarly high level of compatibility and quite possibly more. In particular, our compatibility will be further informed and led by stats from the previous site.

Whilst theoretically Bootstrap gets us off to a flying start with browser support, a good developer is conscious of this from the outset and, because the code is likely to be slimmer and more specific to the project, bugs can be more easily identified, understood and fixed.

It is also worth noting that whatever approach/framework we use, there will always be some level of custom code that requires the same level of testing, especially across mobile devices.

4) Flexibility

We also need to make it clear that the convenience and predictability of Bootstrap for developers is not necessarily in the best interests of design, front-end or, most importantly, the end user.

Bootstrap is very opinionated and may require us to heavily customise and reverse engineer aspects of it - or simply deviate from it entirely for much of the build. This could result in slower progress in development and bloated, poor performing code for production.

The alternative is keeping more aligned with Bootstrap's opinionated UI patterns which could lead to restricted design choices and 'Bootstrap clone syndrome'.

With regards to the in-browser, agile design/dev process proposed, flexibility is of utmost importance. Bootstrap simply does not offer us this.

For example, I would intend on using a grid system that delivers fixed-width rather than responsive in IE8 to avoid the (albeit small) JS overhead of respond.js.

This is just one of the many decisions about implementation and performance that a flexible, bespoke approach will allow. Bootstrap will already have an 'opinion' on things such as this which may not be aligned with the requirements of the project.

5) Risk

The unknown risks of a framework present the most significant worry because so much has already been assumed and built. Admittedly, there are inherently more unknown risks with a framework when the developer/s do not know it intimately.

Will it be flexible enough? Will it result in reverse engineering? Will the code be less performant? Will the site end up looking like yet another Bootstrap site? Will it slow progress rather than speed it up?

I cannot predict or negate these unknown risks - however, when coding from scratch, a much greater and more intimate awareness of risks can be cultivated, and greater freedom/flexibility is offered to counter them. I have many years of experience informing this statement - but I do not have the same experience and confidence using Bootstrap.

6) Experience

I am a front-end developer of 12+ years and my experience and instinct is telling me that Bootstrap is not the best way forward for this particular project.

This is based on the knowledge I have gained in my career, on having used Bootstrap in the past, and on what I have seen of the project, design and timeframe.

This topic is, of course, subjective and the finer details of a build can often only be known in its undertaking. However, in my personal experience, frameworks can limit the flexibility we have available to adapt to issues from all disciplines (design, build and backend).

QUERIES

Will what you provide be 100% cross-browser?

We will test x-browser/device based on the analytics. 100% is a not a realistic goal, even for a framework. There are too many browser, operating system and device combinations to ever deliver such. Instead, we will take an approach of progressive enhancement and ensure that the site is as usable as possible even when certain technologies are unavailable. When it comes to testing, the level of support depends on the time available to spend on quality assurance.

Will you provide updates / fixes for browser incompatibility as and when new browsers are released / issues discovered?

Depends on service level agreement. No code is future proof (inc. Bootstrap) and not code is infallible (see previous answer). We would always aim to discover and fix as many bugs as possible for delivery, but this will never be watertight - with or without Bootstrap.

Bootstrap (or other such third party libraries) are robustly tested to a degree that is hard to match with something custom especially across mobile devices?

Yes, so long as we do not deviate from the Bootstrap UX/design/patterns. Customising, expanding and adding to any framework will require the same level of testing (see points 3 and 4).

I guess we’re bootstrap neutral as well so what I’d like to understand more is what we would be using instead?

- We will be creating a bespoke framework that is fit for purpose.

- It will make use of standardised coding conventions outlined by BEM (http://csswizardry.com/2013/01/mindbemding-getting-your-head-round-bem-syntax/) and SMACSS (http://smacss.com/)

- The code will be focus on leanness, performance, compatibility and clarity, with specific consideration for both backend integration and future development.

- Sass and jQuery will be used to supercharge the development of CSS/JS.

- The build will be highly modular, allowing for components to be tested in isolation and highly reusable.

We’d always opt to build onto a third party (open source) framework where we can, because you have a greater level of compatibility with less risk.

See previous thoughts on risk. A benefit of a framework is definitely in the documentation, testing and community support - but we have presented counter arguments to this.

Our current site is currently not using any obvious front end framework and so a lot of our time is spent “making it work in IE” or “sorting it for iPad" and other such scenarios.

So let's build it better! :)

We’d like to avoid this.

So would we! ;)

-- email ends --

We discovered in due course that the desire to use Bootstrap was actually masking a different issue entirely - the in-house developers had been let down by the previous team and build, and were understandably worried about history repeating itself.

Thankfully, we were able to allay their concerns and we received the go-ahead to proceed without Bootstrap. We also made the codebase available to them throughout the entire build process and this level of transparency helped build on both trust and understanding of the code.

After delivery, we received some great positive feedback - they were absolutely over-the-moon with the build and they really took to our approach - so much so that they went on to integrate it into their own internal processes.

Not a bad outcome :)

In closing, the question of front-end frameworks is a common and tricky one, and not without contention.

I do, however, want to make it clear that I am not against frameworks - many extremely talented people have kindly clubbed together to produce some excellent stuff - and for free.

For some scenarios, they can be absolutely superb. For others, an absolute pain.

Ultimately, it is not just about choosing the best tool for the job that matters but also demonstrating a willingness to explain and justify that choice.

Special thanks to Gary Lake, Mark Skinner, Andy Mantell and Joel Mitchell for their input.

#frameworks #bootstrap #web development #patternlibrary #clients

0 notes