Consistency and Dynamics
Part of a good online experience involves serving the desired information a user wants as quickly as possible. That has been the main motivation behind many of Google's services: Fiber, Now (on Tap), and so forth, and their success at it is part of the reason they are such a successful company.
Doing so requires a lot of optimization and prioritization, which I'll get to shortly. But something that is only recently becoming a major focus is consistency. Rather than having to hunt for information by learning various website layouts and designs, it's much more streamlined to have a design that is consistent and predictable (though that doesn't have to mean boring!). While it's not realistic to design a website so everything is in the exact same layout, small things can be adjusted to give a more consistent feel to the site. It also helps to make the site easier to understand (how many times have you seen a scroll bar on an app that grows and shrinks as you're scrolling, and you can't tell where on the page you really are?).
It is with this in mind that I've decided to work towards making the layout of my site a little more consistent. That's pretty easy at the moment because of the template I'm using (which only allows one column; I admittedly have mixed feelings about the clean look vs. unused screen real estate). But, what can be made more consistent is some of the sizing and spacing.
For guidance on how to space things, I turned to Google's Material specs site (where else, for a Material-themed site?). On there, Google recommends keeping things in increments of 8dps (i.e., dips, or density independent pixels; a unit of measurement that is consistent across screen sizes, and is thankfully equivalent to 8px in CSS [sort of]).
Having the spacing (e.g., margins and padding) in increments is easy enough, but making the elements (i.e., cards) a consistent size that is divisible by 8 is a little more tricky due to the need for the size to change as the screen size changes. In addition, squarespace already does a lot to resize things dynamically, which is great but hard to tweak. As a result, I've gone through and updated the padding, margins, etc. of content to make them all consistently in increments of 8px (mostly 16px), but I haven't touched the height of elements much yet. Although I want to make things more consistent heights (e.g., the tweets in the twitter list on my social page), that currently translates poorly to different screen sizes and will need some more work.
But, spacing isn't only about having content displayed consistently. It's also about making the site more touch-friendly for those on mobile devices. In order to help move towards a more touch-friendly layout, I updated the mobile navigation bar to have touch-areas that are 48px tall and more spaced apart.
Now, consistent spacing and sizing are all well and good for consistency and predictability, but there is another benefit to them: dynamics.
(The animations are smoother in reality. Still learning how to record my screen properly.)
As I discussed in my previous website update post, it's helpful to include animations that can help communicate how the elements on the page relate to one another, and which things users can interact with.
Hovering effects were my first foray into using CSS animations for this purpose, but there is so much more that can be done!
The animated image above shows what I currently have for an experimental version of my social page (which, unfortunately at the time I'm writing this, only works well with Chrome on desktop). Animations like the above, along with looking good, help to communicate how the information is layered and grouped. In addition, it shows that the content is flexible and can be altered as the user wishes.
These larger animations also come with a trade off, though. In the case of loading animations, the cost is having to compete with the rest of the content on the page that is loading. As a result of this competition, frame rates are terrible and the animation disrupts the user experience.
One solution to overcome this conflict is to delay the animations so they don't load until the rest of the content has finished loading, which is the current solution I'm using for the experimental page.
Now, remember how important I mentioned speed is with a website? This delay ruins that. On desktop, the delay currently needs to be at least 3s, and mobile would probably need 5s or more. That's a short time in the big scheme of things, but it's higher than the recommended 2s or less (and rapidly shrinking) load times that have been shown to satisfy users.
An alternative solution is to delay loading some of the content until the animation has finished. This is my ultimate goal though, again, it's questionable whether or not I'll be able to do so without developer-level access to my site's code.
It's because of this (and the need to adapt the code to work better across browsers) that I'm testing the animations on a separate page. If I can get some of the prioritizing of loading figured out and can get the animation to load more quickly, I'll invite people to try it out and send me feedback.
So, that's all for now. I will continue to work hard to make my site as enjoyable as possible to use (within my current means). As things come together, I'll keep you all updated in this weekly post!
And again, for those of you interested in my CSS, you can find it consistently updated in this post.