Use your power to make change a reality.

In 1910, psychologist Max Wertheimer had an insight when he observed a series of lights flashing on and off at a railroad crossing. It was similar to how the lights encircling a movie theater marquee flash on and off.

To the observer, it appears as if a single light moves around the marquee, traveling from bulb to bulb, when in reality it’s a series of bulbs turning on and off and the lights don’t move it all.

This observation led to a set of descriptive principles about how we visually perceive objects. These principles sit at the heart of nearly everything we do graphically as designers.

This is the start of a series of posts about design principles. It begins with these principles of gestalt, because many of the design principles we follow arise out of gestalt theory. In this post, I’ll walk you through a little bit of theory and offer some basic definitions of gestalt principles.

Future posts in this series will consider aspects of design like space, balance and visual hierarchy. In upcoming posts, I’ll point out which gestalt principles influence the aspects of design being discussed, and I’ll offer more practical uses and examples of how the gestalt principles are used in Web design.

The Key Ideas Behind Gestalt Theory

“The whole is other than the sum of the parts.”
— Kurt Koffka

The quote above is gestalt in a nutshell. When human beings see a group of objects, we perceive their entirety before we see the individual objects. We see the whole as more than the sum of the parts, and even when the parts are entirely separate entities, we’ll look to group them as some whole.

There are several key ideas behind gestalt:

• Emergence (the whole is identified before the parts)
  Emergence is the process of forming complex patterns from simple rules. When attempting to identify an object, we first seek to identify its outline. We then match this outline pattern against shapes and objects we already know to find a match. Only after the whole emerges through this outline pattern matching, do we start to identify the parts that make up the whole.
  
  When designing, keep in mind that people will identify elements first by their general form. A simple well defined object will communicate more quickly than a detailed object with a hard to recognize contour.
• Reification (our mind fills in the gaps)
  Reification is an aspect of perception in which the object as perceived contains more spatial information than what is actually present. As we attempt to match what we see to the familiar patterns we have stored in memory, there isn’t always an exact match. Instead we find a near match and then fill in the gaps of what we think we should see.
  
  Reification suggests that we don’t need to present the complete outline in order of viewers to see it. We can leave out parts of the outline as long as we provide enough of it to allow for a close enough pattern match. You can see examples of this a little further down under the principle of closure.
• Multi-stability (the mind seeks to avoid uncertainty)
  Multi-stability is the tendency of ambiguous perceptual experiences to move unstably back and forth between alternative interpretations. Some objects can be perceived in more than one way. An example from below in the section of figure/ground is one you’ve likely seen before. The image can be seen as either two faces in profile or as a vase.
  
  You can’t see both at once. Instead you bounce back and forth quickly between the two stable alternatives. One will tend to be your dominant perception and the longer you go without begin able to see the other, the harder it will be to see that other perception.
  
  From a design perspective if you want to change someone’s perception, don’t try to change it all at once. Find a way to get them to see an alternative. Then work to strengthen that alternative view, while weakening the original.
• Invariance (we’re good at recognizing similarities and differences)
  Invariance is a property of perception in which simple objects are recognized independent of their rotation, translation and scale. Since we often encounter objects from different perspectives, we’ve developed an ability to recognize them despite their different appearance.
  
  Imagine if you could only recognize someone you knew if they stood directly in front of you and faced you, but you couldn’t recognize them once they turned in profile. Despite the different visual perspective we can still recognize people.

You can see these ideas in play in the principles below. The main idea is that gestalt principles are about perception and what is visually communicated by objects. The principles speak to the core of the visual language within which we work.

Gestalt Principles

Most of the principles are relatively easy to understand. There’s a common theme running through many of them.

“All else being equal, elements that are related by X tend to be grouped perceptually into higher-order units.”
— Stephen Palmer

Many of the principles below will follow this pattern. The principles either define X or the higher order that’s perceived.

Law of Prägnanz (Good Figure, Law of Simplicity)

“People will perceive and interpret ambiguous or complex images as the simplest form(s) possible.”

This is the fundamental principle of gestalt. We prefer things that are simple, clear and ordered. Instinctually these things are safer. They take less time for us to process and present less dangerous surprises.

Law of Prägnanz (Good Figure, Law of Simplicity).

When confronted with complex shapes, we tend to reorganize them into simpler components or into a simpler whole. You’re more likely to see the left image above composed of the simple circle, square and triangle like you see on the right than as the the complex and ambiguous shape the whole forms.

In this case, seeing three distinct objects is simpler than seeing one complex object. In other cases, it’s simpler to see a single object, which brings us to…

Closure

“When seeing a complex arrangement of elements, we tend to look for a single, recognizable pattern.”

As with Prägnanz, closure seeks simplicity. Closure is the opposite of what we saw in the Prägnanz image above where three objects were simpler than one. With closure, we instead combine parts to form a simpler whole. Our eye fills in the missing information to form the complete figure.

Closure.

In the left image above, you should see a white triangle even though the image is actually comprised of three black Pac-Man-like shapes. On the right image, you see a panda even though the figure is several random shapes. Seeing the triangle and panda is simpler than trying to make sense of the individual parts.

Closure can be thought of as the glue holding elements together. It’s about the human tendency to seek and find patterns.

The key to closure is providing enough information so the eye can fill in the rest. If too much is missing, the elements will be seen as separate parts instead of a whole. If too much information is provided, there’s no need for closure to occur.

Symmetry and Order

“People tend to perceive objects as symmetrical shapes that form around their center.”

Symmetry gives us a feeling of solidity and order, which we tend to seek. It’s our nature to impose order on chaos. This principle leads us to want balance in composition, though our compositions don’t need to be perfectly symmetrical to be in balance.

Symmetry and Order.

In the image above, you should see three pairs of opening and closing brackets. The principle of proximity, which we’ll get to later in this post, might suggest we should see something else. That suggests symmetry takes precedence over proximity.

Since our eyes will quickly find symmetry and order, these principles can be used to effectively communicate information quickly.

Figure/Ground

“Elements are perceived as either figure (the element in focus) or ground (the background on which the figure rests).”

Figure/ground refers to the relationship between positive elements and negative space. The idea is that the eye will separate whole figures from their background in order to understand what’s being seen. It’s one of the first things people will do when looking at any composition.

Figure and Ground.

The figure/ground relationship can be either stable or unstable depending on how easy it is to determine which is which. The classic example of where the relationship is unstable is the left image above. You either see a vase or two faces depending on whether you see the black color as figure and the white as ground, or vice versa. That you can easily bounce back and forth between the two perceptions demonstrates the unstable relationship.

The more stable the relationship, the better we can lead our audience to focus on what we want them to see. Two related principles can help us:

• Area
  The smaller of two overlapping objects is seen as figure. The larger is seen as ground. You can see this in the right image above. The smaller shape is the figure regardless of color.
• Convexity
  Convex rather than concave patterns tend to be perceived as figures.

Uniform Connectedness

“Elements that are visually connected are perceived as more related than elements with no connection.”

In the image below, lines connect two pairs of elements. This connection leads us to perceive that the connected elements are related to each other in some way.

Uniform Connectedness.

Of all the principles suggesting objects are related, uniform connectedness is the strongest. In the image above, even though we see two squares and two circles, we see the square–circle pairs as more strongly related because they are visually connected.

Notice that the lines don’t need to touch the elements for the connection to be perceived.

Common Regions

“Elements are perceived as part of a group if they are located within the same closed region.”

Another way to show a connection between elements is to enclose them in some way. Everything inside the enclosure is seen as related. Everything outside the encloser is seen as separate. The circles in the image below are all the same, yet we see two distinct groups, with the circles in each enclosure related in some way.

Common Regions.

The typical way to show a common region is to draw a box around the related elements like I’ve done above. Placing the elements on a different background color than their immediate surroundings will also work.

Proximity

“Objects that are closer together are perceived as more related than objects that are further apart.”

Proximity is similar to common regions but uses space as the enclosure. When elements are positioned close to one another, they are seen as part of a group rather than as individual elements. This is especially true when the elements in the group are closer to each other than they are to any elements outside the group.

Proximity.

The objects don’t need to be similar in any other way beyond being grouped near each other in space in order to be seen as having a proximity relationship.

Continuation

“Elements arranged on a line or curve are perceived as more related than elements not on the line or curve.”

It’s instinct to follow a river, a path or a fence line. Once you look or move in a particular direction, you continue to look or move in that direction until you see something significant or you determine there’s nothing significant to see.

Continuation.

Another interpretation of this principle is that we’ll continue our perception of shapes beyond their ending points. In the image above, we see a line and curve crossing instead of four distinct line and curve segments that meet at a single point.

Common Fate (Synchrony)

“Elements that move in the same direction are perceived as more related than elements that are stationary or that move in different directions.”

Regardless of how far apart the elements are placed or how dissimilar they appear, if they are seen as moving or changing together, they’ll be perceived as being related.

The elements don’t need to be moving for the principle of common fate to be present. It’s more that they are seen as having a common destination. For example, if four people are clustered together, but two are observed heading toward the right, they will be seen as having a common fate. Even if two are only looking in the same direction, they’ll be perceived as having a common fate.

Common Fate (Synchrony).

In the image above, the arrows are enough to indicate the elements share a common fate. While movement or change isn’t necessary, both are still a stronger indication of common fate than things like arrows or looking in the same direction which only imply movement.

Parallelism

“Elements that are parallel to each other are seen as more related than elements not parallel to each other.”

This principle is similar to the common fate principle above. Lines are often interpreted as pointing or moving in some direction. Parallel lines are seen as either pointing or moving in the same direction and are thus related.

Parallelism.

It should be noted that for parallelism to be perceived, the lines can also be curves or shapes, though with the latter the shapes should be somewhat line-like in order for them to appear parallel.

Similarity

“Elements that share similar characteristics are perceived as more related than elements that don’t share those characteristics.”

Any number of characteristics can be similar: color, shape, size, texture, etc. When a viewer sees these similar characteristics, they perceive the elements as being related due to the shared characteristics.

In the image below, red circles are seen as related to the other red circles and black circles to black circles due to the similarity in color. Red and black circles are seen as dissimilar to each other even though they’re all circles.

Similarity.

An obvious place to find similarity online is in the color of links. Typically, links within content will be styled the same way, often blue and underlined. This lets the viewer know that the different pieces of text are related. Once one is discovered to be a link, it communicates the others are also links.

Focal Points

“Elements with a point of interest, emphasis or difference will capture and hold the viewer’s attention.”

This principle suggests that our attention will be drawn toward contrast, toward the element that is unlike the others in some way. In the image below, your eye should be drawn to the square. It’s a different shape and color from the other elements. I’ve also given it a drop shadow to further emphasize it.

Focal Points.

The principle of focal points likely arises out of our need to quickly identify the unknown to alert us to potential danger.

The principles of similarity and focal points are connected, and focal points can’t be seen without the presence of similarity among other elements.

Past Experiences

“Elements tend to be perceived according to an observer’s past experience.”

Past experience is perhaps the weakest gestalt principle. In conjunction with any of the other principles, the other principle will dominate over the past experience principle.

Past experience is unique to the individual, so it’s difficult to make assumptions about how it will be perceived. However, there are common experiences we all share. For example, a lot of color meaning arises out of past experience.

Past Experiences.

Having seen traffic lights throughout our lives, we expect red to mean stop and green to mean go. You probably see the image above as a traffic light on its side, because of the three common colors. That’s past experience at work.

Many of our common experiences also tend to be cultural. Color again provides examples. In some countries, white is seen as pure and innocent and black as evil and death. In other countries, these interpretations are reversed. Conventions can arise when the experience is commonly shared, though again it’s important to remember that we don’t all share the same experiences.

Summary

Gestalt principles are important to understand. They sit at the foundation of everything we do visually as designers. They describe how everyone visually perceives objects.

The principles above should be relatively easy to understand. For most of them, the definition and the image are probably all you needed to understand the principle. At the same time, understanding the basic ideas of these principles isn’t the same as understanding how they influence design.

In the coming weeks we’ll look more at how gestalt influences design. We’ll see how symmetry helps us balance a composition and how combining focal points and similarity allows us to create a visual hierarchy in a design.

Before we get to either, though, we’ll take a deeper look at the figure/ground relationship and consider the space in which we place elements. That’s where I’ll pick up the series.

Additional Resources

• Visual Design Principles
• Laws of Organization in Perceptual Forms (Max Wertheimer)
• Gestalt principles
• Gestalt Principles & Web Design
• The Gestalt Principles
• Gestalt principles of form perception
• Gestalt Principles Applied in Design
• Gestalt Theory of Visual Perception
• 6 Principles of Gestalt Psychology That Can Improve Your Photography
• Gestalt
• Gestalt Principles of Art and Design

I especially recommend this five-part series by Andy Rutledge.

• Gestalt Principles of Perception 1: Figure Ground Relationships
• Gestalt Principles of Perception 2: Similarity
• Gestalt Principles of Perception 3: Proximity, Uniform Connectedness, and Good Continuation
• Gestalt Principles of Perception 4: Common Fate
• Gestalt Principles of Perception 5: Closure

(cp, ml, il)

© Steven Bradley for Smashing Magazine, 2014.

Addy Osmani intros a Grunt task for removing unused CSS from your stylesheet before serving it.

While this is certainly a worthy goal, I look at the quotes from people who reduced their stylesheets by 3/4 or more and I'm like holy crap what kinda shop are you running over there?! I know "test, don't guess", but I'd guess that pretty close to 0% of the styles I write are unused. I'm sure HTML changes over time make a orphaned rule here and there, but I'd guess that is largely insignificant.

If you're going to do this, make sure you run it against lots (if not all) of your pages so you aren't removing selectors that are in use, just not on every page. I know I write minor styles all the time that make their way into the global stylesheet since that is cached and used anyway.

Direct Link to Article — Permalink

Spring-cleaning Unused CSS is a post from CSS-Tricks

Through April 14 UMBC students, faculty, and staff may purchase a 12-month Adobe Creative Cloud subscription for just $199.99.  The regular non-academic price is $599.88. The everyday UMBC academic price is $359.88.

Purchase in the store or online.

Adobe Creative Cloud software delivers groundbreaking new creative tools and provides innovative ways to design for the latest devices. With exceptional power and precision, you can create inspiring experiences that go anywhere.

Creative Cloud comes with 20GB of cloud storage and includes the following programs:

• Photoshop CC
• Illustrator CC
• InDesign CC
• Bridge CC
• Extension Manager CC
• InCopy CC
• Acrobat XI Pro
• Dreamweaver CC
• Flash Professional CC
• Flash Builder Premium Edition
• Fireworks
• Premiere Pro CC
• After Effects CC
• Audition CC
• SpeedGrade CC
• Prelude CC
• Encore
• Media Encoder CC
• Photoshop Lightroom
• Muse CC
• Edge Animate CC
• Behance

Current academic ID required. This is a download card for Windows or Mac. No media is included. Requires internet connection to download and to authenticate every 30-99 days.

There was a time when programmers were paid by the number of lines of code they wrote. They were treated as source code producing machines working in cubicles and in return they considered programming just a job that they do eight hours a day and then forget about it, for the rest of the day.

But times have changed. Most cubicle workplaces disappeared and programmers started loving their craft. With the advent of Agile techniques and the Software Craftsmanship movement, many new tools emerged to help the programmer and the process. TDD is slowly becoming the de facto way of writing code and the secrets of SCRUM or Kanban were revealed even to the programmers in the darkest corners of the cubicle world.

Automated testing and test driven development (TDD) are some of the essential techniques Agile provided to us programmers. And a tool that comes with those methodologies is used to produce test code coverage, which is the topic of this article.

Definition

"In computer science, code coverage is a measure used to describe the degree to which the source code of a program is tested by a particular test suite." ~ Wikipedia

The definition above, taken from Wikipedia, is one of the simplest ways to describe what code coverage means. Basically, in your project you have a bunch of production code as well as a bunch of test code. The test code exercises the production code and the test coverage tells you how much of your production code was exercised by the tests.

Information can be presented in various ways, from simple percentages to nice graphics or even real-time highlighting in your favorite IDE.

Let's Check It in Action

We will use PHP as the language to exemplify our code. Additionally, we will need PHPUnit and XDebug to test our code and gather coverage data.

The Source Code

Here is the source code we will use. You can also find it in the attached archive.

class WordWrap {
    
    	public function wrap($string = '', $cols) {
    		$string = trim($string);
    		if (strlen($string) > $cols) {
    			$lastSpaceIndex = strrpos(substr($string, 0, $cols), ' ');
    			if ($lastSpaceIndex !== false && substr($string, $cols, 1) != ' ') {
    				return substr($string, 0, $lastSpaceIndex) . "\n" . $this->wrap(substr($string, $lastSpaceIndex), $cols);
    			} else {
    				return substr($string, 0, $cols) . "\n" . $this->wrap(substr($string, $cols), $cols);
    			}
    		}
    
    		return $string;
    	}
    }

The above code contains a simple function that wraps text to a specified number of characters, per line.

The Test Code

We wrote this code using Test Driven Development (TDD) and we have 100% code coverage for it. This means that by running our test, we exercise each and every line of the source code.

require_once __DIR__ . '/../WordWrap.php';
    
    class WordWrapTest extends PHPUnit_Framework_TestCase {
    
    	function testItCanWrap() {
    		$w = new WordWrap();
    
    		$this->assertEquals('', $w->wrap(null, 0));
    		$this->assertEquals('', $w->wrap('', 0));
    		$this->assertEquals('a', $w->wrap('a', 1));
    		$this->assertEquals("a\nb", $w->wrap('a b', 1));
    		$this->assertEquals("a b\nc", $w->wrap('a b c', 3));
    		$this->assertEquals("a\nbc\nd", $w->wrap('a bc d', 3));
    	}
    }

Running the Tests in CLI With Text Only Coverage

One way to obtain coverage data is to run our tests in the CLI (command line interface) and analyze the output. For this example, we will assume a UNIX like operating system (Linux, MacOS, FreeBSD, etc). Windows users will need to slightly adapt the paths and executable names, but it should be fairly similar.

Let's open a console and change directories in to your test folder. Then run phpunit with an option to generate coverage data as plain text.

phpunit --coverage-text=./coverage.txt ./WordWrapTest.php

This should work out of the box on most systems if XDebug is installed, however in some cases, you may encounter an error related to time zones.

PHP Warning:  date(): It is not safe to rely on the system's timezone settings.
    You are *required* to use the date.timezone setting or the date_default_timezone_set() function.
    In case you used any of those methods and you are still getting this warning, you most likely
    misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set
    date.timezone to select your timezone. in phar:///usr/share/php/phpunit/phpunit.phar/
    PHP_CodeCoverage-1.2.10/PHP/CodeCoverage/Report/Text.php on line 124
    

This can be easily fixed by specifying the suggested setting in your php.ini file. You can find the way to specify your timezone in this list. I am from Romania, so I will use the following setting:

date.timezone = Europe/Bucharest

Now, if you run the phpunit command again, you should see no error messages. Instead, the test results will be shown.

PHPUnit 3.7.20 by Sebastian Bergmann.
    ..
    Time: 0 seconds, Memory: 5.00Mb
    OK (2 tests, 7 assertions)
    

And the coverage data will be in the specified text file.

$ cat ./coverage.txt
    
    Code Coverage Report
      2014-03-02 13:48:11
    
     Summary:
      Classes: 100.00% (1/1)
      Methods: 100.00% (1/1)
      Lines:   2.68% (14/522)
    
    WordWrap
      Methods: 100.00% ( 1/ 1)   Lines: 100.00% (  7/  7)
    

Let's analyze this a little bit.

• Classes: refers to how many classes were tested and how many of them were covered. WordWrap is our only class.
• Methods: same as with classes. We have only our wrap() method, nothing else.
• Lines: same as above, but for lines of code. Here we have a lot of lines because the summary contains all the lines from PHPUnit itself.
• Then we have a section for each class. In our case, that is only WordWrap. Each section has its own methods and line details.

Based on these observations, we can conclude that our code is 100% covered by tests. Exactly as we expected before analyzing the coverage data.

Generating HTML Coverage Output

By just changing a simple parameter for PHPUnit, we can generate nice HTML output.

$ mkdir ./coverage
    $ phpunit --coverage-html ./coverage ./WordWrapTest.php 

If you check your ./coverage directory, you will find a lot of files there. I won't paste the list here because it is quite extensive. Instead, I will show you how it looks in a web browser.

This is the equivalent of the summary section from the text version above. We can zoom in by following the proposed links and see more details.

Coverage Inside Our IDE

The previous examples were interesting and they are quite useful, if your code is built on some remote server to which you have only SHH or web access to. But wouldn't it be nice to have all this info, live in your IDE?

If you use PHPStorm, everything is within the distance of a single click! Select to run your tests with coverage and all the info will just simply show up, magically.

The coverage information will be present in your IDE, in several ways and in several places:

1. Test coverage percentage will be shown near each directory and file.
2. In the editor, while editing code, on the left of the line numbers, a green or red rectangle will mark each line. Green represents tested lines, red represents untested ones. Lines without actual code (empty lines, only braces or parentheses, class or method declarations) will not have any marks.
3. On the right side there will be file browsers where you can quickly browse and sort files by coverage.
4. In the test output, you will see a line of text announcing to you that code coverage was generated.

The Myths About Code Coverage

With such a powerful tool in the developer's hands and under the management's nose, it was inevitable for some myths to surface. After programmers refused to be payed by the number of lines of code they write, or managers realized how easy it is to game the system, some of them started paying programmers by the percentage of code coverage. Higher code coverage means the programmer was more careful, right? It's a myth. Code coverage is not a measure of how well you write code.

Sometimes programmers tend to think that code with 100% coverage has no bugs. Another myth. Code coverage merely tells you that you have tested each line of code. It is a measure of the number of lines exercised. It is not a measure of the number of lines correctly implemented. For example, half written algorithms with only half defined tests will still have 100% coverage. This does not mean the algorithm is finished or that it works correctly.

Finally, gaming the system is very easy. Of course, if you use TDD, you are naturally having a high coverage value. On whole projects, 100% is impossible. But on small modules or classes, obtaining 100% coverage is very easy. Take for example our source code and imagine you have no tests at all. What would be the simplest test to exercise all the code?

function testItCanWrap() {
    	$w = new WordWrap();
    	$this->assertEquals("a b\nc", $w->wrap('a b c', 3));
    	$this->assertEquals("a\nbc\nd", $w->wrap('a bc d', 3));
    }

That's it. Two assertions and full coverage. This is not what we want. This test is so far from descriptive and complete, that it is ridiculous.

The Reality About Code Coverage

Code coverage is a status indicator, not a unit to measure performance or correctness.

Code coverage is for programmers, not for managers. It is a way to spot problems in our code. A way to find old, untested classes. A way to find paths not exercised by the tests that could lead to problems.

On real projects, code coverage will always be under 100%. Achieving perfect coverage is not possible, or if it is, it's rarely a must. However, to have 98% of coverage you must target 100%. Having anything else as your target is non-sense.

Here is the code coverage on Syneto's StorageOS configuration application.

The total is only about 35%, but the results need interpretation. Most of the modules are in the green, with more than 70% coverage. However there is a single folder, Vmware, which pulls down the average. It is a module with a lot of classes containing only definitions for the communication API. There is no reason to test those classes. They were automatically generated by trusted code. The programmers will know this and they will know how to interpret the results. A manager may insist on testing it because it is a red bar and it looks suspicious for someone not knowing the internal details of the project. Would it make any sense to test it? Not at all! It would be a useless test, that would take up precious tens of seconds of build time without any advantage.

Final Thoughts

So here is where we are with code coverage: it's a great tool for programmers, a source of information to highlight possible problems, a misunderstood reality for most managers, and another tool to force and measure programmers' activities. As with any other tool, it is one that can be correctly used and misused easily.