Updating our web design breakpoints using Parabola

Updating our web design breakpoints using Parabola

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Automate complex, custom data workflows

Build, document, and share your first Flow today.

Our customers make some amazing things using Parabola: but often we get asked how Parabola uses Parabola. We certainly get a lot of use out of our own product here — especially things like sales reporting, customer support workflows, and internal communication.

But even the Design team gets use out of Parabola 🎨 🙌! By building a Parabola Flow, I’m able to keep my Design team’s browser width breakpoints up-to-date and accurate, giving us consistent confidence that we’re designing for the right screen sizes. This simple automation saves me hours and gives me access to fresh data I otherwise wouldn’t have.

Breakpoints help us design for varied screens

Breakpoints are just a fact of life in web design: a Designer wants to make sure that their Designs — a UI, a website, or even the underlying grid for all of those surfaces — are arranged well for all viewers across varied device types and screen sizes.

A user could theoretically use a screen that is any pixel height and width … but we can’t design for every theoretical situation, so it’s best to know what the most common **sizes are for the people that view your products. We want to answer questions like …

  • Is it appropriate that we start our designs in a 1440px desktop view? Is there another base width that would be more representative of our desktop users?
  • When we plan for “super wide” monitors; how wide should we realistically plan for?
  • Can we safely design for 375px as our “mobile width” (like a mainstream iPhone size), or are we missing on a lot of our site visitors that use smaller viewports?
  • Do I really have to design for mobile at 320px wide 😆!?

By isolating and designing for these breakpoints, you can keep your design process workable but still provide reasonable coverage when designing across many screen sizes.

An example of Parabola’s website breakpoints being used in a project

Why this works so well for us

Before we get into the detailed Flow assembly, I’ll give away the ending: I built a Parabola Flow that sends me an updated website breakpoints report automatically every month 📊. And automating this analysis saves me time, gives my team confidence, and extends my capabilities as a Designer at Parabola.

The powerful thing about this scheduled Parabola Flow  — this Design task automation 🕶️ — isn’t just that it saves me time in building the report. Honestly, I’m on a busy Design team and I normally wouldn’t bother assembling **this report very often; in the past, I built it about once a year and then relied on increasingly outdated data whenever I needed to refer to our breakpoints. The report was too time consuming, so we just hoped 🤷 that our old breakpoints were still representative of our current audience.

Now, that isn’t the case! Parabola isn’t just saving me a few hours here and there: it’s doing work for me that I wouldn’t otherwise do; as if I’d **hired a person to expand the output of my team. It’s magical stuff ✨, and really makes me appreciate working on this product. Parabola isn’t just for Data Scientists or Operations people: even a Product Designer like me can give themselves more leverage and productivity using an automation tool as easy as Parabola is.

Now, for the nitty gritty …

How I used to assemble this report in spreadsheets

I typically use Google Analytics (“GA”) to find out what screen sizes and device types that people are using to view the site or product I’m working on. GA has these categories — namely device category and browser size — available out of the box, so as long as Google Analytics is installed on your site, you should have access to at least some of this information.

Device Category traffic by Week, in Google Analytics

By building a custom GA report with these columns and sending that to a Google Sheet, you can work with this data however you like!

But once you get that data into a spreadsheet; that’s when the real work starts:

  • ❎ As is the case with any Google Analytics data, it’s more directionally useful when you remove null data and other errant rows
  • 🖥 To get a reasonable analysis per device type (i.e., Desktop, Mobile, Tablet), you have to run that as separate reports or break it up in your spreadsheets by type. You can do this using Pivot tables or Filter formulas.
  • 🤦 Browser sizes come in as the full dimensions in a text string, formatted like: 1440x820.
  • There are many common browser widths — the key number to come up with to create breakpoints — but when you add in all of the varied heights that users’ browsers are, it becomes a long-tail list of tiny categories that’s difficult to analyze.
  • So we need to write a formula to extract only the width number from this string, and then group all of this data by those isolated width values.
  • 🖩 You get raw numbers from Google Analytics, but to understand the relative share of a browser width — e.g., users with a 1440px wide browser represent 9% of your Desktop users — you have to write those array formulas yourself.

At the end of all that ☝️ spreadsheet wrangling, you have your report! You and your team can then make decisions about what screen widths you should be optimizing for.

Hooray! 🎉

But … that was a lot of work! And the data you just extracted is only a snapshot of the data range you just collected (e.g., the last 30 days of visitors to your site). If you want to check this again or keep your breakpoints data up-to-date, you have to go run the source report again in Google Analytics, send it to a Spreadsheet, and do the process all over again.

Why solving this in Parabola works better

But, since I started using Parabola, I don’t do that old process anymore. I also get to have up-to-date breakpoints, at my fingertips, anytime I want them! And that’s because I replaced this tools-and-spreadsheet labor with a Parabola Flow that automatically pulls fresh data and runs the calculations needed to give me the final results.

It’s automation: Design edition.

How this Parabola Flow works

A zoomed-out view of the entire Flow

This Parabola Flow takes data from Google Analytics, arranges and runs calculations on that data, and breaks out the share of (%) device widths by device type. Let’s break it down …

Step 1: Pull in fresh data, anytime

First off, we need to get the data from Google Analytics: fortunately, Parabola has a Pull from Google Analytics step that can do that directly (and per your settings and preferences).

The “Pull from Google Analytics” step in Parabola
  1. First, authenticate your Google Account
  2. Then, indicate the columns ****(called “Metrics” and “Dimensions” in Google Analytics) and date/range you want to pull data for
  3. And refresh the data to see your results.

For this Flow, we want to pull in “Users”, “Sessions”, “Pageviews”, "Device Category”, “Browser Size”, and “Page”; and I’m pulling it for the prior 2 months on a rolling basis — this is so I can schedule the Flow to run monthly and it’ll give me an up-to-date set of visitor data.

Step 2: Prep the data and extract widths

Once we’ve got that data pulled in via the “Pull from Google Analytics” step, we need to do some cleanup before we can calculate the browser width shares per device.

In the old way, I’d do all of this manually in a spreadsheet 😱, defining all of the ranges, writing all of the formulas, and maybe breaking out a few pivot tables. But in Parabola, I can just pull a few Parabola Steps into my Flow to make this process simple, readable, and repeatable.

The first card of this Flow: getting the data and prepping it for calculation

Here’s how we prep this data for calculation:

  1. Use the Filter Rows step to filter out irrelevant data — like ‘null’ browser sizes and pages not from our public website — that would throw off our calculated percentages
  2. ⭐ Extract the actual browser widths — e.g., “1440” (pixels) — from the “Browser Size” column that usually reads things like “1440x890”
  3. ⭐ Use a Sum by Group step to roll up all the now-duplicate Width values — e.g., all “1440” widths regardless of browser height — into a single line item for each width
  4. Remove strange outliers, e.g., screen sizes that aren’t realistic or may be a result of some data collection error.
  5. Enter an Identifier column (like “Any”) that serves as an identifier above all of the Device Categories. This is so I can join datasets later on (more on that then).
  6. Per your preference, use Format numbers (e.g., format widths from “1440” to “1,440”)

Step 3: Calculate shares by device type

Once that data is prepped, we can break it out by device type and make two analyses: one for Desktop, and one for Mobile. (I chose not to include Tablet because our share of Tablet users is so low every month, per the report resulting from this Flow).

Analyzing the share of screen widths, per width, for Desktop then for Mobile

Keep in mind that these steps are largely the same in both of the cards above; they’re just breaking out one report for Desktop browsers and one for Mobile. Here’s how each card calculates the % share of visitors per browser width (per device type).

  1. Filter per device type (e.g., Desktop)
  2. ⭐ Break off a branch to sum up the total amount of Users and Sessions that occurred on the website during this time. (I renamed those columns to “Total [X]” to keep them separate from the columns that they’ll be joined to on the next step)
  3. Use a Combine tables step to join the original data set to the total. This gives us both a column for the number of Users/sessions per width, and also one with the total amount on every row. (This is when that “any” identifier column comes in handy)
  4. ⭐ Use a Insert Math Column step to calculate the percentage of total from each width, for both Users and Sessions
  5. ⭐ Use the Sort and Insert Running total steps to show not just the share that each width makes up, but how much it and larger sizes make up in total. This let’s you say things like “We’re ok designing the largest breakpoint at 1900px because that size and larger make up ~13% of our Desktop users … and it’s a long tail from there.”
  6. Use Column Select and Format Numbers to clean up the data to your liking (i.e., with no wasted columns, and in %s).

We can then duplicate that Card and make tweaks for the other format (e.g., Mobile instead of Desktop), and send those both to separate tabs in a Google Sheets document. Here’s mine:

The final spreadsheet of the breakpoints report

In this spreadsheet, I have tabs dedicated to three calculations in this report. Here I’m showing the “Widths, desktop” tab and some of the data. I’ve applied conditional formatting to this in Google Sheets to help me spot outstanding breakpoints, but the Parabola Flow provides all of this data (and refreshes it each month with the conditional formatting in tact).

I took a look at this this month and manually write in some potential breakpoints. I’d seen 1440px before (it’s a common one on laptops from a few years ago), but these spikes around 1350px and 1260px are interesting!

Step 4: Schedule the report

Those new insights ☝️ are easy to come across because I have this scheduled to run monthly in Parabola: Parabola will notify me each month when it runs the updated version of this report for the prior 60 days. You can do that from the Live screen of this Flow after you run it.

Scheduling a Flow to run in Parabola is easy!

And that’s it! Now, instead of relying on outdated breakpoints data — and/or assembling this data by hand every once in a while — this report populates a spreadsheet automatically every month and sends me an email notification so I can check it.

If you’re interested in building similar Flows to help your team save time and up-level their work, you can start building your own Flow for free by signing up for Parabola. If you’re a Designer (or anyone else!) who wants to build this product with us, take a look at our open roles.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.