October, 2014 | Webmasters Gallery

A Front-End Developer’s Ode To Specifications

October 9th, 2014 admin No comments

In the physical world, no one builds anything without detailed blueprints, because people’s lives are on the line. In the digital world, the stakes just aren’t as high.

It’s called “software” for a reason: because when it hits you in the face, it doesn’t hurt as much. No one is going to die if your website goes live with the header’s left margin 4 pixels out of alignment with the image below it.

But, while the users’ lives might not be on the line, design blueprints (also called design specifications, or specs) could mean the difference between a correctly implemented design that improves the user experience and satisfies customers and a confusing and inconsistent design that corrupts the user experience and displeases customers.

For those of us who create digital products, design specs could mean the difference between efficient collaboration and a wasteful back-and-forth process with costly implementation mistakes and delivery delays. It could also mean the difference between your business making money and losing money, in which case lives might actually be on the line.

In short, specs can help us to build the right product more quickly and more efficiently.

What Are Blueprints (And Why Are They Blue)?

Why are blueprints blue? To find the answer, let’s go back in time a bit, courtesy of Wikipedia¹:

“A blueprint is a reproduction of a technical drawing, documenting an architecture or an engineering design, using a contact print process on light-sensitive sheets. Introduced in the 19th century, the process allowed rapid and accurate reproduction of documents used in construction and industry. The blue-print process was characterized by light colored lines on a blue background, a negative of the original.”

Architectural blueprints were the photocopier of the 19th century. They were the cheapest, most reliable technology available to copy technical drawings.

²

Architectural drawing, Canada, 1936 (Image: Wikipedia³) (View large version⁴)

Blueprints were created by sending light around an ink drawing on transparent film. The light would shine through everywhere except the ink and hit a paper coated with a light-sensitive material, turning that paper blue. This outlined a white copy of the engineering drawing on a dark-blue background.

These copies were then distributed to builders who were responsible for implementing the designs in those drawings.

Today, many graphic designers also distribute design specs to the front-end developers who are responsible for implementing the designs. Design specs are no longer made with paper and light, and they are no longer blue, but, as before, they ensure that the product gets built correctly.

From Bricks To Bits And Bytes

I learned the value of architectural blueprints in my previous career as a real estate developer. One of my responsibilities was to find great architects to create blueprints so that the construction workers we hired knew exactly what to build. Somewhere along the way, I realized that real estate development was not for me: I wanted to make a greater impact by building the scalable skylines of the virtual, rather than the real, world. I learned HTML, CSS and JavaScript and went in search of startups that were hiring. My understanding of the importance of detailed blueprints went with me.

In the wild west of World Wide Web startups, I had to build single-page JavaScript applications that looked good and performed well, and I had to do it quickly. Designs were often handed down to us one week before the product’s release date, and we were asked to start sprinting. The designs usually consisted of Photoshop files (PSDs) with a lot of layers and zero specs to accompany them.

For a former real estate developer, working with graphic designs without specs was like getting a set of architectural blueprints with all of the drawings and none of the numbers. Without the necessary CSS “measurements,” I was forced to hunt through layers and sublayers of shapes and text elements to figure out the right HEX value for the border around the “Buy” button or the font family used in the “Forgot Password?” field. Such a workflow was very unproductive.

I was starving for specs when my friend Chen Blume⁵ approached me with the idea of Specctr¹⁵⁶, a tool that would bring the familiar benefits of architectural blueprints to the world of graphic design and front-end web development. I immediately recognized the value and potential of this idea, so we started working together right away, and soon after that, the first version of Specctr was released.

Properties of objects (specs) created with the Specctr plugin (Source: “Blueprints for the Web: Specctr Adobe Fireworks Plugin⁴⁴⁷”)

Initially, the Specctr plugin was for Adobe Fireworks users⁸ only, which at the time — 2012 — seemed to be the best tool for UI and web designers. Later, we expanded the range of supported apps, and today it includes Fireworks, Illustrator, Photoshop and InDesign.

A Picture (And Some Numbers) Are Worth More Than A Thousand Words

They say that a picture is worth a thousand words⁹. Well, a picture and some RGB values could be worth much more!

3-1913-piqua-ohio-advertisement-500px — “One look is worth a thousand words” appears in a 1913 newspaper advertisement for the Piqua Auto Supply House of Piqua, Ohio (Image: Wikipedia¹⁰).

The phrase “A picture is worth a thousand words” means that a complex idea can be conveyed with just a single still image. It also characterizes well one of the main goals of visualization, which is to make it possible to absorb large amounts of data quickly. However, in the design and development business, a picture or a single PSD is not enough.

Developers need to know a design’s exact attributes to be able to write the HTML and CSS necessary to recreate the text and shape elements via code. If a PSD is not accompanied by detailed specs, then making approximate guesses or hunting through layers could lead either to errors or the loss of precious development time.

Developer Focus

When developing something, I might need several minutes to load the necessary mental models in my head before I can be productive. Any interruption could bring a wrecking ball to the intricate imaginary machinery I’ve struggled to assemble inside my head.

This is why having to look up an RGB value or turn to a teammate to ask which typeface is being used could lead to big gaps in my productivity.

And if you’re a member of a distributed or remote team, then you don’t even have the luxury of immediately getting your questions answered by a colleague — you’re off to an asynchronous communication tool like Skype, Hipchat or, worse, email. As Chris Parnin puts it¹¹:

“The costs of interruptions have been studied in office environments. An interrupted task is estimated to take twice as long and contain twice as many errors as uninterrupted tasks. Workers have to work in a fragmented state as 57% of tasks are interrupted. For programmers, there is less evidence of the effects and prevalence of interruptions. Typically, the number that gets tossed around for getting back into the ‘zone’ is at least 15 minutes after an interruption. Interviews with programmers produce a similar number.”

4-this-is-why-you-shouldnt-interrupt-a-programmer-500px — This is why you shouldn’t interrupt a programmer. Seriously. (Check the full comic strip¹² by Jason Heeris!)

A Carnival Of Errors: Developer Edition

Julia had been at her computer for eight straight hours and was late for dinner with her parents, but she had promised to have this CSS transition between the “product” overlay and “buy” overlay on the master branch by the end of the day. She was almost done, but the type on this “Submit” button didn’t look the same as the one that was live on the website now.

“It’s fine,” she thought. “I’ll change it tomorrow.”

Faced with short deadlines and the prospect of rummaging through Photoshop layers, some developers would take a stab in the dark with what type to use — thus, negating the hours of design research they’ve invested with one stress-fueled decision.

5-buy-button-example-500px — The font looks the same. Well, almost.

In the end, we’ll have to redo it anyway, but for now we’ll meet the deadline. It’s all about developer convenience.

No one in the history of forever put in extra effort to do the wrong thing. Mistakes are usually the result of following a tempting shortcut.

The record industry’s failed attempt to halt the digital distribution of music is a good example of this. Spotify’s whole business model¹³ is based on the fact that “people were willing to do the right thing but only if it was just as rewarding, and much less hassle, than doing the wrong thing.”

Give your front-end engineer a fully spec’ed design and then bask in the rays of gratitude emanating from their face. They’ll get all of your margins and padding exactly right; that subtle gradient will have the precise values you took so long to match; and it will all get done faster. Why would they do anything else? All of the information they need is right there in front of them!

The Triumph Of Tediousness: Designer Edition

Lauren took a second to appreciate her finished design. It was well-balanced and conveyed a sense of calmness, all while guiding attention towards the “Submit” button.

She was tired and ready to go home after a long day of work, but she had promised to deliver the finished design so that Julia could get a head start on developing it for tomorrow’s deadline. She sometimes created specs for the developers she worked with, but she just didn’t have it in her to type and draw out each individual annotation “by hand.”

“Julia will figure it out,” she thought to herself as she hit “Send.”

It’s all about designer convenience.

If design specs (i.e. blueprints) have so much to offer, then why aren’t they a part of every designer’s workflow? The reason I, as a developer, might skip looking up the type is the same reason many designers don’t create specs: It’s easier not to.

This is because designers are not using the right tools. They manually measure and draw each dimension, and they type each pixel value and RGB value “by hand,” using the same general-purpose drawing tools that they used to create the design.

Any time you ask an artist to stop creating and focus on process, you’re fighting an uphill battle. The hill becomes dramatically steeper when the process is slow and tedious.

With the right tools to automate the creation of specs, designers can reduce costs and enable their whole team to reap the benefits of creating and distributing design specs.

Let’s Create (And Use) Design Specs

The two examples above — with Julia and Lauren — are imaginary, but that doesn’t mean they don’t happen constantly in real life. Developers should not have to make any guesses that lead to errors and lose time. On the other hand, creating detailed specs manually is tedious and takes a lot of the designer’s time.

Is there a better way? I believe there is.

We should start using tools that help us to create design specs with a minimum of hassle. Such tools would save time for both designers and developers and would lead to better designer-developer workflows.

Below are some excerpts from a design document annotated with Specctr. With the help of the Specctr plugin, a designer could quickly provide the color values of any design element, along with the exact width and height, gradient values, type attributes (including font family, weight, kerning, leading, etc.), margins, padding, border properties and more. This would greatly help the developer to implement the design because they would not need to hunt through layers and sublayers or make any guesses.

6-specctr-top-left-spec-500px — Text and spacing specs generated with Specctr¹⁵⁶ (View large version¹⁶)

7-specctr-mid-left-spec-500px — hape and text specs generated with Specctr (View large version¹⁸)

8-specctr-mid-bottom-spec-500px — Coordinate and spacing specs generated with Specctr (View large version²⁰)

As a bonus side effect, using detailed design specs will help you to avoid errors and inconsistencies in the final version of the design when it’s implemented in real life. Below is an example of the “drift” that can occur when implementation details are not made explicit and are left up to the developer’s guesswork.

9-how-a-design-can-deviate-without-documentation-example-500px — A comparison of how a design can deviate from a designer’s vision without proper documentation: spec’ed design on the left, unspec’ed design on the right. (View large version²²)

Note: Specctr is not the only tool that automatically generates detailed design specs. Plugins such as PNG Express²³ (designed to work with Photoshop) do similar tasks, but I’ve been mentioning Specctr because I develop?d it myself and have the most experience with it. If you have tried other spec-generation tools, please, share your experience in the comments below.

Components And Style Guides

Developers have long been familiar with the advantages of breaking a large system down into small components through object-oriented programming²⁴, which is currently the dominant programming paradigm, thanks to the adoption of languages such as Java²⁵. Breaking a complex project into self-contained parts that make up the whole allows a single part to be reused in multiple places in a project and allows for greater project organization and easier maintenance.

Designers are also finding²⁶ that breaking down a design into its atomic components allows for greater efficiency because they’re able to combine them to reuse their code and styles²⁷. Seeing the components from which a project’s entire design is derived allows for the immediate communication of style choices made across that project. Examples of the components that would be shown are the grid, buttons, forms, tables and lists.

10-mozilla-grid-comp-500px — Grid component from Mozilla’s “Style Guide”²⁹. (View large version³⁰

11-mozilla-list-comp-500px — List component from Mozilla’s “Style Guide”. (View large version³²

Components combined with design specs make up a style guide³³. A style guide serves as a reference both to communicate a project’s design aesthetic and to provide details of its implementation to developers. Developers no longer have to rely on designers to spec individual documents, and can instead use this reference to find the information they need. In this way, a style guide is another great tool for more efficient collaboration between designers and developers.

12-style-guide-fireworks-500px — A style guide will help you to maintain a consistent look over time. (Source: “How to Make an Effective Style Guide With Adobe Fireworks⁴³³⁵”). (View large version³⁶

Conclusion

I reached out to a few designers for comments about the process they follow to document designs. One of my favorite responses comes from Jason Csizmadi, senior visual designer at Cooper³⁷:

“Developers at all stages of projects expect and demand strong documentation.

Although documentation is never the most exciting aspect of design, it’s a critical step in ensuring smooth working relationships, timely delivery and a successful hand-off at the end. Ultimately, design documentation acts as a life-support system, ensuring that your vision is executed properly.”

Like any good business process, design specs should support the primary endeavor — in this case, to create beautiful websites and applications. Creating these products requires collaboration between designers and developers, and effective collaboration requires effective communication. Investing in the development of workflows and tooling around to make this communication easier and more efficient will pay off big with the speed and effectiveness with which products are built and, ultimately, with the success of the businesses that depend on those products.

Footnotes

The post A Front-End Developer’s Ode To Specifications appeared first on Smashing Magazine.

Categories: Others Tags:

Freebie: 36 Flat Simple Entertainment Icons

October 9th, 2014 admin No comments

Here we have a set of 36 entertainment icons exclusively from Vecteezy, They provide a place for vector artists to create and exchange a variety of free vector graphics like Vector, Vector Patterns, Vector Swirls, Flourishes and other cool stuff to enhance your designs and creativity.

Download Icons 1.4mb

More from Vecteezy

Check out more of their entertainment icons

Categories: Designing, Others Tags:

Freebie: 36 Flat Simple Entertainment Icons

October 9th, 2014 admin No comments

Here we have a set of 36 entertainment icons exclusively from Vecteezy, They provide a place for vector artists to create and exchange a variety of free vector graphics like Vector, Vector Patterns, Vector Swirls, Flourishes and other cool stuff to enhance your designs and creativity.

Download Icons 1.4mb

More from Vecteezy

Check out more of their entertainment icons

Categories: Designing, Others Tags:

Quick, Not Dirty: 30 Free Wireframe Style UIs, Mockups and Templates

October 9th, 2014 admin No comments

Attention to detail is important in any kind of design. Web design means no exception. Yet before we get into that detail we should always scribble up a quick mockup of what we want the project to look and feel like. Some put detail even into that mockup, some stay minimalist. Whatever your approach is, we have curated a nice collection of recent mockup templates for all purposes. Have fun…

Categories: Others Tags:

Mobile Design Pattern: Inventory-Based Discrete Slider

October 8th, 2014 admin No comments

Sliders are cool. When they’re done well, customers love to interact with them. When they’re not done well, they can cause a lot of frustration (not to mention lost sales) by standing between your customers and what they want. And getting them wrong is surprisingly easy.

In this article, we will present a solution, including the design and code, for a new type of Android slider to address common problems, along with a downloadable Android mini-app for you to try out. It’s a deep dive into sliders based on a chapter in Android Design Patterns. The experimental inventory-based slider we will look at would be at home in any application that asks for a price, a size, or any other faceted input within a widely distributed range.

Why Sliders?

Sliders are intuitive. They provide affordance, a quality that makes a control right for a particular task. They just feel right for dialing a value within a range. Sliders translate well from the physical world to touchscreens, where they look great and are easy to manipulate, without taking up a lot of space. Dual sliders in particular are great for limiting search filters and form values to a set range.

In the physical world, sliders serve a function similar to twist knobs. However, knobs are hard to “turn” on touchscreens, and they usually take up more space than sliders. For touchscreens, sliders are better.

Types Of Sliders

Sliders come in two types: single and double. Single sliders are best for entering one value. Dual sliders are great for searching within a range of values.

There are also two kinds of adjustments: continuous and discrete. Continuous adjustments are for indeterminate values in a range, such as a price or temperature. Discrete adjustments are for predefined values (such as clothing sizes). Both single sliders and dual sliders can take either kind of adjustment. Let’s look at some examples.

Zillow has customers use two single sliders with continuous adjustment to set a price range.

¹

The Zillow app uses two single sliders, both with continuous adjustment. (View large version²)

This real-estate app Trulia uses two dual sliders with continuous adjustments:

³

The Trulia app uses two dual sliders with continuous adjustments. (View large version⁴)

Continuous adjustments for prices make sense. Why? Because price ranges are continuous. But they do allow for more precision than most shoppers care about. (A price difference of one cent is unlikely to make a customer reconsider a purchase.)

Discrete adjustments are different. They let you choose values, but only within predefined (i.e. discrete) increments. Facets like shoe size consist of discrete values; in the US and Western Europe, shoes are typically incremented in half-sizes: 6, 6.5, 7 and so on. You can’t buy shoes in a size of 6.25, so providing a control for this level of precision would not make sense.

One way to understand the difference is that single sliders with a low count of discrete values are similar to stepper controls: You can dial the value you want, but only from a predefined set.

03-dual-slider-opt-500 — This is an example of a dual slider with discrete adjustment stops. (View large version⁶)

Experimental Slider Patterns

Sliders with histograms and sliders based on inventory counts are two great experimental patterns that are variations on the standard slider. It’s unfortunate that they are not more common because they solve many of the problems that sliders can cause for users. We explain the problems with regular sliders in the “Caution” section below and detail the experimental solution in the “Super-Sliders” section (right after “Caution”).

So, at this point, you might be thinking, “Sliders sound great. What’s the downside?” Glad you asked.

Caution

Even the best patterns can go bad. Like Harvey Dent, the once loyal ally of Batman and Gotham City’s impeccably ethical district attorney, most things have a dark side. There’s a slippery slope between delight and dismay, and much like the Two-Face character who Dent becomes, sliders can be helpful or hateful. It all depends on how they’re implemented.

Here’s how to sidestep slider problems and keep your customers happy.

Make Sure Reasonable Values Can Be Entered Easily

Kayak has a continuous dual slider for filtering hotel prices (see screenshots below). To get a hotel in Los Angeles that you can afford on a humble mobile UX design consultant’s salary, you must place the pegs right on top of one another. This adjustment is anything but precise. For wide ranges, consider using a slider based on inventory counts, as explained in the “Super-Sliders” section coming up.

04-kayak-app-slider-opt-500 — The continuous price slider fails to dial a reasonable hotel price in Los Angeles on Kayak’s app. (View large version⁸)

Show the Range

Speaking of range, showing the actual range of prices available in an entire collection is a great idea, as shown in the Kayak screenshots above ($38 to $587), instead of using arbitrary numbers such as $0 and max. Neither Zillow nor Trulia show the true maximum and minimum associated with their local home inventory.

Imagine how useful these sliders would be if they stated from the beginning that they ranged between $476,000 and $3,234,700. Showing the range also helps to avoid dead zones, such as when you’re looking for a home in San Francisco priced below $476,000, which would yield zero results. Be aware of how filtering affects the inventory; setting the range for the overall collection without applying the filters is best.

Don’t Cover the Numbers

As the customer adjusts the slider, the values should appear above the pegs, where the user’s fingers would not cover them. Placing the numbers below or to the side of the slider is not as useful. Kayak’s slider (shown above) is good in this regard: The range is covered while the customer adjusts the slider, but the filter’s actual value is not, which is about the best you can do on a mobile device.

Opt for a Slider With Discrete Positions

Continuous sliders are sexy in principle, because you can dial an exact number and get just the inventory you want. But the reality is that sliders are hard to adjust precisely — both in the physical world and on touch devices. That’s why you almost never see a slider for volume adjustment on a stereo. Ironically, the larger the device, the harder that adjusting the slider precisely seems to be. This is Fitts’ law in action: The time required for an action depends on the distance and size of the target. In other words, adjusting a tiny peg in the middle of a large tablet is difficult.

Regardless of the screen’s size, adjusting a continuous slider precisely while being bumped around on a train is hard. (You have permission to refer to this hereafter as Nudelman’s law if you wish.)

Continuous dual sliders also make it easy to over-constrain the range. For example, creating a continuous slider that enables the customer to dial a price of $45.50 to $46.10 might yield zero results and would not serve the customer well. On the other hand, sliders with discrete positions (i.e. stops) are much easier to adjust. The chance of dialing a range that is too small is also less.

Super-Sliders Save The Day

How can you implement a dual slider so that the user is able to input a price range without running into the dreaded problem of zero results mentioned in the “Caution” section above? Here’s where the experimental patterns discussed earlier come in. These are like regular sliders slightly souped up — super-sliders, if you will. Let us explain.

Regular Slider

A slider could use discrete values arranged according to inventory counts. This type of slider is typically arranged in a linear pattern, which means that a certain distance of movement on the slider’s axis represents an equal absolute change in value. For example, in a five-position slider, the price would go from $0 to $100 in $20 increments:

05-linear-price-slider-opt-500 — Each mark on the axis represents an equal absolute change in value on a linear price slider. (View large version¹⁰)

Although this is intuitive, the design makes it easy for customers to come up empty-handed, especially if the range is wide and the inventory is not equally distributed.

As explained in the “Caution” section, a customer shopping for superhero capes might select a range for which the inventory is zero — say, $40 to $60 — not knowing that a whole closetful of capes are available in the $62 to $65 range — literally, For a Few Dollars More. (Apologies to Clint Eastwood and Westerns lovers everywhere.)

Super-Slider (With Zero-Results-Fighting Histogram)

This is where a slider with a histogram (as shown below) is helpful. The idea behind this experimental pattern is simple: The 50 to 100 pixels above the fixed-position slider is a histogram that represents the inventory in a particular section of the linear price range. A high bar represents a large numbers of items, and a proportionally short bar represents a smaller number of items. That’s it.

06-linear-histogram-slider-opt-500 — A linear price slider with histogram provides more information. (View large version¹²)

When using a slider with a histogram, you can still dial the part of the range with low inventory; but making that mistake accidentally is difficult because the inventory counts are clearly shown in the histogram. You can use a slider with a histogram where a standard discrete-position slider would be used; it would take up only a little more vertical space in exchange for a more satisfying customer experience.

No Room for a Histogram?

Another way to implement a slider without using histograms is to arrange the slider’s intervals based on the inventory counts. To do this, divide your entire inventory — say, 100 capes — into five intervals, and you’ll get 20 capes per interval. Now, scan the price range to figure out the price (rounded to the nearest dollar) that corresponds to the approximate inventory count of 20. Suppose the first 19 capes cost between $0 and $60 (remember that we’re assuming no inventory in the $40 to $60 range), the second 21 capes fall in the $61 to $65 range, and so on. Here is what such a slider might look like:

07-alternative-price-slider-opt-500 — The alternative price slider is based on the inventory counts. (View large version¹⁴)

Which implementation should you choose? It depends on the task. Most people don’t mind paying a few dollars outside of their budget, but they absolutely hate getting zero results. An inventory of fewer than 20 items in a given interval is not a satisfying result for most tasks, so use one of the other approaches to provide a better experience. Both a slider with a histogram and a slider based on inventory counts are far superior to the traditional slider. Breaking down the interval according to price is the more flexible approach because it shows the distribution clearly, while never yielding zero results. If the customer’s price range is larger than that of a single 20-item interval, then they can simply select a larger interval using the dual slider.

Both of the experimental sliders out-performed the regular slider in a study we did for a large retailer. Try it yourself. Create a quick prototype and do some “hallway usability.” Ask users to find some items around $70, and compare how they do with the histogram version, the inventory-based version and the regular version.

Tablet Apps

Sliders perform well in tablet apps. Make sure you heed the warnings in the “Caution” section; in particular, opt for a slider with discrete values to ensure accuracy, instead of a continuous slider (adjusting a continuous slider accurately on a large device is harder). Consider device ergonomics and avoid placing sliders in the middle of the screen. Instead, place sliders near the top of the screen, next to the right or left margin, optimized for one-handed operation with the thumb while the fingers hold on to the back of the tablet.

Depending on the design and purpose of your app, experiment by having two sets of sliders on the left and right sides of the screen, to be adjusted by the left and right hands, respectively. This would be especially interesting in apps such as music synthesizers. Finally, experiment with placing sliders vertically along the edge of the tablet (top to bottom), rather than horizontally from left to right, which is the easiest direction to adjust precisely with the thumb, while the fingers hold the back of the tablet.

Try It Out

To see how a slider app feels, a completed slider mini-app is available for you to download and try out. If you’re a developer, you can use it in your own project free of charge (see the “Code” section coming up). To install it, consider using an app installer such as the one made by FunTrigger¹⁵, which you can get free on the Play market. Here’s how it works. Connect your Android device to your computer. You should see the Android file-transfer window open automatically. If not, you might need to install software on your computer such as Android File Transfer (Mac users, take note). Download the APK source file ¹⁶, and place it in the “App Installer” directory (you might have to create the directory).

08-apk-file-opt-500 — Place the APK file in Android’s file-transfer window. (View large version¹⁸)

Now, you will be able to launch the app installer on your device. Navigate to the right directory, and tap the icon for the APK file that you want to install.

09-app-launcher-opt — Use the app launcher to install the app.

After a few customary Android disclaimers, the app will be installed in the normal app area on your device, and you can launch it from there.

Code

We’re providing you with the Java code¹⁹ and a demo of a simple dual slider with discrete stops.

This demo has five intervals between the minimum and maximum values, which we’ve arbitrarily set to $47 and $302. It’s arranged in a linear pattern, which means that a certain distance of movement on the slider’s axis represents an equal absolute change in value, making the increment value $51. In a real app, the values would most likely be derived from a database.

private static final int RANGE_MIN_VALUE = 47;
private static final int RANGE_MAX_VALUE = 302;
private static final int[] RANGE_STEPS = new int[] {
47, 98, 149, 200, 251, 302
};

While five is a good number in principle, you might want to experiment with intervals of seven or nine, depending on the size of the screen.

We recommend that you use the MOD function to determine how many capes need to be in each interval. Then, walk the interval to determine the price breakdown within each range. Finally, if MOD yields a remainder, you can add it to the last interval, or you could get fancier and loop through it to add one or more “excess” capes to each of the intervals. For example, if you have 103 capes, the intervals would be 21, 21, 21, 20, 20. This would more evenly distribute the inventory.

You could use the app as is for your own projects or as a starting point for something fancier. May we suggest a slider with a histogram or an inventory count?

If you do use the code, we’d love to see what you’ve done with it.

This code is provided free of charge and distributed under the GNU General Public License v3. See the README_LICENSE file for details.

Download the complete source code for the app.²⁰

Conclusion

Say it with us, “Done right, sliders delight.”
Sliders turn your customers into empowered explorers and instant item locators. Don’t let a good pattern go bad: Remember these rules, and sidestep slider problems.
Make sure that reasonable values can be entered easily, and don’t cover the numbers.
Say no to fat-fingered fumbling with small increments in large ranges. Speaking of ranges…
Show the range.
Stamp out unhelpful labels like “$0” and “No limit.” Instead, show the actual minimum and maximum values that the customer can search within.
Be discrete.
Continuous range sliders aren’t always the best choice. Discrete stops are better for small sets of predefined values, such as shoe sizes (and cape sizes.) And finally…
Zap zero results.
Fight the frustrating fruitless search. Want to give your customers ninja navigational powers? Add a histogram, or use smart intervals based on your inventory.

That’s all there is to it. Working with sliders is no great mystery. You know the patterns. You’ve nabbed the code. Now there’s nothing to stop you from trying a slider.

Want more patterns? Android Design Patterns: Interaction Design Solutions for Developers²¹ has over 70, including a free design mini-course.

(al, ml)

Footnotes

The post Mobile Design Pattern: Inventory-Based Discrete Slider appeared first on Smashing Magazine.

Categories: Others Tags:

Win Avada, the Bestselling WordPress Theme of All Time on Themeforest

October 8th, 2014 admin No comments

What if there was a theme that does it all? One theme to serve the needs of all your customers? Only one theme with enough features to have it look differently, behave differently with every new project created? You say you’ve been looking for something like this for ages? In fact this theme already exists, and more than 85,000 people know. Now is the time for you to jump aboard. We welcome you there with the chance to win yourself a license. Read on, it’s easy…

Categories: Others Tags:

An Introduction To Unit Testing In AngularJS Applications

October 7th, 2014 admin No comments

Everything is bricks, regardless of the level you are at.

AngularJS¹ has grown to become one of the most popular single-page application frameworks. Developed by a dedicated team at Google, the outcome is substantial and widely used in both community and industry projects.

One of the reasons for AngularJS’ success is its outstanding ability to be tested. It’s strongly supported by Karma¹¹² (the spectacular test runner written by Vojta Jína) and its multiple plugins. Karma, combined with its fellows Mocha¹⁷³, Chai¹⁸⁴ and Sinon²⁰⁵, offers a complete toolset to produce quality code that is easy to maintain, bug-free and well documented.

“Well, I’ll just launch the app and see if everything works. We’ve never had any problem doing that – No one ever.”

The main factor that made me switch from “Well, I just launch the app and see if everything works” to “I’ve got unit tests!” was that, for the first time, I could focus on what matters and on what I enjoy in programming: creating smart algorithms and nice UIs.

I remember a component that was supposed to manage the right-click menu in an application. Trust me, it was a complex component. Depending on dozens of mixed conditions, it could show or hide buttons, submenus, etc. One day, we updated the application in production. I can remember how I felt when I launched the app, opened something, right-clicked and saw no contextual menu — just an empty ugly box that was definitive proof that something had gone really wrong. After having fixed it, re-updated the application and apologized to customer service, I decided to entirely rewrite this component in test-driven development style. The test file ended up being twice as long as the component file. It has been improved a lot since, especially its poor performance, but it never failed again in production. Rock-solid code.

A Word About Unit Testing

Unit testing has become a standard in most software companies. Customer expectations have reached a new high, and no one accepts getting two free regressions for the price of one update anymore.

If you are familiar with unit testing, then you’ll already know how confident a developer feels when refactoring tested code. If you are not familiar, then imagine getting rid of deployment stress, a “code-and-pray” coding style and never-ending feature development. The best part of? It’s automatic.

Unit testing improves code’s orthogonality. Fundamentally, code is called “orthogonal” when it’s easy to change. Fixing a bug or adding a feature entails nothing but changing the code’s behavior, as explained in The Pragmatic Programmer: From Journeyman to Master⁶. Unit tests greatly improve code’s orthogonality by forcing you to write modular logic units, instead of large code chunks.

Unit testing also provides you with documentation that is always up to date and that informs you about the code’s intentions and functional behavior. Even if a method has a cryptic name — which is bad, but we won’t get into that here — you’ll instantly know what it does by reading its test.

Unit testing has another major advantage. It forces you to actually use your code and detect design flaws and bad smells. Take functions. What better way to make sure that functions are uncoupled from the rest of your code than by being able to test them without any boilerplate code?

Furthermore, unit testing opens the door to test-driven development. While it’s not this article’s topic, I can’t stress enough that test-driven development is a wonderful and productive way to write code.

What and What Not to Test

Tests must define the code’s API. This is the one principle that will guide us through this journey. An AngularJS application is, by definition, composed of modules. The elementary bricks are materialized by different concepts related to the granularity at which you look at them. At the application level, these bricks are AngularJS’ modules. At the module level, they are directives, controllers, services, filters and factories. Each one of them is able to communicate with another through its external interface.

⁷

Everything is bricks, regardless of the level you are at. (View large version⁸)

All of these bricks share a common attribute. They behave as black boxes, which means that they have a inner behavior and an outer interface materialized by inputs and outputs. This is precisely what unit tests are for: to test bricks’ outer interfaces.

⁹

Black box model (well, this one is gray, but you get the idea) (View large version¹⁰)

Ignoring the internals as much as possible is considered good practice. Unit testing — and testing in general — is a mix of stimuli and reactions.

Bootstrapping A Test Environment For AngularJS

To set up a decent testing environment for your AngularJS application, you will need several npm modules. Let’s take a quick glance at them.

Karma: The Spectacular Test Runner

Karma¹¹² is an engine that runs tests against code. Although it has been written for AngularJS, it’s not specifically tied to it and can be used for any JavaScript application. It’s highly configurable through a JSON file and the use of various plugins.

If you don't see this at some point in this process, then you might have missed something. — If you don’t see this at some point in the process, then you might have missed something. (View large version¹³)

All of the examples in this article can be found in the dedicated GitHub project¹⁴, along with the following configuration file for Karma.

// Karma configuration
// Generated on Mon Jul 21 2014 11:48:34 GMT+0200 (CEST)
module.exports = function(config) {
  config.set({

    // base path used to resolve all patterns (e.g. files, exclude)
    basePath: '',

    // frameworks to use
    frameworks: ['mocha', 'sinon-chai'],

    // list of files / patterns to load in the browser
    files: [
      'bower_components/angular/angular.js',
      'bower_components/angular-mocks/angular-mocks.js',
      'src/*.js',
      'test/*.mocha.js'
    ],

    // list of files to exclude
    exclude: [],

    // preprocess matching files before serving them to the browser
    preprocessors: {
      'src/*.js': ['coverage']
    },

    coverageReporter: {
      type: 'text-summary',
      dir: 'coverage/'
    },

    // test results reporter to use
    reporters: ['progress', 'coverage'],

    // web server port
    port: 9876,

    // enable / disable colors in the output (reporters and logs)
    colors: true,

    // level of logging
    logLevel: config.LOG_INFO,

    // enable / disable watching file and executing tests on file changes
    autoWatch: true,

    // start these browsers
    browsers: ['PhantomJS'],

    // Continuous Integration mode
    // if true, Karma captures browsers, runs the tests and exits
    singleRun: false
  });
};

This file can be automagically generated by typing karma init in a terminal window. The available keys are described in Karma’s documentation¹⁵.

Notice how sources and test files are declared. There is also a newcomer: ngMock¹⁶ (i.e. angular-mocks.js). ngMock is an AngularJS module that provides several testing utilities (more on that at the end of this article).

Mocha

Mocha¹⁷³ is a testing framework for JavaScript. It handles test suites and test cases, and it offers nice reporting features. It uses a declarative syntax to nest expectations into cases and suites. Let’s look at the following example (shamelessly stolen from Mocha’s home page):

describe('Array', function() {
  describe('#indexOf()', function() {
    it('should return -1 when the value is not present', function() {
      assert.equal(-1, [1,2,3].indexOf(5));
      assert.equal(-1, [1,2,3].indexOf(0));
    });
  });
});

You can see that the whole test is contained in a describe call. What is interesting about nesting function calls in this way is that the tests follow the code’s structure. Here, the Array suite is composed of only one subsuite, #indexOf. Others could be added, of course. This subsuite is composed of one case, which itself contains two assertions and expectations. Organizing test suites into a coherent whole is essential. It ensures that test errors will be reported with meaningful messages, thus easing the debugging process.

Chai

We have seen how Mocha provides test-suite and test-case capabilities for JavaScript. Chai¹⁸⁴, for its part, offers various ways of checking things in test cases. These checks are performed through what are called “assertions” and basically mark a test case as failed or passed. Chai’s documentation has more¹⁹ on the different assertions styles.

Sinon

Sinon²⁰⁵ describes itself as “standalone test spies, stubs and mocks for JavaScript.” Spies, stubs and mocks all answer the same question: How do you efficiently replace one thing with another when running a test? Suppose you have a function that takes another one in a parameter and calls it. Sinon provides a smart and concise way to monitor whether the function is called and much more (with which arguments, how many times, etc.).

Unit Testing At The Application Level

The point of the external interface of a module in an AngularJS application is its ability to be injected into another module — that it exists and has a valid definition.

beforeEach(module('myAwesomeModule'));

This is enough and will throw an error if myAwesomeModule is nowhere to be found.

Unit Testing At The Module Level

An AngularJS module can declare several types of objects. Some are services, while others are more specialized. We will go over each of them to see how they can be bootstrapped in a controlled environment and then tested.

Filters, Services and Factories: A Story of Dependency Injection

Filters, services and factories (we will refer to these as services in general) can be compared to static objects or singletons in a traditional object-oriented framework. They are easy to test because they need very few things to be ready, and these things are usually other services.

AngularJS links services to other services or objects using a very expressive dependency-injection model, which basically means asking for something in a method’s arguments.

What is great about AngularJS’ way of injecting dependencies is that mocking a piece of code’s dependencies and injecting things into test cases are super-easy. In fact, I am not even sure it could be any simpler. Let’s consider this quite useful factory:

angular.module('factories', [])
.factory('chimp', ['$log', function($log) {
  return {
    ook: function() {
      $log.warn('Ook.');
    }
  };
}]);

See how $log is injected, instead of the standard console.warn? While AngularJS will not print $log statements in Karma’s console, avoid side effects in unit tests as much as possible. I once reduced by half the duration of an application’s unit tests by mocking the tracking HTTP requests — which were all silently failing in a local environment, obviously.

describe('factories', function() {

  beforeEach(module('factories'));

  var chimp;
  var $log;

  beforeEach(inject(function(_chimp_, _$log_) {
    chimp = _chimp_;
    $log = _$log_;
    sinon.stub($log, 'warn', function() {});
  }));

  describe('when invoked', function() {

    beforeEach(function() {
      chimp.ook();
    });

    it('should say Ook', function() {
      expect($log.warn.callCount).to.equal(1);
      expect($log.warn.args[0][0]).to.equal('Ook.');
    });
  });
});

The pattern for testing filters, services or other injectables is the same. Controllers can be a bit trickier to test, though, as we will see now.

Controllers

Testing a controller could lead to some confusion. What do we test? Let’s focus on what a controller is supposed to do. You should be used to considering any tested element as a black box by now. Remember that AngularJS is a model-view-whatever (MVW) framework, which is kind of ironic because one of the few ways to define something in an AngularJS application is to use the keyword controller. Still, any kind of decent controller usually acts as a proxy between the model and the view, through objects in one way and callbacks in the other.

The controller usually configures the view using some state objects, such as the following (for a hypothetical text-editing application):

angular.module('textEditor', [])

.controller('EditionCtrl', ['$scope', function($scope) {
  $scope.state = {toolbarVisible: true, documentSaved: true};
  $scope.document = {text: 'Some text'};

  $scope.$watch('document.text', function(value) {
    $scope.state.documentSaved = false;
  }, true);

  $scope.saveDocument = function() {
    $scope.sendHTTP($scope.document.text);
    $scope.state.documentSaved = true;
  };

  $scope.sendHTTP = function(content) {
    // payload creation, HTTP request, etc.
  };
}]);

Chances are that the state will be modified by both the view and the controller. The toolbarVisible attribute will be toggled by, say, a button and a keyboard shortcut. Unit tests are not supposed to test interactions between the view and the rest of the universe; that is what end-to-end tests are for.

The documentSaved value will be mostly handled by the controller, though. Let’s test it.

describe('saving a document', function() {

  var scope;
  var ctrl;

  beforeEach(module('textEditor'));

  beforeEach(inject(function($rootScope, $controller) {
    scope = $rootScope.$new();
    ctrl = $controller('EditionCtrl', {$scope: scope});
  }));

  it('should have an initial documentSaved state', function(){
    expect(scope.state.documentSaved).to.equal(true);
  });

  describe('documentSaved property', function() {
    beforeEach(function() {
      // We don't want extra HTTP requests to be sent
      // and that's not what we're testing here.
      sinon.stub(scope, 'sendHTTP', function() {});

      // A call to $apply() must be performed, otherwise the
      // scope's watchers won't be run through.
      scope.$apply(function () {
        scope.document.text += ' And some more text';
      });
    });

    it('should watch for document.text changes', function() {
      expect(scope.state.documentSaved).to.equal(false);
    });

    describe('when calling the saveDocument function', function() {
      beforeEach(function() {
        scope.saveDocument();
      });

      it('should be set to true again', function() {
        expect(scope.state.documentSaved).to.equal(true);
      });

      afterEach(function() {
        expect(scope.sendHTTP.callCount).to.equal(1);
        expect(scope.sendHTTP.args[0][0]).to.equal(scope.document.text);
      });
    });
  });
});

An interesting side effect of this code chunk is that it not only tests changes on the documentSaved property, but also checks that the sendHTTP method actually gets called and with the proper arguments (we will see later how to test HTTP requests). This is why it’s a separated method published on the controller’s scope. Decoupling and avoiding pseudo-global states (i.e. passing the text to the method, instead of letting it read the text on the scope) always eases the process of writing tests.

Directives

A directive is AngularJS’ way of teaching HTML new tricks and of encapsulating the logic behind those tricks. This encapsulation has several contact points with the outside that are defined in the returned object’s scope attribute. The main difference with unit testing a controller is that directives usually have an isolated scope, but they both act as a black box and, therefore, will be tested in roughly the same manner. The test’s configuration is a bit different, though.

Let’s imagine a directive that displays a div with some string inside of it and a button next to it. It could be implemented as follows:

angular.module('myDirectives', [])
.directive('superButton', function() {
  return {
    scope: {label: '=', callback: '&onClick'},
    replace: true,
    restrict: 'E',
    link: function(scope, element, attrs) {

    },
    template: '<div>' +
      '<div>{{label}}</div>' +
      '<button ng-click="callback()">Click me!</button>' +
      '</div>'
  };
});

We want to test two things here. The first thing to test is that the label gets properly passed to the first div‘s content, and the second is that something happens when the button gets clicked. It’s worth saying that the actual rendering of the directive belongs slightly more to end-to-end and functional testing, but we want to include it as much as possible in our unit tests simply for the sake of failing fast. Besides, working with test-driven development is easier with unit tests than with higher-level tests, such as functional, integration and end-to-end tests.

describe('directives', function() {

  beforeEach(module('myDirectives'));

  var element;
  var outerScope;
  var innerScope;

  beforeEach(inject(function($rootScope, $compile) {
    element = angular.element('<super-button label="myLabel" on-click="myCallback()"></super-button>');

    outerScope = $rootScope;
    $compile(element)(outerScope);

    innerScope = element.isolateScope();

    outerScope.$digest();
  }));

  describe('label', function() {
    beforeEach(function() {
      outerScope.$apply(function() {
        outerScope.myLabel = "Hello world.";
      });
    })

    it('should be rendered', function() {
      expect(element[0].children[0].innerHTML).to.equal('Hello world.');
    });
  });

  describe('click callback', function() {
    var mySpy;

    beforeEach(function() {
      mySpy = sinon.spy();
      outerScope.$apply(function() {
        outerScope.myCallback = mySpy;
      });
    });

    describe('when the directive is clicked', function() {
      beforeEach(function() {
        var event = document.createEvent("MouseEvent");
        event.initMouseEvent("click", true, true);
        element[0].children[1].dispatchEvent(event);
      });

      it('should be called', function() {
        expect(mySpy.callCount).to.equal(1);
      });
    });
  });
});

This example has something important. We saw that unit tests make refactoring easy as pie, but we didn’t see how exactly. Here, we are testing that when a click happens on the button, the function passed as the on-click attribute is called. If we take a closer look at the directive’s code, we will see that this function gets locally renamed to callback. It’s published under this name on the directive’s isolated scope. We could write the following test, then:

describe('click callback', function() {
  var mySpy;

  beforeEach(function() {
    mySpy = sinon.spy();
    innerScope.callback = mySpy;
  });

  describe('when the directive is clicked', function() {
    beforeEach(function() {
      var event = document.createEvent("MouseEvent");
      event.initMouseEvent("click", true, true);
      element[0].children[1].dispatchEvent(event);
    });

    it('should be called', function() {
      expect(mySpy.callCount).to.equal(1);
    });
  });
});

And it would work, too. But then we wouldn’t be testing the external aspect of our directive. If we were to forget to add the proper key to the directive’s scope definition, then no test would stop us. Besides, we actually don’t care whether the directive renames the callback or calls it through another method (and if we do, then it will have to be tested elsewhere anyway).

Providers

This is the toughest of our little series. What is a provider exactly? It’s AngularJS’ own way of wiring things together before the application starts. A provider also has a factory facet — in fact, you probably know the $routeProvider and its little brother, the $route factory. Let’s write our own provider and its factory and then test them!

angular.module('myProviders', [])

.provider('coffeeMaker', function() {
  var useFrenchPress = false;
  this.useFrenchPress = function(value) {
    if (value !== undefined) {
      useFrenchPress  = !!value;
    }

    return useFrenchPress;
  };

  this.$get = function () {
    return {
      brew: function() {
        return useFrenchPress ? 'Le café.': 'A coffee.';
      }
    };
  };
});

There’s nothing fancy in this super-useful provider, which defines a flag and its accessor method. We can see the config part and the factory part (which is returned by the $get method). I won’t go over the provider’s whole implementation and use cases, but I encourage you to look at AngularJS’ official documentation about providers²¹.

To test this provider, we could test the config part on the one hand and the factory part on the other. This wouldn’t be representative of the way a provider is generally used, though. Let’s think about the way that we use providers. First, we do some configuration; then, we use the provider’s factory in some other objects or services. We can see in our coffeeMaker that its behavior depends on the useFrenchPress flag. This is how we will proceed. First, we will set this flag, and then we’ll play with the factory to see whether it behaves accordingly.

describe('coffee maker provider', function() {
  var coffeeProvider = undefined;

  beforeEach(function() {
    // Here we create a fake module just to intercept and store the provider
    // when it's injected, i.e. during the config phase.
    angular.module('dummyModule', function() {})
      .config(['coffeeMakerProvider', function(coffeeMakerProvider) {
        coffeeProvider = coffeeMakerProvider;
      }]);

    module('myProviders', 'dummyModule');

    // This actually triggers the injection into dummyModule
    inject(function(){});
  });

  describe('with french press', function() {
    beforeEach(function() {
      coffeeProvider.useFrenchPress(true);
    });

    it('should remember the value', function() {
      expect(coffeeProvider.useFrenchPress()).to.equal(true);
    });

    it('should make some coffee', inject(function(coffeeMaker) {
      expect(coffeeMaker.brew()).to.equal('Le café.');
    }));
  });

  describe('without french press', function() {
    beforeEach(function() {
      coffeeProvider.useFrenchPress(false);
    });

    it('should remember the value', function() {
      expect(coffeeProvider.useFrenchPress()).to.equal(false);
    });

    it('should make some coffee', inject(function(coffeeMaker) {
      expect(coffeeMaker.brew()).to.equal('A coffee.');
    }));
  });
});

HTTP Requests

HTTP requests are not exactly on the same level as providers or controllers. They are still an essential part of unit testing, though. If you do not have a single HTTP request in your entire app, then you can skip this section, you lucky fellow.

Roughly, HTTP requests act like inputs and outputs at any of your application’s level. In a RESTfully designed system, GET requests give data to the app, and PUT, POST and DELETE methods take some. That is what we want to test, and luckily AngularJS makes that easy.

Let’s take our factory example and add a POST request to it:

angular.module('factories_2', [])
.factory('chimp', ['$http', function($http) {
  return {
    sendMessage: function() {
      $http.post('http://chimps.org/messages', {message: 'Ook.'});
    }
  };
}]);

We obviously do not want to test this on the actual server, nor do we want to monkey-patch the XMLHttpRequest constructor. That is where $httpBackend enters the game.

describe('http', function() {

  beforeEach(module('factories_2'));

  var chimp;
  var $httpBackend;

  beforeEach(inject(function(_chimp_, _$httpBackend_) {
    chimp = _chimp_;
    $httpBackend = _$httpBackend_;
  }));

  describe('when sending a message', function() {
    beforeEach(function() {
      $httpBackend.expectPOST('http://chimps.org/messages', {message: 'Ook.'})
      .respond(200, {message: 'Ook.', id: 0});

      chimp.sendMessage();
      $httpBackend.flush();
    });

    it('should send an HTTP POST request', function() {
      $httpBackend.verifyNoOutstandingExpectation();
      $httpBackend.verifyNoOutstandingRequest();
    });
  });
});

You can see that we’ve defined which calls should be issued to the fake server and how to respond to them before doing anything else. This is useful and enables us to test our app’s response to different requests’ responses (for example, how does the application behave when the login request returns a 404?). This particular example simulates a standard POST response.

The two other lines of the beforeEach block are the function call and a newcomer, $httpBackend.flush(). The fake server does not immediately answer each request; instead, it lets you check any intermediary state that you may have configured. It waits for you to explicitly tell it to respond to any pending request it might have received.

The test itself has two methods calls on the fake server (verifyNoOutstandingExpectation and verifyNoOutstandingRequest). AngularJS’ $httpBackend does not enforce strict equality between what it expects and what it actually receives unless you’ve told it to do so. You can regard these lines as two expectations, one of the number of pending requests and the other of the number of pending expectations.

ngMock Module

The ngMock module²² contains various utilities to help you smooth over JavaScript and AngularJS’ specifics.

$timeout, $log and the Others

Using AngularJS’ injectable dependencies is better than accessing global objects such as console or window. Let’s consider console calls. They are outputs just like HTTP requests and might actually matter if you are implementing an API for which some errors must be logged. To test them, you can either monkey-patch a global object — yikes! — or use AngularJS’ nice injectable.

The $timeout dependency also provides a very convenient flush() method, just like $httpBackend. If we create a factory that provides a way to briefly set a flag to true and then restore it to its original value, then the proper way to test it’s to use $timeout.

angular.module('timeouts', [])

.factory('waiter', ['$timeout', function($timeout) {
  return {
    brieflySetSomethingToTrue: function(target, property) {
      var oldValue = target[property];

      target[property] = true;

      $timeout(function() {
        target[property] = oldValue;
      }, 100);
    }
  };
}]);

And the test will look like this:

describe('timeouts', function() {

  beforeEach(module('timeouts'));

  var waiter;
  var $timeout;

  beforeEach(inject(function(_waiter_, _$timeout_) {
    waiter = _waiter_;
    $timeout = _$timeout_;
  }));

  describe('brieflySetSomethingToTrue method', function() {
    var anyObject;

    beforeEach(function() {
      anyObject = {foo: 42};
      waiter.brieflySetSomethingToTrue(anyObject, 'foo');
    });

    it('should briefly set something to true', function() {
      expect(anyObject.foo).to.equal(true);
      $timeout.flush();
      expect(anyObject.foo).to.equal(42);
    });
  });
});

Notice how we’re checking the intermediary state and then flush()‘ing the timeout.

module() and inject()

The module()²³ and inject()²⁴ functions help to retrieve modules and dependencies during tests. The former enables you to retrieve a module, while the latter creates an instance of $injector, which will resolve references.

it('should say Ook.', inject(function($log) {
  sinon.stub($log, 'warn', function() {});

  chimp.ook();

  expect($log.warn.callCount).to.equal(1);
  expect($log.warn.args[0][0]).to.equal('Ook.');
}));

In this test case, we’re wrapping our test case function in an inject call. This call will create an $injector instance and resolve any dependencies declared in the test case function’s arguments.

Dependency Injection Made Easy

One last trick is to ask for dependencies using underscores around the name of what we are asking for. The point of this is to assign a local variable that has the same name as the dependencies. Indeed, the $injector used in our tests will remove surrounding underscores if any are found. StackOverflow has a comment²⁵ on this.

Conclusion

Unit testing in AngularJS applications follows a fractal design. It tests units of code. It freezes a unit’s behavior by providing a way to automatically check its response to a given input. Note that unit tests do not replace good coding. AngularJS’ documentation is pretty clear on this point: “Angular is written with testability in mind, but it still requires that you do the right thing.”

Getting started with writing unit tests — and coding in test-driven development — is hard. However, the benefits will soon show up if you’re willing to fully test your application, especially during refactoring operations.

Tests also work well with agile methods. User stories are almost tests; they’re just not actual code (although some approaches, such as “design by contract²⁶,” minimize this difference).

Further Resources

“The Pragmatic Programmer: From Journeyman to Master²⁷,” Andrew Hunt and David Thomas

AngularJS’ documentation on unit testing²⁸

All examples can be found in the GitHub repository²⁹

(al, ml)

Footnotes

The post An Introduction To Unit Testing In AngularJS Applications appeared first on Smashing Magazine.

Categories: Others Tags:

Stack: New Kanban Boards Task- and Projectmanager by Bugherd

October 7th, 2014 admin No comments

The makers of the popular bugtracker Bugherd from Australia are back with another solution designed to make the life of all of us working in the design and development industry easier. Their new product listens to the name “Stack” which offers a nice association as to what we can achieve with it. Stack follow the concept of the popular Kanban board systems. The most well-known specimen these days is Trello. The similarities are striking. We have taken a closer look at Stack. Here are the results…

Categories: Others Tags:

The Skeptic’s Guide To Low-Fidelity Prototyping

October 6th, 2014 admin No comments

UX designer Matt Tyas presents a prototype concept.

Designer Paul Rand once said, “An understanding of man’s intrinsic needs, and of the necessity to search for a climate in which those needs could be realized, is fundamental to the education of the designer.” Prototyping helps us to unveil and explore these human needs, opening the door to insightful interaction and more empathetic design solutions.

Low-fidelity prototypes, in particular, are rough representations of concepts that help us to validate those concepts early on in the design process. Throughout this article, we will look at some of the features that make low-fidelity prototyping a unique tool to radically improve your work and to build an environment in which users’ needs can be truly realized.

This article focuses on the practice and general principles behind integrating low-fidelity prototypes in design in general, covering applications that range from graphic, web and user experience (UX) design to business and service design.

What Is Low-Fidelity Prototyping And Why Will It Improve The Way You Work?

Have you ever spent an overwhelming amount of time and resources designing something that a client or user discards in a matter of seconds? I’ve seen it happen far too many times. It is never pleasant, always frustrating, yet often preventable. Designing a product without continual validation is like walking blindfolded over a plank into a sea of sharks. Even Apple, a company that has repeatedly spoken against using focus groups to design products, pioneered a process called the Apple new product process¹ (ANPP), which involves creating and testing hundreds of early prototypes.

Some of us are quick to jump into building (what to us seem like) brilliant products, to the point of pixel perfection, without even stopping to ask whether our user or client feels the same way. The fact is that designing without introducing potential users to raw versions of our ideas is unsafe, uncomfortable and wasteful.

On the other hand, perfection can also haunt some of us to the point of inaction. While some are too quick to act and end up wasting resources, others are completely paralyzed by the “excessive” amount of work behind building something new. There’s just “so much to get done” before delivering the product to the user that we end up feeling frustrated and overwhelmed.

Have you ever overspent resources in a rush or accomplished too little for being a perfectionist? Low-fidelity prototyping helps us to find the middle ground between overspending and overthinking, between too little investment and too much user validation. By building a practical, preliminary version of your product, you will catch potential problems and promising insights faster and earlier in the process.

²

UX designer Matt Tyas presents a prototype concept. (View large version³)

The word “prototype” comes from the Greek prototypos⁴, a compound of protos (“first”) and typos (“mold,” “pattern,” “impression”). This initial, raw presentation of our ideas is precisely what we’ve come to know as low-fidelity prototyping. Unlike high-fidelity prototyping, this method requires less time, specialized skills and resources. Its purpose is not to impress users, but to learn from them. Instead of wowing people with our product, the goal of low-fidelity prototyping is to have users wow us with their insight. In a way, the technique facilitates listening, rather than selling. It opens a conversation in which users’ needs, designers’ intentions and other stakeholders’ goals are discussed and aligned.

Scientist Jim Rudd and his colleagues at IBM helped to define the difference between the two major types of prototypes in a much recommended piece titled “Low vs. High Fidelity Prototyping Debate⁵” in Interactions Magazine:

Low-fidelity prototypes are generally limited function, limited interaction prototyping efforts. They are constructed to depict concepts, design alternatives, and screen layouts… These prototypes are created to communicate, educate, and inform.

“Fidelity” can be a confusing term. In broad terms, it can be defined (according to Oxford Dictionary) as “the degree of exactness with which something is reproduced.” In other words, a prototype’s level of fidelity answers the question, How precisely does this represent the final solution?

Why Now?

Though low-fidelity prototyping has existed for centuries, it has recently become popular with the spread of agile design methodologies, inspired by several movements:

Design thinking advocates for “thinking with your hands” as a way to build empathetic solutions.
Lean startup relies on early validation and the development of a minimum viable product to iterate on.
User-centered design calls for a collaborative design process where users deliver continual feedback based on their reactions to a product’s prototype.

As pointed out, we can’t really say that low-fidelity prototyping is new because people have been laying out concepts on cavern walls since time immemorial. What we can say is that, given the speed with which we are expected to design market-appropriate solutions, low-fidelity prototyping has never been more important to all kinds of designers.

⁶

Designers in companies such as Nintendo use low-fidelity prototyping. Designer Kazuyuki Motoyama explains⁷ that the only way to actually know what a Miiverse would feel like was to hold it. That’s when he built this prototype out of cardboard. (Imag credit: Nintendo⁸)

Advantages

All low-fidelity prototypes, regardless of the type of product being built, bring the following advantages.

Detect and Fix Major Problems Early

Building a low-fidelity prototype that can be quickly exposed to user feedback enables us to visualize and solve core issues related to the product’s usability and proposed functionality. Because the prototype is not supposed to generate insight about the final look and feel of the product (they are rough approximations), users generally submit thoughtful ideas from what they see. By removing the bells and whistles associated with high-fidelity prototypes, we strip our concept down to the core. Addressing whatever problems we detect at this stage is vital to the product’s eventual success.

Consultant Nigel Heaton wrote a key paper titled “What’s Wrong With the User Interface? How Rapid Prototyping Can Help⁹,” presenting it at the 1992 IEE Colloquium on Software Prototyping and Evolutionary Development. He explains that rapid prototyping should be able to solve around 80% of all major interface issues. In the process of designing products that truly match users’ needs, low-fidelity prototyping provides a much-needed wake-up call right from the start.

Aside from helping us to detect major problems, low-fidelity prototyping also gives us the motivation required to fix them. In a 2012 study¹⁰ of the psychological experience of prototyping, researchers at Stanford and Northwestern University found that “the practice of low-fidelity prototyping… led to reframing failure as an opportunity for learning, fostering a sense of forward progress, and strengthening beliefs about creative ability.” The study concluded that building low-fidelity prototyping affects not only the final product, but our level of engagement with the design process itself.

Build Cheaply and Easily

Low-fidelity prototypes can be easily built by individuals and teams with little or no technical skills. As long as the goals of the product and project are clear, then the emphasis with low-fidelity prototyping will be not on form or function, but on focus. Where should we invest our resources next? Where should we avoid investing them? Which features will be key for the user? Are we headed in the right direction with this raw concept? Do we need to pivot towards new models or explore other options?

The best low-fidelity prototypes are built resourcefully, on a small or nonexistent budget and in a short time period. You may also be familiar with the term “rapid prototyping¹¹,” which is merely the practice of “quickly mocking up the future state of a system.” In the spectrum of rapid prototyping, low-fidelity prototypes are on the speedy end.

Draw Feedback That Focuses on High-Level Concepts, Rather Than Execution

In his article “Prototyping for Tiny Fingers⁷⁵¹²,” interaction designer Marc Rettig points to the imminent risk of working with high-fidelity prototypes, which is that you will likely “hear criticisms about your choice of fonts, color combinations, and button sizes.” Being exposed to an elaborate prototype, users might feel compelled to comment on these details and neglect to gather their thoughts on high-level concepts such as user flow, layout and language.

Rather than being focused on validating the product’s underlying assumptions and core value, high-fidelity prototypes redirect attention towards the aesthetics of the product. A rougher low-fidelity prototype, on the other hand, “forces users to think about content rather than appearance.”

Iterate More Willingly

Because the effort and resources required to produce a low-fidelity prototype are significantly less, we are less reluctant to change the prototype completely. Think about it: When has it been easier for you to completely scrap something you’ve been working on? When you’ve invested a few minutes sketching it or when you’ve spent countless hours perfecting a prototype? In Rettig’s words, “Spend enough time crafting something and you are likely to fall in love with it.”

Iteration is key in a truly agile design process. Only by continually evolving our concepts will we be able to create empathetic solutions that will succeed in the current market. Low-fidelity prototypes encourage this type of shameless, stress-free environment of iteration. Making sharp changes, pivoting to a new business model or even starting from scratch feels more natural to us because there is simply not that much to scrap.

Carry and Show Them Easily

While some high-fidelity prototypes require a special device or environment to be shown, most low-fidelity prototypes can be easily carried around and shared. Rudd states, “Low-fidelity prototypes are easily portable — they can be presented on paper, view graphs, or white boards.”

How hard is it to transport a piece of paper? Does it require any special conditions, spaces or advanced instructions? Paper-based low-fidelity prototypes liberate us from the burden of technical and portability requirements.

If you decide to build a low-fidelity prototype using any of the software listed at the end of this article, then reconsider whether showing it on a screen is the best choice. A study showed that paper encourages collaborative work more readily than screens in several interesting ways. Researchers at the University of Nottingham, University of Surrey and Cambridge EuroParc examined how paper and screens foster collaboration¹³ in three different work settings: an architectural practice, a medical center and the control room in London’s underground railway. They concluded that paper generates an added flexibility that enables individuals to interact and collaborate in a wide range of ways.

The researchers noticed, among other things, that by handwriting (i.e. drawing, writing or sketching low-fidelity prototypes), participants were able to take notes quickly, while remaining engaged with subjects. This flexibility is particularly important when designing collaboratively and communicating with users to obtain feedback. The natural versatility of paper (it can be folded, cut, scribbled on) also made cooperation significantly easier. Consider these advantages when you decide to expose users to a low-fidelity prototype. Printing out your screenshots or wireframes could radically change the input that you receive.

Types

Paper-Based 2D

It doesn’t get any simpler than a plain old sheet of paper. Marc Rettig estimates that paper-based prototyping frees designers to spend 95% of their time thinking about the design itself and to spend only 5% on technical issues (which he calls the “mechanics of the tool”). Reflect on your own experience: How many times has your attention diverted from the essential elements of design to the technicalities of a tool?

In web design, for instance, paper-based low-fidelity prototypes can include screenshots of interface elements. In his article “Using Paper Prototypes in Home Page Design¹⁴,” former Sunsoft engineer Jakob Nielsen suggests that “Pop-up menus, messages, and dialog boxes can be simulated with Post-it stickers, or transparent overlays printed on overhead foils.” Sunsoft’s experience with redesigning its home page revealed that primitive, rough prototypes are valuable sources of insight into usability.

This low-fidelity prototype of a new web design for SCAD's Interaction Design department shows the initial concepts for improving reading and posting interactions. — This low-fidelity prototype of a new web design for SCAD’s Interaction Design department¹⁶ shows the initial concepts for improving reading and posting interactions. (View large version¹⁷)

The team at Flow New Media Design shows how it starts with paper-based prototypes to “strip things back to the bare bones [and] concentrate on the important things.” — The team at Flow New Media Design shows how it starts with paper-based prototypes¹⁹ to “strip things back to the bare bones [and] concentrate on the important things.” (View large version²⁰)

Two interaction design students launched a company named Sticky Jots, which offers kits to help anyone get started with low-fidelity paper-based prototypes, such as storyboards. — Two interaction design students launched a company named Sticky Jots²², which offers kits to help anyone get started with low-fidelity paper-based prototypes, such as storyboards. (View large version²³)

3D

If you want to get more creative and provide users with a 3D prototype to interact with, several fascinating options are available. Using cardboard, foam, wood, plastic, clay and building blocks has become increasingly popular, especially with the spread of design thinking’s hands-on approach.

3D prototypes add a level of interaction that 2D prototypes do not achieve. While building it might take slightly longer, a 3D prototype encourages manipulation and could draw a higher level of engagement in the concept-testing phase. The three-dimensional nature will add realism and open the door to valuable feedback.

Ashley Costanzo developed this 3D low-fidelity prototype for HealthyMade: fresh ingredients and recipes packaged into a healthy preplanned meal. — Ashley Costanzo developed this 3D low-fidelity prototype for HealthyMade²⁵: fresh ingredients and recipes packaged into a healthy preplanned meal. This product answers the question, “How might we provide healthier food options to people in need?” (View large version²⁶)

Business origami is a paper prototyping method developed by Hitachi to facilitate the design of services and systems. It was developed in-house but eventually attracted the attention of other organizations. The paper cut-outs of various objects improve prototyping systems and interactions with them.

LEGO Serious Playwas created to facilitate innovation and business performance. — LEGO Serious Play²⁸ was created to facilitate innovation and business performance. The sets can be used to build low-fidelity prototypes of business and service experiences. Liquid Agency, for instance, used this method²⁹ to prototype an answer to the question, “What type of health care do we aspire to offer that would make a difference today and tomorrow?” (View large version³⁰)

Quick Start Guide

1. Define Your Goals: What Will You Show?

Which main features do you want to expose your users to? List two to three pieces of core functionality that you will include in the low-fidelity prototype. In the next step, we will make sure that these aren’t left out.

You can use a simple table like the one below to list your features:

Core features	Complementary features

Here are some sample features that you might include as either core or complementary:

Sample features to prototype in graphic, web and UX design	Sample features to prototype in business and service design
Geolocation Branch finder Contact form Blog roll Instant quote generator Image uploading Feedback system Color customization Social media integration Analytics Gamification Task manager PDF exporting Web conferencing Directory	Collaboration spaces Retail experience Sales pitch Price list and payment plans Customer support Consulting appointments Delivery Subscription payments Reward points Special packaging Business model Content generation Brand personality No-hassle contracts Returns policy

Business model canvas. (Image credit: Aberdeen Global Service Jam³²) (View large version³³)

Concept development and sketches for flower seed packaging. (Image credit: Shavonne Maclin³⁵) (View large version³⁶)

2. Define the Method: How Will You Show It?

Decide what kind of low-fidelity prototype would suit your project best. What could you build quickly that would help users to deliver valuable feedback? How could you display and test the concept simply, investing the least amount of resources? To find the simplest method possible, continue asking the question, “Is there a simpler way to show this?” until you arrive at a feasible way to depict the product’s features.

The level of detail that is right for your prototype will depend on a few factors:

What type of user will be exposed to this prototype?
Would they be able to deliver insightful feedback based on the model that you are presenting? Would they need to see a certain level of detail in order to understand the concept?
What resources are accessible to you?
With low-fidelity prototyping, agility is crucial. Think of the tools and resources that surround you as you ideate. Be resourceful and find clever ways to use what you have.

Think about it in this way:

What I want to show	Is there a simpler way to show this?	Is there a simpler way to show this?	Is there a simpler way to show this?
Inputting a QR code	³⁷ (View large version³⁸)	³⁹ (View large version⁴⁰)	⁴¹ (View large version⁴²)
Geolocation feature (for browsing nearby)	⁴³ (View large version⁴⁴)	⁴⁵ (View large version⁴⁶)	⁴⁷ (View large version⁴⁸)

Note: The prototypes above show the evolution of the design of the payment screen in Foursquare⁴⁹‘s existing app and were designed by Marta Fioni.

Still struggling to find a method that suits your project? Here are some ideas:

Download this graphic and hang it somewhere visible in your office. It will keep you motivated to make low-fidelity prototyping a consistent part of your design process. (View large version⁵¹)

3. Execute: Show It

Start out by defeating your “My skill in [x] isn’t good enough” mindset. Low-fidelity prototyping is not about how sophisticated your model looks, but about the conversation it generates about the future of the product. Remember, not form or function, but focus.

Sample Low-Fidelity Prototypes From Different Design Fields

Graphic, web and UX design	Business and service design
user flow sketch board wireframe sketches mood board	sample brochure landing page flyers business cards sample ad scenarios storyboard 3D model explainer video business model canvas

Try any of the following digital and analog tools to speed up your prototyping process:

	Graphic, web and UX design	Business and service design
Digital	Mockup.io⁵² POP⁵³ (import paper designs) Flinto⁵⁴ Solidify⁵⁵ InVision⁵⁶ Proto.io⁵⁷ Balsamiq⁵⁸ Moqups⁵⁹	Cacoo⁶⁰ Mural.ly⁶¹ Canvanizer’s business model canvas⁶² Business Model Fiddle⁶³ Stickies.io⁶⁴ ProcessOn⁶⁵ Conceptboard⁶⁶
Analog	paper whiteboard poster sticky notes sketchbook notebook napkin squared paper print template cards overhead sheet cardboard carton plastic wood pieces plastic pieces glue scissors markers foam pieces UI stencil	paper whiteboard poster sticky notes sketchbook notebook napkin squared paper print template cards overhead sheet cardboard carton plastic wood pieces plastic pieces glue scissors markers foam pieces

4. Test: How Will You Evaluate What You’re Showing?

Go beyond the idea that “It’s so rough-looking that users will hate it.” Having to explain the limitations of your low-fidelity prototype is normal. In fact, it is expected. Guide users to understand the aims of the project, and ask probing questions. If it helps, prepare a short guide before you present the prototype. List a few of the questions that you’d like to be answered during the session, and write an introduction that you could read out loud to help the user contextualize what they are looking at. These are some of the types of questions you will want to ask:

Regarding perceived benefits
“What, in your opinion, is the key benefit offered by this product concept?” “From the features you have seen today, which ones would make you use the product?” “Which features didn’t you see that would make you want to use it?”
Regarding positive and negative reactions
“On a scale of one to five, how much do you like this concept?” “Why?”
Regarding awareness
“Having looked at this concept today, what do you remember most about it?” “What do you recall?”
Regarding comparative advantage
(If you showed users two or more versions of a concept, ask which variant works best.) “Which of these options appeals to you the most?”
Regarding emotional reactions
“How did looking at this concept make you feel?” (Help them by providing a list of emotions — happy, frustrated, angry, excited, bored, etc. — or face illustrations that depict these emotions. Have each user select one or more emotions triggered by the prototype.)
Regarding intention of use
“Having looked at this product concept today, on a scale of one to five, how much would you be willing to use it once it has been refined and launched?” “Why?”
General feedback
“Feel free to annotate any changes or corrections that you feel would improve this concept.”

5. Learn: We’ve Shown. Now What?

Collect your users’ feedback and find similarities in their evaluations of the concept. Build an affinity diagram⁶⁷ to identify the most common suggestions. Incorporate their feedback, and move on to building a high-fidelity prototype that reflects the product’s look and feel with a greater level of detail. Repeat the testing session with as many users as needed.

Conclusion

Hopefully, this article has helped you understand the impact that low-fidelity prototypes can have on our design processes and outcomes. The five steps outlined above are meant to guide you through the process of building and testing a low-fidelity prototype, and they will surely improve the quality and depth of your design work. Think about the concepts that you are currently working on: How could you validate them before investing an overwhelming amount of time and effort into polishing them? It isn’t always easy to see that a raw representation of what you are building might just be the right amount of fidelity needed to ask the most crucial questions about its effectiveness. When in doubt about whether you’re ready to test an early concept, always keep author Elizabeth Gilbert’s words close to heart:

Part of the elasticity that you need, in order to continue to try to create, is the foregone conclusion that not all of it is going to be fabulously successful. But it’s all going to be part of a long lifetime body of experimentation.

Other Resources

“50 Free UI and Web Design Wireframing Kits, Resources and Source Files⁶⁸,” Paul Andrew
“Free Printable Sketching, Wireframing and Note-Taking PDF Templates⁶⁹,” Paul Andrew
“Design Better and Faster With Rapid Prototyping⁷⁰,” Lyndon Cerejo

References

“The Psychological Experience of Prototyping⁷¹” (PDF), Elizabeth Gerber and Maureen Carroll, Design Studies, 33:1 (2012), pages 64–84
“Tasks-in-Interaction: Paper and Screen Based Documentation in Collaborative Activity⁷²,” Paul Luff, Christian Heath and David Greatbatch, Proceedings of the 1992 ACM Conference on Computer-Supported Cooperative Work, (New York, NY), pages 163–170
“Chapter 10: People and Prototypes,” Bill Moggridge, Designing Interactions⁷³, Cambridge, MA: MIT Press (2007), pages 682–723
“Using Paper Prototypes in Home-Page Design⁷⁴,” Jakob Nielsen, IEEE Software, 12:4 (1995), pages 88–89,97
“Prototyping for Tiny Fingers⁷⁵¹²,” Marc Rettig, Communications of the ACM, 37:4 (1994), pages 21–27
“Low vs. High-Fidelity Prototyping Debate⁷⁶,” James Rudd, Interactions, 3:1 (1996), pages 76–85

(ah, il, al, ml)

Footnotes

The post The Skeptic’s Guide To Low-Fidelity Prototyping appeared first on Smashing Magazine.

Categories: Others Tags:

24+ Best Apps for Graphic Design Freelancers

October 6th, 2014 admin No comments

One of the best ways to improve your workflow and time management as a graphic design freelancer is to use apps. Not just any app will do, however. You need ones that won’t waste your time by crashing and that help you both on the go and when around your computer. Our collection of the best apps for graphic design freelancers below are divided into design and photography apps and business management apps. As a graphic designer, you never know when inspiration might hit, which is why you want something in place to record your idea before you lose it. And we all hate the annoying business tasks, especially when they take too much time away from designing. The apps below should help solve both of these problems that can occur for graphic design freelancers.

Categories: Others Tags:

Archive

What Are Blueprints (And Why Are They Blue)?

From Bricks To Bits And Bytes

A Picture (And Some Numbers) Are Worth More Than A Thousand Words

Developer Focus

A Carnival Of Errors: Developer Edition

The Triumph Of Tediousness: Designer Edition

Let’s Create (And Use) Design Specs

Components And Style Guides

Conclusion

Further Reading

Footnotes

More from Vecteezy

More from Vecteezy

Why Sliders?

Types Of Sliders

Experimental Slider Patterns

Caution

Make Sure Reasonable Values Can Be Entered Easily

Show the Range

Don’t Cover the Numbers

Opt for a Slider With Discrete Positions

Super-Sliders Save The Day

Regular Slider

Super-Slider (With Zero-Results-Fighting Histogram)

No Room for a Histogram?

Tablet Apps

Try It Out

Code

Conclusion

Footnotes

A Word About Unit Testing

What and What Not to Test

Bootstrapping A Test Environment For AngularJS

Karma: The Spectacular Test Runner

Mocha

Chai

Sinon

Unit Testing At The Application Level

Unit Testing At The Module Level

Filters, Services and Factories: A Story of Dependency Injection

Controllers

Directives

Providers

HTTP Requests

ngMock Module

$timeout, $log and the Others

module() and inject()

Dependency Injection Made Easy

Conclusion

Further Resources “The Pragmatic Programmer: From Journeyman to Master27,” Andrew Hunt and David Thomas AngularJS’ documentation on unit testing28 All examples can be found in the GitHub repository29

Footnotes

What Is Low-Fidelity Prototyping And Why Will It Improve The Way You Work?

Why Now?

Advantages

Detect and Fix Major Problems Early

Build Cheaply and Easily

Draw Feedback That Focuses on High-Level Concepts, Rather Than Execution

Iterate More Willingly

Carry and Show Them Easily

Types

Paper-Based 2D

3D

Quick Start Guide

1. Define Your Goals: What Will You Show?

2. Define the Method: How Will You Show It?

3. Execute: Show It

Sample Low-Fidelity Prototypes From Different Design Fields

4. Test: How Will You Evaluate What You’re Showing?

5. Learn: We’ve Shown. Now What?

Conclusion

Other Resources

References

Footnotes

Categories

Blogroll

Archives

Meta

Further Resources

“The Pragmatic Programmer: From Journeyman to Master²⁷,” Andrew Hunt and David Thomas

AngularJS’ documentation on unit testing²⁸

All examples can be found in the GitHub repository²⁹