Your friends at Viget present Inspire, a Design & Interaction Blog

Equating Color and Transparency

Color and transparency are typically treated independently. Choose a color and set its opacity (or alpha, if you prefer). Simple enough. But, how exactly are color and opacity related?

For the purpose of this post, lets just consider grayscale. With a little additional effort, this discussion may be extrapolated to all colors.

In Theory

In the RGB and HEX color modes, there are technically 256 possible shades of gray available for digital screens including black and white. However, confined to only adjusting the opacity of black on a white background, 256 shades reduces to 100 as opacity is typically represented as a whole percentage point from 0% to 100%. For reference, a table mapping 100 shades of gray to the equivalent opacity of black on a white background is attached at the end of this post.


Are Hollow Icons Really Harder to Recognize Than Solid Icons? A Research Study

Last summer software designer Aubrey Johnson published a post on Medium with a specific critique of Apple’s brand new mobile operating system, iOS7. Johnson suggested that Apple’s new “hollow” icons, being more visually complex than “solid” icons, create cognitive fatigue for users that will eventually lead them to tire of the interface and stop using it. The timely, bite-sized post was shared and discussed widely, with some designers affirming it as sensible advice and others criticizing it as overblownoversimplified, and lacking valid evidence.

Solid and hollow icons example

An example of solid and hollow icons in the tab bar of an app in Apple’s iOS7. The selected icon, Top Charts, uses a filled-in "solid" style. The unselected icons use an outlined "hollow" style.

As a graduate student in human-computer interaction and a UX intern at Viget, I saw an interesting opportunity to test Johnson's claim with evidence from real users. To find a definitive answer to the question of whether hollow icons require more cognitive effort for users, I created a web app that measures users’ speed and accuracy in selecting icons with different visual styles. By studying the data from more than a thousand test participants, I found that hollow icons are not necessarily less usable than their solid counterparts. However, the results are actually a bit more complicated.


Three Years, Three Words

As I come up on my three year review, I find myself reflecting on my professional career and how far I've come since I graduated from George Mason University with a degree in Graphic Design. Recently, I had the chance to reflect on this topic further when Tom, Joseph, and I went to speak at my alma mater. We answered questions, gave advice on how students can prepare for working 40 hours a week.

During the session we fielded a handful of questions, one of which I asked myself at my own graduation.

"How do you find your path?"


Presenting Design with Empathy

Snow shovel illustration

This past winter brought more snow than usual to North Carolina. As I was working from home one day, I watched my neighbor shoveling his driveway. I noticed that the shovel that he was using looked like it was making the job a lot harder. I was sure I could design a better shovel for him.

I went to work designing an amazing new shovel with the latest technology. It was sure to blow his mind. I walked over to my neighbor, handed him the shovel and said, “I made this shovel. You’re going to be able to shovel your driveway in half the time with half the effort. The design is nothing like you’ve ever seen before. Enjoy!” Standing there with a giant grin on my face, my neighbor looked at the shovel perplexed.

“What are these buttons and knobs? The handle is bent in a funny direction. I don’t understand this,” he said as he handed the shovel back to me. My grin quickly faded.

This story may be far-fetched, but this is exactly how many of us treat our clients when we present a design to them for the first time. In our case the shovel might be a mood board, design comp, wireframe, user-flow, or some other design deliverable. Many, if not most of our clients don’t work in our industry. They probably use web sites, just like my neighbor used other shovels in the past. But that doesn’t mean that even the most beautiful, well-thought-out design will make sense to them. It’s our job as designers to empathetically present our work to clients in a way they’ll understand.


Skewed Hit Boxes with CSS Transforms

One of the neatest things about CSS Transforms is that they change the hit area of an element to whatever transformed value we set. So, if we rotate an element, the hit area for that element doesn’t stay a box in the defined X and Y plane; it changes to the transformed shape.

CSS Transformed Hit Box

See the Pen rhAje by Tommy Marshall (@tommymarshall) on CodePen.

With that in mind, when I was handed a design comp with a skewed design element and links with angled edges within it, I realized for great justice it was achievable by skewing an element and applying overflow: hidden to the container.

The markup for this demo is really simple:

<div class="container">
    <div class="inner">
        <ul>
            <li>
                <a href="#">Something Awesome</a>
            </li>
            <li>
                <a href="#">Something Awesome</a>
            </li>
            <li>
                <a href="#">Something Awesome</a>
            </li>
        </ul>
    </div>
</div>

Based on that markup, we first transform the .container element and skew it 18 degrees on the X-axis, then undo that skew on the .inner container so our links display properly instead of at an angle (Using SASS).

.container {
  background: #555;
  margin-left: 100px;
  padding: 100px 0;
  position: relative;
  width: 400px;

  /* the important stuff */
  overflow: hidden;
  @include transform(skewX(-18deg));
  
  .inner {
    /* revert the transform */
    @include transform(skewX(18deg));
  }
​}

If you looked at the above example in a Codepen you’ll notice the edges of the skewed element are a bit choppy. You can use the translateZ trick to fix that rendering issue, but that blurs the child elements of the container as well. Instead, I found adding a simple box-shadow to the container works totally fine.

.container {
  box-shadow: 0 0 1px #000
  ...
}

Next, to fix the alignment of the nested links, I add a bit of left positioning to each <li> using the :nth-child selector. 

ul {
  list-style: none;
  margin: 0;
  padding: 0;
  width: 100%;
  
  li {
    position: relative;
      
    @for $i from 1 through 3 {
      &:nth-child(#{$i}) {
        left: 18px + ($i * -18);
      }
    }

    a {
      background: #5579c2;
      color: #fff;
      display: block;
      padding: 1em 5em;
      text-decoration: none;
      text-transform: uppercase;
      
      &:hover {
        background: darken(#5579c2, 20%);
      }
    }
  }
}

The bonus of using CSS Transforms and :nth-child is that in browsers without support the fallback looks exactly as you'd expect: an unskewed element without the extra left spacing for each of the links.

You'll notice even with the width: 100% on our links, it doesn't span the full width of the .container. To get around this you can just apply a bit extra to the <ul>, since our .container element is set to overflow: hidden.

ul {
  width: 120%;
}

Final Result

See the Pen Jxcbu by Tommy Marshall (@tommymarshall) on CodePen.

When you hover over the links you’ll see that the hit areas are exactly as we’d expect them to be (not going beyond the bounds of the container) and thanks to CSS Transforms and overflow: hidden.

Found this helpful or have another application of skewing elements change an elements hit area? Let me know below!