Let's get strategic - and break some points. Not share-points but breakpoints :).
To understand the challenge: we're creating a website and want it to be responsive. One of the aspect of a responsive site is that it responds to the screen size - presenting the content as best as possible at every possible screen size - and there are thousands of screen sizes - multiplied by browser types and you'll get a lot of test scenarios - too many, to be exact. So we need a strategy.
Now without getting into the syntax yet, this responsive behavior is made with CSS and basically consists of rules like
- the logo is 200px wide
- if the screen is less than 799px wide, then the logo is 180px wide
- if the screen is between 533 and 678 wide, the logo is 20% of the full width
And we need lots of these rules, like for
- page alignments
- margin size
This looks simple enough - and it is. A typical web page can easily have many hundred rules which are valid right now, and many more which don't have an effect till the screen changes. And this is the main problem: You
must stay very, very organized to not f*** up. And then you'll have to test all this.
But there is an important shortcut: breakpoints
A breakpoint is a specific screen size, where a lot, if not all, display rules change. In between these points almost no rules change. That's the magic: by organizing just a bit, everything becomes manageable. This blog shows a few bits of CSS-examples in case you still have no idea what this would look like...
Normally you'll have 2-5 breakpoints, and this means you'll plan for 2-5 scenarios during which all factors stay the same. This is much easier to define and test. And it's much easier to write effect-JS for these elements, because I have a controlled environment.
What happens when you don't use breakpoints?
Then the web designer will continuously optimize each factor - one at a time. So he'll try some screen size and say "i think the logo is too big" and adapt it. This might have a side effect on the margins, which accidentally changes the width of content.... This causes a very slow iteration of rather random changes and a lot of combinations and clashing rules. Hard and expensive to develop, impossible to test reliably. And the worst part is: each small change can have a cascade of follow-up changes.
Let's do it right
Here you can find our template used to plan breakpoints. Use it as follows:
- start by filling in goals and overview
- define the breakpoints (page 4) - as few as possible
- then define the rules for each element in each segment
This is great, because I simulate scenarios in my head within seconds - this 2-hour preparation can easily save you 2-5 days of work later on.
So have fun with our template, you won't regret it!
With Love from Switzerland
Daniel & the 2sic Team
PS: Read other parts here:
#2 Responsive vs. Adaptive and
#3 The Good Death of WYSIWYG