The Software We Pay For

We did a Web Developer Economics series a few years ago, where we looked at the various costs of being a web developer:

  1. Web Developer Economics: One-Off Software Costs
  2. Web Developer Economics: Hardware Costs
  3. Web Developer Economics: Monthly Service Costs
  4. Web Developer Economics: The Wrapup

I’m sure some of that software and hardware has changed since then, but the spirit is the same. It costs money to have the things you need to do this job.

I just wrote a similar article, but from the perspective of a business paying for the software it needs. That link is to Medium, but it was posted on the CodePen blog originally. Just giving that a shot to see what all the hubbub about Medium is about.

Direct Link to ArticlePermalink

The post The Software We Pay For appeared first on CSS-Tricks.

Prototyping in the Browser

Prototyping animations and interactions is vital for a number of reasons: they can make your interface feel deceptively fast, they can help focus the user on a specific task, and they can provide a better sense of the current state of your application. Is data being loaded? Is something now unclickable? How long do they have to wait until they can perform an action?

At Gusto, I’ve been working on a lot of tiny interaction details and prototypes lately for these very reasons — sadly there’s not much that I can show you all in detail just yet. But, I think the process of how I’m doing this is far more interesting than what I’m actually working on so that’s what I’m going to share here.

The problem I’ve faced with prototyping animations comes down to the tools because they ultimately feel restrictive to me. Whenever I’ve experimented with them in the past, I feel like one hand is always tied behind my back. It could very well be that I’m not using them correctly, but I feel that none of them really mimic browser behavior quite right and, although I’ve been fascinated to watch tools like Framer, Marvel, Zeplin and Principle gain traction, I don’t think they’re for me. At least not yet anyway.

In my opinion, the best way to prototype a lot of interactions is still with plain ol’ HTML, CSS and (gasp!) a sprinkle of jQuery when I need it.

How I’m prototyping today

With my recent project, I decided to invest a little bit of time into CodePen to help our design team quickly prototype things. Here’s what I built:

See the Pen Gusto Prototype: Header by Robin Rendle (@robinrendle) on CodePen.

No really, that’s it. It’s just a simple prototype that looks like our app.

It’s a pen with all the HTML for the app navigation — and it contains all the CSS, too. This way, a designer at Gusto can fork that pen and start writing HTML and CSS to experiment with a specific bit of Figma and Sketch do a much better job of that. Prototypes like this are mostly useful when figuring out finicky UI interactions like tables, spreadsheets and dropdowns — components that can get complicated real quick.

To make this prototype, I simply copied and pasted all of the HTML and CSS from our web app into a new pen. (In the future, we should probably have a system where we’re always prototyping with the latest up-to-date code from our app but, for now, I think this is a fine starting point.) This pen contains all of the menu and navigation items we need to make it look like the Gusto app. We have a a separate pen for the footer which closes off all the divs that we open up in the header. Lastly, we have one more pen that imports those two other pens like so:

<!-- HEADER -->
[[[http://codepen.io/robinrendle/pen/481a88853820067752e28cdb479c91f3]]] <!-- HTML GOES HERE -->
<h1>App Prototype</h1>
<p>You can fork this pen and write all the HTML and CSS you need to prototype interactions and explore ideas right here in your browser.</p> <!-- FOOTER -->
[[[http://codepen.io/robinrendle/pen/0dcaa93954f06f4d03b7e23e8ea54cac]]]

See the Pen Gusto Prototype: Full by Robin Rendle (@robinrendle) on CodePen.

What’s that weird syntax with all the [[[ ]]]? That’s the HTML Include syntax for CodePen. If we put the URL of a pen in between those brackets, CodePen will fetch the code from that pen and place it straight into this new pen. That’s it! Pretty sweet, right?

To wrap things up, I wanted to make a couple of notes about what I’ve learned with this new setup.

Lesson 1: Prototypes should be super easy to share

Ideally, prototypes are easy to share with other designers and engineers, exceptionally fast to get setup, and don’t require prior training or expertise — and Codepen is perfect for that. I like this setup for a bunch of reasons. For one, we don’t have to teach designers CoffeeScript like we have to with Framer and we don’t have to run React or Vue workshops to get them up and running with a complex prototyping app.

Yes, folks do need to learn how HTML and CSS works to make prototypes like this but I think learning the very basics of those two languages is vital for a designer working on the web anyway.

Lesson 2: Bad code is a-okay

Here’s another thing I recently learned while doing prototyping: bad code is okay at this stage. In fact, we should be writing terrible, unforgivable code when prototyping in the browser. We ought to write the sort of CSS and HTML that would keep Harry Roberts up at night because clean, maintainable code gets in the way of the design process when the focus should be on iterating as quickly as possible.

To be quite honest, I don’t care about front-end best practices when I’m making these prototypes — I don’t think about BEM, semantic HTML or even performance. Oh, and I certainly don’t care about the most proficient way to render a React thingamijig.

As long as we ditch all of that prototype code and start from scratch later, and as long as there’s step to break the design into components and ensure that those lego pieces are maintainable, well documented, and highly performant in our production environment, then I believe that writing bad should not only be allowed, but actively encouraged.

This leads to my final takeaway.

Lesson 3: Designers and developers should always translate their code

I reckon that the first time a designer and/or front-end developer writes code, it should never be in a production environment. Having the leeway and freedom to go crazy with the code in a safe environment focuses your attention on the design and making it compatible with a browser’s constraints. After this, you can think about grooming the code from a hot, steaming heap of garbage into lovely, squeaky-clean, production-ready poetry. Translating the static mockups into an interactive prototype is the first step, but it’s vital to have a next step to enforce your code standards.

Does your app use BEM? How should you abstract each of these components into separate files? What do you call all of these new components that you’re introducing into the design system?

I believe all of these questions are easier to answer once you have that interactive prototype. And I would highly recommend that designers and front-end engineers alike experiment making little tools like this. It might feel a little odd at first, but I promise that it will produce much better work in the long run.

The post Prototyping in the Browser appeared first on CSS-Tricks.

4 Reasons to Go PRO on CodePen

I could probably list about 100 reasons, since as a founder, user, and (ahem) PRO member of CodePen myself, I’m motivated to do so. But let me just list a few here. Some of these are my favorites, some are what PRO members have told us are their favorite, and some are lesser-known but very awesome.

1) No-hassle Debug View

Debug View is a way to look at your the Pen you’ve built with zero CodePen UI around it and no <iframe> containing it. Raw output! That’s a dangerous thing, in the world of user-generated code. It could be highly abused if we let it go unchecked. The way it works is fairly simple.

You can use Debug View if :

  1. You’re logged in
  2. The Pen is PRO-owned

Logging in isn’t too big of a deal, but sometimes that’s a pain if you just wanna shoot over a Debug View URL to your phone or to CrossBrowserTesting or something. If you’re PRO, you don’t worry about it at all, Debug View is totally unlocked for your Pens.

2) Collab with anybody anytime

Collab Mode on CodePen is the one that’s like Google Docs: people can work together in real time on the same Pen. You type, they see you type, they type, you see what they type.

Here’s what is special about that:

  • There is nothing to install or set up, just shoot anybody a link.
  • Only you need to be PRO. Nobody else does. They don’t even have to be logged in.

Basically, you can be coding together with someone (or just one or the other of you watching, if you please) in about 2 seconds. Here’s a short silent video if you wanna see:

People use it for all sorts of things. In classrooms and educational contexts, for hiring interviews, and just for working out problems with people across the globe.

Drag and drop uploading

Need to quickly host an asset (like an image) somewhere? As in, quickly get a URL for it that you can use and count on forever? It’s as easy as can be on CodePen.

If you’re working on a Project, you can drag and drop files right into the sidebar as well:

Save Anything Privately

Privacy is unlimited on CodePen. If you’re PRO, you can make unlimited Private Pens and Private Collections. You’re only limited in Private Projects by the total number of Projects on your plan. This is the number one PRO feature on CodePen for a variety of reasons. People use them to keep client work safe. People use them to experiment without anyone seeing messy tidbits. People use them to keep in-progress ideas.


I didn’t even mention my actual favorite CodePen PRO feature. I’ll have to share that one some other time 😉

Go PRO on CodePen


4 Reasons to Go PRO on CodePen is a post from CSS-Tricks