Wednesday, 30 March 2016

An Introduction To Semiotics — Signifier And Signified - Vanseo Design

An Introduction To Semiotics — Signifier And Signified - Vanseo Design


An Introduction To Semiotics — Signifier And Signified

Posted: 29 Mar 2016 05:30 AM PDT

The famous pipe. How people reproached me for it! And yet, could you stuff my pipe? No, it’s just a representation, is it not? So if I had written on my picture ‘This is a pipe’, I’d have been lying!
— René Magritte


The Treachery of Images by René Magritte

The image above is René Magritte's The Treachery of Images, sometimes translated as The Treason of Images and if you read the quote above it, you can probably tell Magritte is talking about this painting.

It looks a lot like a pipe to me, but the words underneath say "This is not a pipe" and Magritte is 100% correct. What you're looking at is not a pipe. It's a digital image of a photograph of a painting of a pipe. What it isn't, is a pipe, and if you aren't convinced see if you can fill it with tobacco, light it, and then smoke it. I'll wish you good luck as you try.

Radioactive Icon

My point in sharing this with you is to say that signs aren't the things they represent. Some signs look like the things they represent, such as an image of a photograph of a painting of a pipe or the print icon in most apps that looks like a printer. Some signs look nothing like what they represent, such as the symbol for radioactive shown here. If you didn't know what it was a symbol for, nothing in the graphic would help you figure it out.

All this talk about signs not being the same as what they represent is what semiotics is all about. Semiotics is a good topic for designers because it allows us to understand the relationships between signs and what they communicate to the people who interpret them.

If you think about it, just about everything you do when designing a website is about creating a sign of some kind, whether it's an icon or text label in a navigation bar or a background image that provides context for an article. The words on this page are all signs as well.

I spent the last two weeks talking about icons, both in general and the hamburger icon specifically. I want to spend the next few weeks discussing semiotics. It's a much larger topic than what I'll be able to cover here, but I'll walk you through the basic concepts and try to help you decide what type of icon to use depending on the specifics of what you want to communicate.

What is Semiotics?

Semiotics is the study of signs. Not roadsigns, but something more general. It's the study of meaning-making and meaningful communication.

Semiotics is related to linguistics, the study of language, but it limits itself to the signs and symbols part of communication. That's not to say it's all visual. Words and numbers are signs along with photographs, icons, and roadsigns. Anything that's capable of representing something else is a sign. Anything that creates meaning is a sign.

The reason for studying semiotics is that is gives us a useful set of tools for identifying and creating the patterns that lead to meaning in communication.

Ferdinand de Saussure and Charles Sanders Peirce are the founders of semiotics, though each worked independently of the other. Ferdinand de Saussure (1857–1913) was a Swiss linguist, who was also the father of modern linguistics. Charles Sanders Peirce (1839–1914) was an American philosopher and the founder of pragmatism. They're names will come up a few times throughout this series.

Signifier and Signified

Saussure said the sign is the basic unit of meaning and he thought signs were made up of two parts.

  1. Signifier — The form of a sign. The form might be a sound, a word, a photograph, a facial expression or Magritte's painting of pipe that's not a pipe.
  2. Signified — The concept or object that's represented. The concept or object might be an actual pipe, the command to stop, or a warning of radioactivity.

Remember that words, as well is pictures, are signs The word "pipe" is a sign for an actual pipe as much as Magritte's painting is a sign for an actual pipe. The signified is the same in both cases, that of a real pipe than can be filled with tobacco, which you can light and smoke.

What's different in the two signs is the signifier. In Magritte's case the signifier is a painting and with the word "pipe" the signifier is the word itself. Both are representations of an actual pipe.

The Interpretant

Peirce added a third part to signs, the interpreter. He saw signs consisting of:

  1. The representamen (signifier) — The sign's form.
  2. An Interpretant — What the audience makes of the sign.
  3. An Object (signified) — What the sign refers to.

One thing to make clear is the interpretant is not the same as an interpreter. It's not the audience, but what the audience makes of the sign. For example if someone looked at Magritte's painting and saw it as a piece of wood rather than a pipe, it's that sense that it represents a piece of wood that's the interpretant and not the person making the interpretation. That's probably not very intuitive so let me add another example.

Imagine a street light at an intersection turning red and several cars stopping. According to Peirce's model the red light of the traffic light is the representamen (signifier), the act of cars stopping is the object (signified), and the idea that a red light is a command for vehicles to stop is the interpretant. If it's still not clear, don't worry. The basic concept should become clearer as we continue through the series.

Peirce said "We only think in signs" and added that anything is a sign if someone interprets it as meaning something other than itself. He also added that signs can be defined as belonging to one of three categories, icon, index, or symbol, which is where I want to pick this up next week.

Closing Thoughts

I realize I didn't cover a lot in this post, but I want to let the basic concepts sink in before moving on. In some ways they probably seem obvious, but if you were looking at Magritte's painting and someone asked you what it was, you'd likely respond that it's a pipe, even though it's a painting of a pipe or an image of a painting of a…well, you get the idea.

I want you to take away the short definition of semiotics, that it's the study of signs and that a sign is anything that can represent something else and is interpreted to have meaning.

Also take away that signs have three parts, a signifier or representamen (Magritte's painting), which is the actual form of the sign, a signified or object (an actual pipe), which is what the sign represents, and an interpretant (the meaning that's interpreted), which is what an interpreter makes of the sign.

Next week, I'll continue by talking about three different categories of signs, icons, indexes, and symbols. I'll leave today with you another quote about signs that expresses a different meaning about what they can do.

A sign is anything that can be used to tell a lie
— Umberto Eco

Download a free sample from my book Design Fundamentals.

Join me as I share my creative process and journey as a writer.

This posting includes an audio/video/photo media file: Download Now

Wednesday, 23 March 2016

The Hamburger Icon Debate - Vanseo Design

The Hamburger Icon Debate - Vanseo Design


The Hamburger Icon Debate

Posted: 22 Mar 2016 05:30 AM PDT

Type "hamburger icon" into Google and once you scroll past the images of the icons, you'll notice a few articles about the history of the icon and a lot of articles debating if it's the solution for all our small screen navigation problems or if the hamburger icon will destroy humanity. You know the usual overreaction to every topic that involves designing websites.

Vintage Hamburger Sign

Last week I began a series about icons and signs and I mentioned I would talk about the hamburger icon today. I'll talk about what the controversy with the icon is all about and I'll point you to some A/B tests before offering some thoughts about whether or not it's ok to use hamburger icons on wider screens.

Does everyone know what the hamburger icon is and does when they see one? No. Do more people know today than say two years ago? Yes. Will more people know what it means two years from now? Most likely, yes.

Two Different Arguments About Hamburger Icons

There are really two different debates around the hamburger icon ( ☰ ) or navicon as it's sometimes called. One of them has nothing to do with the icon itself.

  1. Should global navigation be hidden by default?
  2. Assuming some navigation will be hidden behind an icon or label, is the hamburger icon a good choice for the icon?

I suppose you can also include a third debate about whether or not to hide navigation by default on desktop sized screens assuming you're ok hiding them on mobile screens.

It's easy to find articles telling you to never use the hamburger icon or dire things will happen. Most of these articles discuss hiding navigation as well as the hamburger icon as the icon to use, however the latter debate is only there to prove their side in the first debate.

The controversy tends to be whether or not to hide global navigation and not how you choose to hide it. I get the impression the people arguing against hiding navigation don't care how it's hidden. I suspect they'd be equally against hiding navigation behind the words "click me for navigation."

A lack of recognition for the hamburger icon is cited as a reason not to use it to hide navigation, but again I think the people who argue this would argue against using any icon for the purpose of hiding navigation.

The two debates are tied together in the controversy, but I hope you can see they are in fact two separate issues and one of the issues isn't about the icon itself, but rather what it's used for.

Do People Recognize the Icon on Mobile Devices?

While researching hamburger icons for this article, I came across a series of tests James Foster ran on mobile devices in 2014. He compared the hamburger icon, the icon with the word menu as a label, and a border around the icon and measured how often each was clicked. I think James did a good job with the tests.

What many people take from these and similar tests is that the navicon combined with a menu label typically outperforms the navicon by itself. The same people often suggest this means you shouldn't use the hamburger icon.

What I take away, particularly from James' tests is that adding a border around something clickable makes it appear more clickable and so it gets clicked more.

The first test James ran suggested that adding the menu label to the icon increased clicks by 7.2%, which is pretty good until you notice that placing a border around the navicon (without the label) resulted in a 22.4% increase in clicks.

James later ran other versions of the test and I'd encourage you to check them all out. You can scan the articles for the results if you don't have time to read through them all.

My take away overall was that people did understand the word menu to lead to a menu more than they understood the icon alone, but of more importance was making the button look clickable. Another takeaway for me is that as time passes, more people recognize the icon and that will continue to increase as it gets used and seen more.

By the way James' conclusion to his own tests was that it's ok to use the icon.

I'm sure if everyone runs A/B tests on their sites now, we'll find the that more people understand what to do when they see the word menu than when they see the hamburger icon alone, but if we continue to test the icon, every year more people will know what the icon by itself means.. I'm also sure if we make buttons look clickable they'll get clicked more.

Is it Ok to Use the Hamburger Icon on the Desktop?

The last few years people have started using the hamburger icon on wider screens as a way to hide user interface, specifically global navigation. This is probably done in an effort to make a site appear simpler with a minimal aesthetic.

I wrote an article about this two and half years ago when I asked how important is it to have always visible navigation? At the time I was thinking about a site I wanted to design for myself and whether or not I needed to have the global navigation visible at all times or if it would be ok to hide it behind some kind of icon or icon and label combination.

I thought then as well as now that it's ok to do this provided you understand the potential downside.

  1. It's an extra click to get anywhere on the site.
  2. A mouse click is more effort than a tap.
  3. People might not be familiar with the icon.

I said then I wasn't too concerned about the first two items as I felt the cleaner looking page was worth the extra click. The familiarity or rather the lack of familiarity with the icon is the major potential problem.

Granted this is just my opinion, but I expect people will understand the hamburger icon more over time. As long as designers are consistent in using it and consistent in what it represents and does, I'm pretty sure people will figure it out.

Whether or not you should hide navigation behind any icon is another matter. I suspect it's less of a big deal than many make it out to be, though I think it's fair to say that at the current time most people don't realize there's a menu behind the navicon. However, I don't see the pattern going away on small screens given the lack of space and I expect people will become more familiar with hidden navigation over time.

If you disagree, consider that the common sense advice for web designers used to be that people didn't know to scroll. I think most people figured out how to scroll and I think most people will figure out that if you don't see navigation, it's probably behind a visible button.

Closing Thoughts

At the start of this post I mentioned the results I found when searching Google for "hamburger icon." One thing I found interesting is how the results change when varying the date range for the search.

When I searched anytime, the results suggest the icon is bad. When I limited the search to the past year there are still results suggesting the hamburger icon is bad, but also some saying it's ok and asking if it's time to start using the icon on the desktop. When I limited the search to the last month, I mostly see results for how to create hamburger icons.

Seems like an indication that as time has passed, the hamburger icon is becoming more accepted. I think we should give it more time before deciding it should never be used. I also suggest it's too soon to decide that placing global navigation behind some kind of menu indicator is inherently a bad idea.

Next week I want to pick up the topic of semiotics to help us decide what icons are communicating so we can better decide how they should be designed.

Download a free sample from my book Design Fundamentals.

Join me as I share my creative process and journey as a writer.

This posting includes an audio/video/photo media file: Download Now

Wednesday, 16 March 2016

Why You Should Start Learning More About Icons - Vanseo Design

Why You Should Start Learning More About Icons - Vanseo Design


Why You Should Start Learning More About Icons

Posted: 15 Mar 2016 05:30 AM PDT

One of the challenges in designing websites for smartphones is the small screen size. It can be difficult to fit even basic things like navigation labels on smaller screens and when you do fit them all in there's often a lack of space between links leading you to click one you didn't intend.

icons

In my own personal experience, I find the apps I use are often easier to navigate than the sites I visit. I think one of the reasons is that the apps tend to use more icons, where the websites took a desktop first approach and crammed a few too many links into a small space or hid them behind a navicon.

It's led me to think about icons in general and hamburger icons in particular. I haven't used a lot of icons in my work over the years, but as I'm thinking about it more, I wanted to learn a little about how and what icons communicate. A little research led me to the topic of semiotics, the study of signs, symbols, and their use and interpretation.

I want to talk about signs and symbols over the next few weeks, starting today with some general talk about icons. Next week I'll focus specifically on the hamburger icon and in the weeks that follow I'll dig a little into the world of signs and semiotics.

Icons are Everywhere

If you haven't already noticed, icons are everywhere. They're in the apps we use and they're on the websites we visit. I currently have two applications (Ulysses and Firefox) visible on my laptop screen. Also visible is the Mac menu bar. Here are the icons I see.

  • The Apple logo in the upper left that serves to reveal system wide menu options.
  • 14 icons in the menu bar (most of which I specifically added) to open various apps or operating system functionality. One of these icons opens a drawer to reveal additional icons that I've tucked away.
  • 3 icons each (for a total of 6) at the top left of both apps to close, minimize, and resize the windows.
  • 7 icons in the navigation bar in Ulysses to access different functions of the apps.
  • 19 icons, mostly for extensions, in Firefox; the last being a hamburger icon to reveal even more icons that I can add.
  • 25 favicons to the left of most of the tabs I have open in Firefox.

I haven't even mentioned what’s present on the web page displayed in Firefox, but given it's an article about icons, I didn't think it fair to include. Even without the article itself, I count 72 icons, which is hopefully enough to make my point that they are everywhere.

Why Icons?

It begs the question why so many icons and I think the answer is relatively simple. It's because they generally take up less space to communicate something than words might need to communicate the same thing. They also add visual interest and can get a message across quicker than words.

I'm sure you've heard the expression a picture is worth 1,000 words. Looking at an image takes less time than reading 1,000 words. Quicker doesn't automatically mean better, of course. It just means quicker.

Still an icon communicates quicker and if we agree on the definition of that icon and what it means, then it will also communicate more effectively.

Remove the word stop from a stop sign and I think we'd still know it was a stop sign because of our familiarity with their shape and color. You'd see it out of the corner of your eye and your foot would hit the brakes in a Pavlovian response as you look around to make sure no cops saw you stopping late.

Or would we all recognize it?

It depends on where you live and what stop sign is used in your country. There are actually two standard designs for stop signs and both came about from the 1968 Vienna Convention on Road Sigs and Signals.

Think about that for a moment. Stops signs are pretty close to universal, but that wasn't always the case. Look at some of the old stop signs on the Wikipedia page I linked to in the last paragraph. The old stop signs have the shapes of octagons, circles, triangles, squares, and arrows.

In other words we now have mostly universal stop signs, because we agreed in advance on what stop signs should look like. It's that agreement, that shared understanding of the meaning of the sign, that led to the standard, which is what leads to an instantly recognizable symbol.

Now imagine you encounter a stop sign, but instead of the word stop it includes the word go. I'm willing to bet you'd automatically stop when the sign came into your vision, despite the word go instead of the word stop.

That's why icons. Because once we agree on its meaning, an icon communicates quicker and more effectively than the words we would otherwise use. That agreement is a pretty big if, and we'll talk more about it later in this series.

That doesn't mean I think we should give up words in favor of icons. Some things are still better communicated verbally rather than visually. However, I expect the use of icons will more likely increase than decrease in the coming years.

Again, that's not to say everything will or should be replaced by an icon. Too many reduces the effectiveness of all of them. However, I suspect they’ll grow in use and it makes sense to learn a few things about them.

Closing Thoughts

I hope it's clear that mobile devices are now the primary computing device most people use. Smaller screens lead to more icons given the lack of screen real estate.

That doesn't automatically mean icons have to be carried through to wider laptop and desktop screens, but if more people use smaller screens, it stands to reason they're going to be more familiar with the conventions of the small screen than the bigger one, which suggests we should be more familiar with them too.

Over the next few weeks I want to take a look at icons and more generally signs as icons are really one type of sign. I want to walk through the basics of semiotics and how semiotics can help us communicate more effectively.

However, first I want spend next week talking about an icon that some designers are trying to push toward a standard with a shared and universal meaning, while others curse its use as the greatest evil facing the world today. Next week I want to talk about the hamburger icon.

Download a free sample from my book Design Fundamentals.

Join me as I share my creative process and journey as a writer.

This posting includes an audio/video/photo media file: Download Now

Wednesday, 2 March 2016

Sass: When To Use @mixin And When To Use @extend - Vanseo Design

Sass: When To Use @mixin And When To Use @extend - Vanseo Design


Sass: When To Use @mixin And When To Use @extend

Posted: 01 Mar 2016 05:30 AM PST

Mixins are ways to reuse styles across your project and their ability to take arguments makes them very powerful and flexible. The @extend directive allows you to reuse styles by letting one selector inherit those of another. In some respects they both do the same thing so which one should you use?

Wood Mixing Bowl

I'll answer the question toward the end of this post. First there are a few more things I want to talk about in regards to the @mixin directive.

I want to talk about how you can pass blocks of CSS content to a mixin instead of passing arguments. I also want to talk about the scope of the content blocks that are passed. Then I'll get back to the question. I'll compare the @extend and @mixin directives to help you decide when to use which.

Passing Content Blocks to a Mixin

Last week I showed you how you can pass arguments to a mixin. You can also pass a block of styles directly. Inside the mixin you add an @content; statement, which will be replaced by the content block you pass to the mixin.

1  2  3  4  5  6  7  8  9  10  11  12  13  
@mixin button {     font-size: 1em;     padding: 0.5em 1.0em;     text-decoration: none;     color: #fff;     @content;    }    .button-green {     @include button {       background: green     }  }

This is similar to the mixin I used last week and it contains some code to style a button. The difference between this code and the mixin from last week is the last line here includes the @content statement.

The mixin is then called inside the .button-green selector. The @include passes a block of content that contains a single line of CSS to style the background color as green. This content will replace the @content statement inside the mixin.

The Sass compiles to:

1  2  3  4  5  6  7  
.button-green {      font-size: 1em;      padding: 0.5em 1.0em;      text-decoration: none;      color: #fff;      background: green;    }

Another way you can set this up is to have included only the @content directive inside the mixin and passed everything else, including the selector through a root level @include.

1  2  3  4  5  6  7  8  9  10  11  12  13  
@mixin button {      @content;    }    @include button {      .background-green {        font-size: 1em;        padding: 0.5em 1.0em;        text-decoration: none;        color: #fff;        background: green;      }  };

The sass compiles to the same code as the previous example.

You can also mix and match and have some styles in the mixin and some passed through the @include as I did in the first example. One thing to keep in mind is the styles need a selector. For example the following doesn't work.

1  2  3  4  5  6  7  8  9  10  11  
@mixin button {     font-size: 1em;     padding: 0.5em 1.0em;     text-decoration: none;     color: #fff;     @content;    }    @include button {     background: green;    };

Trying to compile this code results in an error, because there isn't a selector for the styles. I realize I mentioned this last week, but it's easy to forget the selector and I hope another reminder helps you remember.

You might wonder when you would use @content as opposed to passing an argument value. Christian Reuter offers a few use cases.

  • In nested (inline) media queries
  • In keyframes for animation
  • For context specificity
  • Combined with @at-root for writing BEM syntax

I'll let you read Christian's article for the details.

Variable Scope and Content Blocks

When a block of content is passed to a mixin, the scope of that block is where the content is defined and not inside the mixin. That means that variables defined in the mixin can't be used within the passed content block.

1  2  3  4  5  6  7  8  9  10  11  
$color: green;    @mixin button($color: #fff) {     color: $color;     @content;     border: 1px solid $color;    }    .button-green {     @include button {background: $color;}    }

Here I defined a variable $color globally as well as inside the mixin using a default argument. The two variables have different color values assigned.

Inside the mixin, $color will make use of the local default argument (#fff). When the content block is passed from .button-green, the $color value used will be the one defined globally (green).

The Sass compiles to the following CSS.

1  2  3  4  5  
.button-green {     color: #fff;     background: green;     border: 1px solid #fff;    }

The @content directive is replaced with the passed content block that uses the global variable (green), while the color and border color use the local value defined in the default argument (#fff).

Should You Use @mixin or @extend

Both @extend and @mixin help modularize your code and make it easier to reuse styles across your stylesheet.

One of the questions you might have been asking while reading the last few posts in this series is when should you use the @extend directive and when you should use the @mixin directive?

We can start to answer the question by looking at how some code compiles.

1  2  3  4  5  6  7  8  9  10  11  
.button {      background: green;    }    .button-1 {      @extend .button;    }    .button-2 {      @extend .button;    }

Using @extend produces DRY CSS.

1  2  3  
.button, .button-1, .button-2 {      background: green;    }

Notice that the styles are not repeated, which makes the code DRY. With @mixin the resulting code isn't as DRY.

1  2  3  4  5  6  7  8  9  10  11  
@mixin button {      background-color: green;    }    .button-1 {      @include button;    }     .button-2 {      @include button;    }

The Sass using the @mixin compiles to:

1  2  3  4  5  6  7  8  9  10  11  
.button {      background-color: green;    }    .button-1 {      background-color: green;    }    .button-2 {      background-color: green;    }

You can see the styles are repeated here inside each of the different selectors, meaning the compiled CSS doesn't adhere to DRY principles.

That might suggest you should always use @extend, but @extend has cons as well. Using @extend creates relationships between selectors and couples them together.

The extended and extending selectors might also be located in different parts of your stylesheet making them more difficult to maintain or possibly lead to source order and specificity issues.

The @extend directive isn't flexible. You can't pass arguments to it so what's there is there. There are also limitations on using @extend inside @media directives and you can't extend a selector across different media directives using @extend.

The main issue is the coupled relationships. When you're dealing with styles for related components, say a set of buttons, then it makes sense to share styles using the @extend directive. If the styles to be repeated won't be limited to related components you probably want to use a mixin instead.

The main advantage to using mixins is the power and flexibility they have because they can accept arguments. Naturally if you want to pass arguments, you'll have to choose @mixin over @extend.

If you don't have any arguments to pass you might want to take advantage of the DRYer result of using @extend. However, you should note that the resulting weight saving using gzip on your files probably makes the savings in file weight from having DRY code close to irrelevant.

Repetition in your compiled code isn't necessarily a bad thing if the file weight savings are minimal. It's bad when it's in your source, because the repeated code is harder to maintain. Using @mixin leads to DRY source code with less DRY compiled code. However, the compiled code isn't going to be bloated especially when gzip's algorithm works well with repetition.

The @mixin directive is ultimately more powerful and flexible and combined with gzip doesn't lose out on the main benefit of @extend.

I'll let Harry Roberts from CSS Wizardy have the last word on when to use each.

  • Use @extend when the rulesets that you are trying to DRY out are inherently and thematically related. Do not force relationships that do not exist: to do so will create unusual groupings in your project, as well as negatively impacting the source order of your code.
  • Use a mixin to either inject dynamic values into repeated constructs, or as a Sassy copy/paste which allows you to repeat the same group of declarations throughout your project whilst keeping a Single Source of Truth.

Or as Harry succinctly closes

Use @extend for same-for-a-reason; Use @mixin for same-just-because.

Update: Last week Harry posted again on this topic suggesting you should always choose @mixin over @extend because mixins better for performance.

Closing Thoughts

In addition to passing arguments to a mixin, you can also pass it blocks of content directly. You probably won't do this often, but there are several use cases where it makes sense.

Most of the time @mixin will make more sense than @extend, but both have their place. Use @extend when the selectors in question and the rulesets they'll share are related in some way. Use @mixin for everything else.

I hope you enjoyed this series on Sass. I'll have some more to say about Sass later in the year when I talk about data types and functions and control directives. Until then it's time to leave Sass for a bit and talk about other things.

Download a free sample from my book Design Fundamentals.

Join me as I share my creative process and journey as a writer.

This posting includes an audio/video/photo media file: Download Now