New Aug 19, 2024

Chris’ Corner: Filtering

Company/Startup Blogs All from CodePen View Chris’ Corner: Filtering on blog.codepen.io

We updated the Your Work section of CodePen recently. See, it used to have a dropdown menu like this that we labelled “View”:

This allowed you to scope down the Pens you were looking at below (in a Grid or List view). A single <select> element like that started to feel a little awkward. Especially when we added something to it — see the temporary “2.0 Pens” option there for our alpha testers. What if you wanted to look at template Pens that are also forks? Or forks that you’ve made private? Or your private 2.0 Pens? None of that was possible with a single dropdown.

So we did this:

This turns all those choices about what you want to see into individual options you set independently. We didn’t change any of the defaults. Now you can combine any of the filters, and even combine them with filtering by tag. Hopefully this helps you drill down into your own work and find just what you need easier.

From our perspective, it helped us clean up our internal APIs for this kind of thing, which always feels nice.

We try to remember (as in, use localStorage) what filters you have last set, so that you don’t have to re-set things next time you come back. But we also update the URL when you pick filters, so you can bookmark or share a URL with particular filters. For instance:

https://codepen.io/your-work?access=public&fork=true&template=true

But the localStorage makes it so you don’t have to have the URL params set, we’ll still try to remember. So far so good!

Note that we chose URL parameters there. It’s always a fine-line of what should be part of the path of a URL and what should be relegated to a query parameter (or even a hash, sometimes). This is (I’m fun at parties) endlessly fascinating to me.

Like this:

https://codepen.io/your-work?fork=true

Could be:

https://codepen.io/your-work/forks

Which has certain nice characteristics. You could argue it’s cleaner looking. You could say it’s setting up a hierarchy with meaning, meaning you forks/private could mean Forked Pens that are also Private. But hierarchy is key there… it doesn’t actually matter which order those would go in. private/forks would meant the same thing, so it’s not really a hierarchy. URL params keep it all at the same level, i.e. ?fork=true&access=private.

URL params also don’t lock you into a certain URL format forever the way making new paths does.

We made a different choice, long ago, when it came to your user profile. For instance:

https://codepen.io/chriscoyier/pens/public

There, “pens”, and “public” could have been URL params, but somehow it felt better to have things be part of the path then, and I do still think that having something like /pens/ in there does make hierarchical sense still. Although I would be the decision was made then because of our roots as a Ruby on Rails app which encourages patterns like these.

I don’t know that we’re going to win any awards for URL design, but the fact that it hasn’t caused us much grief over our many years of existing is testament that we’ve done OK. There are a few things I can think of that we maybe could have done better. Sometimes I’m jealous of apps that use like /u/username for profiles, meaning the “root” of the path isn’t all usernames and you don’t have to blacklist usernames for internal URLs, although I do kinda like the look of the URL with the username first I have to admit. Also our URL’s that have /pen/ in them really mean “the editor” and the different views replace that, like /full/ means Full Page view… but it’s still a Pen, so that I’ve never 100% loved. Some of that Pen stuff gets cleaner as we move toward our new version of CodePen.

I’ll leave you with Jim Nielsen’s Examples of Great URL Design, for fun.

Scroll to top