Table of Contents for
Responsive Web Design Patterns

Version ebook / Retour

Cover image for bash Cookbook, 2nd Edition Responsive Web Design Patterns by Chelsea Myers Published by Packt Publishing, 2015
  1. Cover
  2. Table of Contents
  3. Responsive Web Design Patterns
  4. Responsive Web Design Patterns
  5. Credits
  6. About the Author
  7. About the Reviewers
  8. www.PacktPub.com
  9. Preface
  10. What you need for this book
  11. Who this book is for
  12. Conventions
  13. Reader feedback
  14. Customer support
  15. 1. Creating a Home for Responsive Patterns
  16. Why and how to create a responsive site
  17. Breaking websites down to their patterns
  18. Building a home for your patterns
  19. Summary
  20. 2. The Main Stage – Building Responsive Layouts
  21. Most popular layout patterns
  22. Creating complex systems
  23. Summary
  24. 3. Make Way for Responsive Navigations
  25. Responsive navigation patterns
  26. Summary
  27. 4. From Static to Dynamic – Embedding Media
  28. Responsive image patterns
  29. Understanding sliders and carousels
  30. Implementing videos
  31. Summary
  32. 5. Gathering and Displaying Information
  33. Responsive table patterns
  34. Summary
  35. 6. Combining Responsive Patterns
  36. Continuing to look for patterns
  37. Your pattern library is not done yet!
  38. Summary
  39. 7. Ship It – Finalizing Your Pattern Library
  40. Getting ready to handoff
  41. Publishing your library
  42. Further exploration
  43. Summary
  44. Index

Chapter 7. Ship It – Finalizing Your Pattern Library

When you are knee-deep in a project, it may be hard to keep your pattern library organized. You have deadlines rapidly approaching. It's difficult to be proactive and organize your patterns before or during the project. It can be easy to say, "I'll just do that later" when it comes to creating your responsive pattern library. But when that project is actually done, don't most of us need a break? We might want to take a step back from the project and not touch it for a while. And when we do come back to it, if we ever even do, the memory of how and why we made a pattern a certain way can be a little faded. And if we worked with other people, they may be gone or too busy to contact. The chances of making a pattern library that would be as good, or as thorough, as it would have been if we did it first are decreased.

Recently, I was asked to hop on a project that was completed and launched almost a year ago. I worked on it then, but only in a supporting role. Now, the client wanted some small changes to fit newer content. I quickly realized that I remembered very little about the website's structure and had to relearn a lot. At some point, my project manager asked me if there was a style guide for the website. After a lot of digging, I could not find anything. Style guides and pattern libraries were standard for all new projects, but like I mentioned, this one was completed almost a year ago. So, when I was asked to make updates, I had almost nothing to go on. When the client wanted to make changes themselves, they had no point of reference.

I searched through our CSS files (specifically, Sass in this case) to find guidance for typography, icons, and general spacing. I had to look at the JavaScript filenames to find what plugins we used and Google the abbreviations to find documentation. It took up a lot of my time, and the clients, to make sure all the changes adhered to their brand and that I wasn't recreating something a past developer already accounted for. And all of this was made even more difficult because the website was responsive. That means everything shifted at different screen sizes. So, I had to account for these shifts as well. And when I made a change, or created something new for the project, it had to shrink and grow with the rest of the system. All projects benefit from pattern libraries, but responsive projects need it the most. There are just too many variables constantly fluctuating for us to keep track of without some sort of tracking system. At the very least, this book will help you identify the bare minimum of what you should be recording in your own pattern library. Documenting your project can save you and your team time. Layout, navigation, media, and data patterns are just the basics. Each project and client requires a different level of documentation. As reviewed, a responsive library can also include what you would typically find in a style guide. You will need to decide how much your responsive pattern library will hold. Together, we will go over how to incorporate a pattern library into your project and what else it needs before it is complete. In this final chapter, we will be discussing:

  • At what stage of the project should the pattern library be included?
  • Final touches needed to complete a responsive pattern library
  • Resources for further information on pattern libraries

When to create your pattern library

Pattern libraries can be incorporated into a project at any stage. So, if you are already working on something, it is never too late to add one. The phase of a project's timeline you choose to create your pattern library can impact the way the library is used and how beneficial is it to the project team. The responsive pattern library is included at the beginning of development, during development, or after development. Let's review the pros and cons of each stage.

After development

You may have guessed that I personally do not like waiting until the end of the project to create a responsive pattern library. As humans, we are prone to walk into rooms and forget why we went there in the first place. Yes, some of us have better memory than others, but I still don't trust our minds enough to recall decisions made weeks or months prior. If we put the library together at the end of our project, the patterns may suffer. It can be harder to remember the techniques we used. We may not remember to document all the patterns. There are projects with zero time to make a pattern library during development and it gets pushed to the end. That's okay. It happens. Sometimes, clients don't want to spend time or money on one and there's nothing you can do. But a pattern library made after a project is still better than no pattern library at all. And, if you do this, you will still have something to catalog patterns for you to refer to when working on future projects.

During development

Responsive pattern libraries are most commonly built during development. Usually, a project has its development milestones all mapped out. As each batch is worked on, developers save snippets of code into their library as they move along. Maybe a developer starts with writing the CSS for the typographic scale and saves it in the pattern library. Now, this can be an acceptable way to use the pattern library, but it is not seeing its full potential. One of the best parts about a digital responsive pattern library is that it allows for collaboration. If a team is working on this project, perhaps the developers can share the typographic scale in the library with the lead designer on the team. The designer can then check the values, making sure nothing got lost in the conversion from Adobe Photoshop (or whatever tool was used) to CSS. Yes, just like a real library, responsive pattern libraries are archiving tools. But also like a real library, what's the point if no one ever uses it?

A responsive pattern library also breaks down a system into its pieces. These pieces are reusable and easier to maintain. A team then has one place to find all of a system's pieces, and the ability to build with them. Duplicate patterns can be avoided. Fixes can quickly be applied to patterns that will then apply globally. Patterns can also be duplicated and edited to meet a new requirement. Working with a responsive pattern library can change how you and your team develops websites. If you are ready to embrace working modularly, incorporate responsive pattern libraries early into your project.

Before development

Responsive libraries can be the most useful when being used before major development even starts. For most web projects, there is a design phase and a development phase. Usually, there is some development "kick-off" or "handoff" in the middle where the designers go over their compositions with the developers before they start their part. Slowly, we are seeing a gradual overlap happening between these two phases as technology and software advances, allowing us to design in the browser to get to development a whole lot faster.

We need this rapid development because there is so much more to making websites today. The design phase of the projects usually produces composition of the website, mostly at large screen sizes. Sometimes, there is a mobile design, or three, showing what the page will look like at smaller sizes. But rarely are there enough designs for the developers to know what every single page, and module, will look like at every single screen size. And you know what? Maybe the designer doesn't even know. Responsive websites take more time to plan because there is just more to design and develop. A responsive pattern library allows for an opportunity to make this planning easier.

Using a responsive pattern library before major development can be like developing in a sandbox. Designers and developers can sit down and look at the important patterns that make up the website and create them first. Then, when it comes to implementing the patterns, the developer is not left scratching his or her head thinking, "What is this supposed to look like at 700px?" It can be tough though, with milestones already laid out and time running out, to make time for developing inside a responsive pattern library.