Displaying Website Projects in Web Development Portfolios

February 1, 2016

Categorized: Development, Workflow

There are multiple methods for displaying a website project in your portfolio, with pros and cons to each. This is a very frequent question as far as I’ve seen. Many people are unhappy with flat screenshots, and want to show something more. So they wind up thinking about WordPress multi-site and other very complicated solutions — but there are easier ways to display your projects in web development portfolios.

Your Portfolio: Clients

This might be a given for some seasoned freelancers, but it’s worth emphasizing, it’s not something that occurs to newcomers: specify in your contract you reserve the right to display your project on your portfolio.

Make it clear to the client, too — especially if it’s their first time. Most people don’t have the first clue about your job, after all. They may have looked at your portfolio, but it might not be immediately apparent that their project is going to end up there, too. Just cover your bases, specify it in your contract and (if necessary) remind the client outside of the contract regarding project display.

If the client wants to negotiate on display, feel free to negotiate with a higher rate or similar. I personally probably wouldn’t turn down a project just because I couldn’t use it in my portfolio, but your mileage may vary.

Ways to Display Website Projects in Web Development Portfolios

Screenshots

Screenshots are the go-to for most, and for good reason. They are easy, quick, and most anyone can take a simple screenshot with just the keyboard (or the Windows Snipping Tool, if you’re into that!).

Pros

  • Simple, easy, quick
  • Properly compressed screenshots are usually smaller than single page saves, definitely smaller than whole site copies
  • Responsive screenshots

Cons

  • Flat: no interaction unless you take videos/GIFs
  • Tedious to take screenshots of several pages, even more tedious with videos/GIFs

GIFs and Videos for Interaction

Because the con of screenshots — a lack of interaction display — is a big one, especially for animation-heavy projects, you might also want to take GIFs or brief videos of interaction you really want to show off. Credit all the way to a reddit user who pointed out this technique.

Single Page Screenshots — No Photoshop Stitching

I use Awesome Screenshot in Firefox and Full Page Screen Capture in Chrome to get the whole page easily without requiring a bunch of Photoshop stitching. Neither program really likes repeating, fixed elements (such as back-to-the-top buttons or fixed position calls to actions, or fixed backgrounds). But other than that, both the Firefox and Chrome extensions have worked marvelously for me in the past.

Single Page Save

You can also save individual pages if you want to display more interaction and allow the viewer to more freely explore your design. This is pretty easy in any browser — just hit CTRL + S or go to File > Save Page As (Firefox). This is a very low-fi way to capture all of the HTML, CSS, and images on a given page.

Pros

  • Simple, relatively easy, quick
  • Allows viewers to see interaction (links, dropdowns, animations)
  • Removes possibility of live site going down/changing in ways you did not anticipate

Cons

  • Enforcing responsive mode requires further edits
  • Painful method of saving entire site
  • Edits are necessary

At most I’d save an important page or five (e.g., homepage, regular content page, e-commerce shop page, product page, etc.). There’s no reason for me to show three pages of regular content or seven products, after all — if they’re all the same design/appearance/functionality.

Whole Site Copy

This actually comes up surprisingly often in the web development communities I’m a part of. I try to make sure to outline the flaws and problems in implementing this method, and usually steer my recommendation toward single page saves or whole-page screenshots.

Pros

  • Simple, relatively easy, quick
  • Allows viewers to see interaction (links, dropdowns, animations)
  • Removes possibility of live site going down/changing in ways you did not anticipate

Cons

  • Enforcing responsive mode requires further edits
  • Probably overkill, unnecessary for most viewers
  • More likely to cause issues with clients than other methods
  • Edits are necessary

Tools for Whole Site Copies

If a whole-site copy is desired, though, there are automatic tools — such as HtTrack or wget — to make the job easier.

Edits Necessary: Single Page Save and Whole Site Copy

These are really important edits necessary for single page save or whole site copy:

  • Noindex it or even throw it behind an Apache login to prevent Google from indexing your copied site and penalizing your client.
  • Remove client’s Google Analytics and other traffic measurement things, don’t screw up their data with your copy.
  • Make sure all links point only to your copied site, don’t drive weird traffic to your client.

You’re getting flat copies of the site, single HTML files — so you’re in for some pain if you’re editing a lot of files.

Preferred Technique?

Personally I just do screenshots. That’s enough for me!