Design & code: (re)launching dadapixel
If you’re reading this, it means that v1 of the new Dadapixel, Design Notes, Project Phoebe, and I AM LIAM sites have finally (re)launched.
The sites are very simple. They’re stark, utilitarian, static, geometric. But building them has been a great learning experience for me, so to go along with the launch I thought it may be fun (and maybe even useful) to write a quick post looking at a few of the things that went into the redesign, some of the rationale, challenges, and even cracks that still need patching up.
But why?
First, why? Why did I brush up on HTML & CSS, learn a little javascript, and start completely over with not one but four websites that all serve completely different purposes?
There are a few obvious reasons: previously all my sites were hosted on Squarespace, they had varying, restrictive, and incompatible design systems, performance wasn’t that great, etc.
But the real underlying reason is that I wanted to learn something new and make my portfolio its own side project.
In just the time it’s taken me to create these sites, I’ve read a lot of varying opinions about designers and their websites and portfolios (or lack thereof). I’ve read both ends of the spectrum — that “good” designers don’t even have portfolios (because they’re too busy), and conversely that designers should really have portfolios and — by the way — they’d better have great UX.
I really don’t fully buy either of these. To the first point, I wonder what we as designers should be busy doing, exactly, to get to the point where we can’t create (and maintain) some sort of portfolio.
Assuming that I as a designer should be constantly occupied with the projects I work on in the daytime is assuming what would be — for me — a really unhealthy work balance. I can only speak for myself, but side projects keep me alive. Working on something beyond the projects I tackle at my full-time (or even freelance) jobs keeps me clear and sane enough to tackle those projects, and doesn’t diminish my dedication to them. I do my best thinking when I have time to be expressive, reflective, and just have fun. So I will keep a portfolio as long as I am able to, because I consider making a nice presentation for my work its own side project, starting with this launch.
To the second argument, I would say that many designers don’t know how to code or can’t hire a developer to code for them for their personal website. And I think that’s fine. Knowing the constraints of the medium in which you’re working is vital. I’m a believer that great design happens inside great constraints. But web development may be outside your wheelhouse and that’s ok. And when you’re in that situation and turn to a resource like Squarespace, you don’t have as much control over the UX of the site — you’re largely leaving it up to someone else.
And even as I launch these sites and continue to learn, development isn’t what I do on a day to day basis, so I’ve still got a long way to go to gain the skills I need to implement exactly what I design.
So while I don’t totally agree that a designer’s site needs perfect UX — because it may not be feasible for the designer to realize their vision in code right now and perfect UX doesn’t exist yet — I wanted to dig in and learn enough about the web to build something of my own and see what I could do. I wanted a cohesive language for all my websites that would feel familiar but still adapt to each site’s needs and purpose. So that’s what I set out to execute.
The skeleton
The basic structure is simple and shared. A full-canvas color block is surrounded by a toolbar and a sheet of paper peeking in from the bottom of the screen. In the center is a quick intro to the site or description of what’s going on.
The rationale here is mostly about keeping things simple, focused, and directed. The user lands on the page, and they immediately see a bold headline. They either choose to read the description or — more likely — don’t. From there the eye will likely go to the peeking card.
Peeking something from beyond the fold is a classic way of indicating the affordance to scroll, so this imaginary user will scroll down to see what’s going on and then they’re in the content list for the front page. In most cases this is a selection of highlights with an indicator for seeing more. On the Phoebe site it’s a card for each of the main components of the project.
Post pages (for individual case-studies, episodes, etc) look similar except the sheet of paper is continuous and slides all the way up to the headline.
The toolbar that overlays each page starts off coplanar to the main color block, elevating on scroll to let the content flow underneath. And it can contain links that — at smaller sizes — collapse into a navigation drawer. But more on that later. First there are a few more details worth pointing out.
Readability in long vertical lists
Design Notes and I AM LIAM both feature long vertical lists — on the Design Notes site, the archive has a list of all episodes, while I AM LIAM has lists of projects inside each category of the portfolio.
When I implemented the original design, it became clear that the cards — which were spaced 8px from each other vertically — were hard to scan and parse as you scrolled by. I tried a few things immediately to fix this.
- I increased the space between cards to 24px. This helped a bit but didn’t solve the underlying issue.
- I made the background darker on I AM LIAM to see if the card contrast was an issue. The main body’s background color was a light gray to avoid clashing with cards that would feature unpredictable content. The I AM LIAM site is a good example of this, since portfolio entries are often centered on outside brands with their own palettes. The light gray was an issue for scanning, but not the main culprit.
- I tried coloring the cards for each project. This was way too much, but kind of fun to play with anyway.
I also went to other sites — specifically blogs — that I knew could face a similar issue, since they also need to make headlines and body text into modules that are easy to scan.
Eventually I realized that blogs don’t suffer this issue as strongly because it isn’t just up to the headline text and the space between posts visually separate them from one another. There’s all this other stuff in in the header that creates distinct visual modules. This stuff could include comment counts, social buttons, categories, and other metadata, which create strong blocks that stand out from the end of the previous post.
Obviously my portfolio site doesn’t have comments, and I don’t mind too much whether anyone wants to post a tweet about a specific page, so the solution I found was to add a small bar component to the card, just under the headline.
The length of each bar is calculated based on the size of the screen and the card, and the height remains constant.
The color of the bar is based on the individual post. So the portfolio entry for 5217 is a bright green to match the design of the app. Project Phoebe is a cool indigo. Etc. This way, even if it weren’t for images, each post could stand out on its own.
Flexible navigation components
As I mentioned before, the four sites involved in this launch all have different purposes. One is a site to introduce and catalog a podcast, one is a portfolio, one is a simple portal, and one is a combination portal and index (more on that at a future date).
This variation means that every site has a unique flow or traversal in mind, which means that navigation should be flexible, contouring to the contents of each site. The underlying structure of navigation includes a toolbar, toolbar links, and a navigation drawer. At smaller screen sizes, any toolbar links will collapse into the drawer.
Briefly, I’ll walk through what this structure looks like on each site in the redesign, and why it looks that way.
Dadapixel is probably the simplest and truest incarnation of the navigation structure I’ve chosen, and its structure is almost identical to Phoebe’s. There are a few links in the toolbar which collapse into a drawer at smaller sizes. That’s all there is to it.
Design Notes is a bit more interesting. On the previous Design Notes site, the main page had a header with several links out to podcast clients or feeds like RSS, iTunes, SoundCloud, Play Music, YouTube, etc. The links here were simply too numerous to include in the toolbar — they would need to collapse almost immediately when the screen got smaller. So I put them in the drawer by default.
But since the items in the drawer aren’t actually deeper parts of the site — they’re all outward-facing links — they aren’t strictly in-site navigation. So I took a liberty with the drawer and made its toggle button a headphones icon rather than the traditional “hamburger.” This way the drawer feels more like an action of its own rather than something that will allow you to navigate.
The drawer is also colored with an accent, since Design Notes has a palette of several colors and a generally more dynamic aesthetic.
The portfolio site (I AM LIAM) has the most interesting permutation of the navigation structure, as it splits nav between the toolbar and the drawer at large sizes, with a segmented drawer taking over at smaller sizes.
This was another case where the original site had several links up top and more links deeper into the site scattered around each page. All the in-site and out-of-site links wouldn’t fit in a toolbar so I prioritized the in-site navigation and left the secondary and out-of-site navigation for a drawer.
At smaller sizes, the links collapse into the drawer and the secondary nav is segmented with a simple horizontal break, thus maintaining the nav hierarchy without complicating the main page.
Room for customization
Another important part of building the base and skeleton for these four sites was ensuring room to customize the design further using color & typography.
Doing this actually wasn’t as hard as it might sound. And since building these sites was a learning experience for me, I learned along the way (and am still learning) how to do this more efficiently with each iteration.
At first I did way too much styling inline on specific components, while most of the heavy lifting (like the top ribbon color, nav drawer color, etc) was handled in site-specific override sheets. The primary design exists in a shared “core” set of stylesheets, so I had the core sheets establishing the style of the page, then an override sheet changing larger components, and then styles in the actual page changing things like text color.
But by the time the sites launched, I had simply established additional text styles in the core sheet so that all sites could share them. For example, h2 text comes in light and dark variants, as does card text.
The I AM LIAM page for this case study intentionally shows off a wide range of the customization options available in the design. The ribbon is a background component that will always fill the above-the-fold screen space so it’s flexible enough to accept background images or just colors. The toolbar has its own separate background just in case I don’t want it to match the ribbon.
Version 1.0 & designing for bugs
Despite all I’ve learned building these sites, I’m positive that a professional developer would probably have a thing or two to say about the code. And that’s exciting because it means I still have a lot more to learn.
But we don’t always have time to learn enough to perfect something before launch, so we have to get creative. And there are certainly instances of creativity in my own code and styling in this initial release.
One example that I was able to fix by release was the nav drawer component. To open and close the nav drawer I’m using some really basic Javascript that just adds or removes “On” classes from the drawer itself and the scrim that appears behind it.
$(document).ready(function(){
//open drawer with hamburger icon
$('.collapsedMenu').click(function(){
$('.nav').addClass('navOn')
$('.scrim').addClass('scrimOn')
});//close drawer by clicking outside
$('.scrim').click(function(){
$('.nav').removeClass('navOn')
$('.scrim').removeClass('scrimOn')
});//close drawer with back arrow
$('.navBack').click(function(){
$('.nav').removeClass('navOn')
$('.scrim').removeClass('scrimOn')
});});
In CSS, I have a couple of effects. To begin with, I’ve animated the movement of the drawer so it feels smooth. I also animate the opacity of the scrim on open and close. Finally, I adjust the visibility of the scrim so it won’t block interaction on the main content area when the drawer is closed. Here’s my old code:
.nav {
position: fixed;
left: 0;
top: 0;
background-color: #4A4A4A;
width: calc(100vw - 56px);
max-width: 324px;
height: calc(100%);
z-index: 3;
transform: translateX(-100%);
transition: transform 0.3s ease-in-out;
}.navOn {
transform: translateX(0);
box-shadow: 8px 0px 24px rgba(0,0,0,0.24);
}.scrim {
width: 100%;
height: 100%;
position: fixed;
top: 0;
left: 0;
background-color: rgba(0, 0, 0, 0.6);
opacity: 0;
z-index: 3;
visibility: hidden;
transition: opacity 0.2s ease-in-out;
}.scrimOn {
opacity: 1;
visibility: visible;
transition: opacity 0.2s ease-in-out;
}
Functionally, it’s a really simple way to get the interaction that I want with the drawer. Practically, however, it didn’t work quite how I wanted. Specifically, the scrim was snapping back to invisible as soon as the drawer-closing interaction was performed, rather than smoothly transitioning.
Because I knew this would be a challenge, had 30-odd pages to get done, and wanted to meet a deadline to get the site launched, I did a small trick with the design to lessen the negative impact of the scrim’s faulty behavior until I could get it fixed.
The scrim serves to darken the body of the site when the drawer is open, so the practical effect of my code is that it doesn’t separate the drawer from the background effectively when the user performs a drawer-closing interaction. To try and ease this impact, I simply made the nav drawer a slightly lighter color than the primary color of the site.
When the drawer is open, you don’t have the original primary color as a reference, so the difference is hard to perceive (or impossible on sites like Design Notes where the drawer is an accent color), but when the drawer is closing the eye does — briefly — recognize the drawer as a distinct element, even without the heavy scrim.
This wasn’t meant to be a permanent solution of course —just a placeholder. After the main pages were finished I would revisit and eliminate the problem altogether. But I thought it was a good illustration of the fact that — given the constraint of time — sometimes creative workarounds are required until you can go back and permanently solve a problem.
After revisiting the issue I found the fix, which was a thrilling and embarrassing one-line change.
transition: opacity 0.2s ease-in-out;…simply needed to be changed to
transition: opacity 0.2s ease-in-out, visibility 0.2s ease-in-out;It was as easy as that.
What’s left?
This is just version 1. Really I’d consider it version 0.1 or 0.01. It’s a decent start, and hopefully publishing these sites will teach me more about how to improve. But there are also plenty of features still missing.
Yet to come are lightboxes, proper galleries, more efficiency with visual assets, and more portfolio entries.
Design & code
Being responsible for both the design and the code on a project, even a relatively simple one, has been and is an enriching experience. I’ve implemented things I didn’t think I could, and experienced manipulating design and code simultaneously, mixing them into something harmonious and enjoyable. And while I’ve done this with Android designs on occasion (even implementing a few of the basic layouts for Helios), it’s different to produce a functional artifact from a design, beyond just working layouts to actual functionality.
I’m hooked.
You can see the sites at liamspradlin.com, designnotes.fm, phoebe.xyz, and dadapixel.com
