The official book of California Stylesheets
(and that's okay)
It's a book about writing CSS.
And not writing CSS.
The official book of California Stylesheets
(and that's okay)
It's a book about writing CSS.
And not writing CSS.
It makes sense that if you suck at Photoshop, and you suck at HTML, that you also suck at Photoshop-to-HTML.
Photoshop-to-HTML is the time-honored process of doing too much work in Photoshop before doing more of that same work in HTML, except the work in HTML is now complicated by the fact that you have to honor the stuff that was made in Photoshop.
Also, you have to go back and update anything in Photoshop any time the HTML changes.
It’s sort of like making a new city. You’re in charge of how the city looks. So you build another parallel city nearby that shows how all the buildings should look. But don’t worry. This is all justified because it’s not a real city. It’s just a bunch of facades built to the same sizes. And it’s pixel perfect! So it looks real. But the buildings don’t have insides so you didn’t just waste a whole bunch of work building your own city. That would be absurd.
Stop.
Just stop.
Stop having two versions of your product.
You don’t need pixel-perfect mockups of every corner of your product recreated in Photoshop. Or Sketch. Or Figma. They’re all great programs but can serve as a time prison too. Design to the standards. Design the standards. Show examples of what things should look like. Show impressions of pages. Use these programs to figure out the standards, not to figure out each individual page and every pixel on that page.
Produce assets. Assets should be a visual designer’s main deliverable, not comps. Comps create work for other people. Assets solve a problem and serve as part of the final product.
Figure out the information design problems first. Iterate as you learn. Use Photoshop to fuel this process, not as a blocker of this process.
The best product design product out there, and the closest to the parallel construction technique of Photoshop-to-HTML, is Balsamiq’s Wireframes product. It’s the opposite of pixel perfection. Everything is cocktail-napkin bad, immediately telling the viewer it’s about information design and not visual design.
It can’t be stressed enough how important it is to communicate this to the viewer. Anything else leaves entire swaths of the team (expert screen-lookers) wasting time on details way, way too early in the project. Not that it’s ever really appropriate to waste time on pixel-perfection details in anything but the final implementations. But doing it early on is particularly damaging.
This doesn’t mean you can’t make cool stuff. You just make it as an asset.
In the information design planning it’s an ugly gray box. Whatever you’re communicating to your user through your design doesn’t need to be communicated to your team. Consuming your own product in this way is self-flattery. It is not the kind of user perspective you want to gain.
Put the gray box in with a label that says “pic of SF.” If you put in a picture of San Francisco, people will spend time arguing over which picture. Months later you pivot to being a social network for poets and nothing matters anymore.
Your product’s design standards should be maintained inside or alongside your web product. Even if it’s an Android app, everyone on the team can always go to websites. If you have an iOS team next year, not everyone will be able to look in your Android codebase or in your Android app for your brand color hex codes and padding values. But everyone can look at your website.
If you use a preprocessor (CASS doesn't), that’s a great place to put them. Or just write them into your style guide. Or maybe a yaml file tucked away somewhere. I don’t know. It’s your project. Just don’t put them in Photoshop. Your team should never be waiting on Photoshop to load.
CSS custom properties and/or preprocessor variables are a handy place to put your design variables.
Everything is easier because there’s one spot for things like padding, margin and base color. It’s also canonically defined (once) right there in the place developers new to the project are most likely to look for it: At the top of the file.
Look at the top of any California Stylesheet for these settings, organized into sections of typography, layout and more.
The Gumroad version contains a secret chapter that spills the dirt on CSS preprocessors, a tech CASS no longer uses.
