Jason Grigsby

Co-founder

In 2000, Jason Grigsby got his first mobile phone. He became obsessed with how the world could be a better place if everyone had access to the world’s information in their pockets. When his soon-to-be-wife met him, he had covered the walls of his apartment with crazy mobile dreams. To this day, he remains baffled that she married him.

Those mobile dreams hit the hard wall of reality: WAP was crap. So Jason went to work on the web until 2007, when the iPhone made it clear the time was right. He joined forces with the three smartest people he knew and started Cloud Four.

He is the author of Progressive Web Apps from A Book Apart and co-author of Head First Mobile Web from O'Reilly. His writing and work helped define the new web standards for responsive images.

He was the founder and president of Mobile Portland, a local nonprofit dedicated to promoting the mobile community where he started the first community device lab. There are now over 150 device labs in the world.

Since co-founding Cloud Four, he has had the good fortune to work on many fantastic projects, including the Obama iPhone App and Walmart's responsive design. Jason is a sought‐after speaker and consultant on web technology and mobile.

Articles

After seventeen years, An Event Apart (AEA) is no more. I know all things must end, but this one hit me hard. It’s been a couple of weeks, and I’m still thinking about what AEA has meant to me, and how much I will miss it.

Components are everywhere, but they are rarely reusable across systems. A design system component is written differently than a CMS editor component. But does it have to be this way? Could we take one set of components and port them to multiple JavaScript frameworks, import them into design tools, and use them for the editing interfaces in content management systems?

I’ve spent years looking for tools that help designers who don’t code participate in a process like the one we use. Something that would let them reuse design system components and would allow them…

Responsive design sprints are a significantly better way to design and build for today's web than the traditional web design process. We provide the receipts. Unfortunately, not every organization can adopt this responsive design sprints. Why is that and what can be done about it?

Web design software makers saw the pain caused by the design to developer hand off and built features to help. Unfortunately, these features don’t help as much as the software makers hope. At best, they are unwanted features to be ignored. At worst, they reinforce faulty assumptions that undermine design systems.

The traditional web design process hopes that static mockups—representing mobile, tablet, and desktop breakpoints—provide developers with everything they need to know to turn the designs into functional web pages. In reality, design happens between breakpoints.

Responsive design broke the traditional web design and development process in fundamental ways. Despite this fact, many organizations continue to use this broken process.

Of all the things that the W3C has published, my favorite is the priority of constituencies. That’s quite a statement given the W3C published the standards that form the foundation of the web and, by extension, my career. But the priority of constituencies has always deeply resonated with me. What happens if we apply it to design systems?

My father-in-law loves the Olive Garden. So of course that's what we offered to bring for our first post-vaccination meal. I grabbed my iPad and passed it around to build an order. Everything went smoothly until I tried to checkout. The checkout button was off screen and impossible to hit. So I investigated why this was happening and took a guess at how much this bug might cost the Olive Garden’s owners.

Web components promise speedier integration. At some level, I understood this. I've even made this exact point while advocating for them. And yet, what happened on a recent project surprised me.