Webmasters Gallery

Smartphones are widely used in everyday life. More and more people turn to them to create content, shoot pictures, share news via social media, leave checkpoints, entertain themselves, learn something new across the internet. To cut a long story short, the list of features and possibilities of these small pocket-size devices are increasing day by day. An affection that has already turned into addiction a long time ago.

When the iPhone came out in 2007, the demonstration of its web browser by the late great Steve Jobs gave the not-so-subtle impression that Apple wasn’t too perturbed about its users pinching to zoom and swiping to scroll as part of the browsing experience. Responsive web design aimed to solve this problem by smartly applying flexible grids, fluid layouts and, of course, media queries.

However, responsive web design has turned out to be somewhat of a case study in the law of unintended consequences, with one of the perverse unanticipated effects being breakpoint paranoia. But even without the undue influence that media queries exerts on your selection of these breakpoints, it dawns on you after much introspection that these might not be the droids we’re looking for.

In this article, we’ll look at breakpoints beyond screen size and explore different possibilities and practical approaches to using them to create truly adaptive experiences on the web.

Threshold Dynamics

A threshold¹ is the point or level at which something begins or changes. Thresholds can be found and felt virtually everywhere in the physical world: stopping at a traffic light, choosing skimmed milk over full cream, two sugars instead of three, uncouthly opting out of the teacup ride at Disney World, etc.

Thresholds define us because they define actions, and actions determine outcomes. Being able to identify the right thresholds sets you on a course for better outcomes, especially when you know exactly what needs to be done within each threshold. It’s akin to doing the right thing at the right time.

Our foresight to conceptualize — and enable — new thresholds where there were none will open up a new vista of actions vis-à-vis outcomes. The freedom and flexibility we acquire from this will only help to fulfill our innate desire for incremental awesomization, which will drive us to create even better websites that provide better user experiences.

Today’s Breakpoints

In web design today, the thresholds we fixate on the most relate almost exclusively to screen size. The major challenge over the last few years has been designing for mobile devices, and, with screen size being the obvious focal point, our primary intent has been to adapt the layout of our web pages to tally with the specific display characteristics of the target environment.

In responsive web design, the predominant method of defining these breakpoints is by setting media queries.

@media screen and (min-width: 240px) and (max-width: 320px){
   body { background: red; }
}

The markup above clearly identifies two thresholds (240 pixels and 320 pixels) that constitute a range within which an action will be triggered (in this case, changing the background color to red). It’s quite straightforward in concept.

Medusa Queries

“As we augment the abilities of people to accomplish their tasks, we should be careful not to needlessly curtail what they can do.”

– Jeremy Keith

Media queries, it turns out, are extremely rigid. Usually, you are forced to employ breakpoints in ways that are not exactly intuitive nor inline with your core design aspiration. In other words, you have to fit your design aspiration to its capabilities. So, you may have a vibrant imagination about your own thresholds, but more than likely media queries won’t let you apply them the way you envisage.

Defenders of media queries should understand that efficiency is what makes any effective effort laudable. Spending many minutes or even hours tweaking those pesky directives and then having to re-tweak them each and every time you want to make an adjustment is nothing short of a recursive nightmare. What’s so wrong with setting breakpoints based on broad categorizations of mobile devices (such as smartphone, tablet, etc.)?!

In the article “Designing for Breakpoints²,” Stephen Hay suggests defining breakpoints based on device classes. Spurred by a few assertions, I embarked on a mini-research project that I later converted into a blog post³ to prove this right or wrong. And in a recent poll that I conducted on whether media queries should target device classes⁴, about 54% of respondents said yes. But there’s no intuitive way to do this with media queries even if you wanted to.

In my humble opinion, from the web designer’s standpoint, the feature set of media queries is incomplete. And it is so because designers have an imagination and an appetite for many more breakpoints than media queries can currently provide (and probably ever will in future).

The New Breakpoints

As mentioned a little earlier, our ability to find and set new thresholds will determine our ability to conceptualize new actions that we can set a trigger to. By so doing, we can introduce more tweaks into an inherently static and inflexible environment.

Breakpoints in Contextual Web Design

The websites of tomorrow have to be more than responsive — they have to be contextual, too. These concepts of flexibility and fluidity have to transcend screen size. The age of the one-size-fits-all website will have to come to an end and be replaced by websites that also adapt to the needs and expectations of users.

To enable this feature, we have to conceptualize more thresholds, but first we need to find out what parameters to track. In Nick Finck’s insightful presentation on “The Contextual Web⁵,” he highlights four aspects of context in web design: user, task, environment and technology. Of course, all four are a treasure trove of extrapolations, but what should we really focus on?

We could ask literally hundreds, even thousands, of questions about users, their tasks, their environment and what technology they have access to. However, we have to base these questions on our current and overt abilities to obtain data on these four parameters. Some possible questions could be:

• What are the physical abilities of the user?
  If the user is vision-impaired or hearing-impaired, we would need to add more accessibility features that would enhance their experience.
• Where is the user’s general location?
  Knowing where the user is gives us a good idea of their culture, economic status, demographic, etc.
• What time is it in the user’s location?
  People are usually creatures of habit and are probably more likely to perform certain actions at a certain time.
• What is the user’s device?
  A phone is not a tablet, and a tablet is not a PC. Different devices have different capabilities and will be used for different tasks.
• What does the user have an affinity for?
  What the user likes (and dislikes) will play a strong part in helping us to prioritize and deliver content.

There are ways to answer the questions above with the technology available in browsers today. And if not, then we really need to work harder to build them in, especially considering an issue as important as accessibility.

So, how would we design a website to be contextual? How would we visualize breakpoints in a contextual sense? Here’s one scenario.

Let’s suppose that it’s 6:00 in the morning, and your alarm goes off. You hobble to your kitchen to get some breakfast, before getting ready and heading out to work. You fancy eggs, but you open the fridge and there are no eggs. So, you settle on something else, but you want to order some groceries so that they’re ready to be picked up on your way back from work. You fire up the website of an extremely large department store chain from your Internet-connected refrigerator to get this done.

Are you impressed simply because this website is responsive? Is getting the best deal on electronics a priority for you at this point? Do you really want to be reminded that some of the few items you “recently viewed” on said website were Lincoln Logs and a Spider-Man toothbrush holder? I mean, it’s 6:18 am, and you’re browsing from a fridge. Does it take a rocket scientist to figure out that maybe grocery items should be a category worth prioritizing?!

I’m sure there are numerous other scenarios like this, and it’s easy for someone who isn’t familiar with web technology to get frustrated with how websites still seem to fall short of their expectations. But for those of us who do, should we still be making excuses, or should we be trying to push the envelope further?

The New Methods

“Media queries allow authors to test and query values or features of the user agent or display device, independent of the document being rendered.”

– Editor’s Draft, W3C (3 June 2014)

I was recently perusing the “Media Queries Level 4⁶” draft specification to get a sense of where things are headed. I must say that I’m not very excited with the direction, and there just doesn’t seem to be much innovation here.

From the abstract of the document, we get a clear definition of what media queries are as a method. However, I just can’t understand why there is no evolution of media features to reflect present — and possible future — realities.

What’s wrong with having device-class media features like phone or tablet? They seem like obvious choices, and, according to the poll referred to earlier, web designers want that feature set. Some would argue that those might not be “things” in the future, but that is hardly believable, given that cars, TVs, computers, refrigerators, watches and spectacles are still “things” that people find useful today. And when are we really going to see a resolution to the question of element queries⁷?

In my opinion, media queries (as a tool for web design in a multi-device world) simply can’t maintain any sort of equilibrium with the creative trajectory of contemporary web designers, and they are a morally indefensible standard for web design going forward. Maybe we should look at alternative approaches; I’d like to suggest a few. They’re not that complicated, and all we’d need are a HAT, a COAT and a TIE.

HAT Trick

We’re probably all familiar with CSS class selectors at this point. They are one of the most commonly used selectors in web design⁸.

.muttley .do_something {…}

What I don’t understand is why we don’t use these classes more than media queries to build mobile-friendly websites?

It seems to me that designing websites for many different situations would be so much easier and faster if browsers employed HTML attribute tagging (HAT). Basically, this would involve the browser placing specific parameters in the class attribute of the tag (in the process of the page being loaded), which would enable the web designer to leverage these classes in their CSS markup.

Some of these parameters could include the following:

• device group
  fixed, mobile, home, wear, auto, etc.
• device class
  PC, phone, tablet, TV, fridge, car, watch, etc.
• input device
  coarse, fine
• bandwidth
  high, medium, low
• orientation
  portrait, landscape
• viewport width and height
  in device-independent pixels, to the nearest multiple of 40, with an alphabet prefix for compliance
• local date and time
  in ddmmyyyy format for date, and 24-hour representation for time
• time zone
  UTC offset⁹
• general geo-location
  continent and country codes

More parameters could be added based on anticipated need. In addition, all parameters would be abstracted to the DOM window object to make them easily accessible via JavaScript.

So, suppose someone was using a Nexus 5 phone over a 4G LTE mobile network. The browser would add the relevant tags to the page, leaving us with this:

<html class="mobile phone coarse high portrait v360w v640h d07052014 t0900 utc_a af_ng">

And if they changed the phone’s orientation to landscape, the browser would statefully update the tag, giving us this:

<html class="mobile phone coarse high landscape v640w v360h d07052014 t0900 utc_a af_ng">

If this happened, the web designer would have a lot of options to quickly adapt their web pages across numerous logical breakpoints at literally the speed of thought. Let’s consider one working example.

I was recently testing a pricing table¹⁰ that is not unlike tables seen on a lot of SaaS websites these days. The table is three columns and is built using ul tags with floated li tags.

Below the pricing table is some FAQ content, also with a multi-column layout.

Obviously, these multi-column elements would not look as good on all mobile devices as they would on a desktop. So, in the spirit of responsive web design, we would have to adapt them to the dimensions of a smaller screen. And the way we would do this is by showing these two visual components in their full multi-column glory only when the web page is being viewed on a tablet in landscape orientation.

The logic behind this is that we would expect a tablet in that orientation to have enough screen space for the whole table to appear as intended. If those conditions are not met, then we’ll collapse the columns to be linear and vertical.

The basic CSS for our pricing table is this:

ul {
   margin: 0;
   padding: 0;
   list-style: none; }

ul li {
   float: left;
   width: 33%; }

So, leveraging HAT, we would implement these features using the following markup:

.mobile ul li {
   float: none;
   width: 100%; }

.mobile.tablet.landscape ul li {
   float: left;
   width: 33%;}

That’s it! Just disable the floated layout elements for all mobile devices, and then re-enable them for tablets in landscape orientation. Simple aspiration, simple solution. Do you want to try doing the same thing with media queries? Say hello to Dr. StackOverflow for me!

Clearly, employing this approach has benefits. Efficiency is one major benefit; you’d spend less time building websites because you wouldn’t be wasting ridiculous amounts of time crafting media queries, not to mention all of the testing of mobile devices that goes along with that. Secondly, maintaining your markup would be easier because everything would be inline and there would be no needless duplication. Thirdly, you would have the opportunity to explore many more use cases because there would be more parameters that serve as thresholds for more logical breakpoints.

COAT of Many Colors

Everyone seems to be fascinated by analytics. Website analytics programs, such as Google Analytics and MixPanel, all try to give a good picture of who has visited your website, how long they stayed, what websites they came from, what devices they used, etc. What this data won’t tell you is what content the visitors have an affinity for.

You could, of course, use cookies to track visitors to your website, but then you’d only be able to determine what they like on your website that day or week or month. You wouldn’t be able to accurately determine the specific content they care about, nor might you be able to do anything about it before they leave.

Tracking content affinity and adapting content to said affinity could really help us build websites that truly adapt to people’s desires. To really obtain this data, though, the data-collection mechanism needs to transcend any one website. That is, all websites would need to build this affinity profile in a collaborative and transparent way.

COAT stands for “cumulative and open affinity tagging.” It’s simply a shared method of understanding the things visitors have an affinity for and then building a profile of that affinity. Here’s how it would work:

• Someone visits a bunch of websites regularly. Some are news websites, some are sports websites and some are blogs. Each web page would have a COAT meta tag.
• The browser (via a COAT sub-engine) would read this meta tag and incrementally store its value in a reserved, protected and read-only localStorage variable (which could be named anything) in a comma-delimited format. So, for the websites that our user visits, the value might be news:info:1,sports:soccer:2,blog:tech:3.
• If the person visits another sports-related website, the website would read (and update) their affinity tag from localStorage. It sees that the person is amenable to football, and so gives more priority to football content on the home page.

Armed with this insight, we could tweak a website’s home page to better cater to the different needs of users in a highly specialized way.

COAT data would comprise a single comma-delimited string in the following format:

{category_1}:{sub_category_1}:{popularity_1},…,{category_n}:{sub_category_n}:{popularity_n}

Here, category is the broad classification of a type of content; sub_category enables further classification; and popularity is a measure of the frequency of visits. So, if our user visited a tech blog 30 times a month and visited the football section of a sports website 5 times a day, then we would end up with this tag:

blog:tech:30,sports:soccer:150

This is merely an example; the classification system would be defined and maintained by the greater web community. A number of safeguards would be in place, too. For example, if a website didn’t define a COAT meta tag, then it wouldn’t be able to read one either. Also, if the user was browsing in private mode, then COAT would be disabled.

COAT wouldn’t track any personal information. The intent is not to figure out who a person is and where they might be, but to get a broad picture of the kind of content they like (and how much they like it), so that websites are able to personalize their browsing experience.

TIE In

Let’s face the fact: JavaScript is awesome. It’s not very approachable to most web designers, but its capabilities are simply immense, and it holds the key to websites doing great things in the future, even as its contribution to website functionality today is not in question.

HTML and CSS are a great duo for building websites, having been so for quite a while now. However, only HTML seems to have been allowed to maintain a relationship with JavaScript. Granted, CSS is “a style sheet language used for describing the look and formatting of a document.” But as things stand today in a world dominated by web-enabled devices, a lot of the factors that determine the look and feel of a website have gone beyond the realm of CSS.

As a result, CSS needs to be allowed to “friend” JavaScript and ask for its help in performing certain tasks. There really should be a way to link Javascript functionality directly with inline CSS rules. One way would be via transcendent inline expressions (TIE). TIE would provide a mechanism of linking CSS rules with JavaScript expressions, opening up even more amazing opportunities for website functionality.

Let’s look at a simple example. Suppose we had a testimonials component in the sidebar of our home page:

¹⁷

We want to drop this same component into the main content area of another page, somewhere where we have more width to work with:

²⁰

This is called modular design, and conceptually it’s a very simple idea. However, we’d have a pretty hard time implementing this in CSS (as Ian Storm Taylor found²³), because there isn’t a straightforward way to apply CSS styles to the testimonials component based on the size of its container.

This scenario is what has sparked the clamor for element queries, the overriding need being a way to define reusable modules that adapt to the size of their containers. If CSS natively implemented some sort of TIE functionality, then we might be able to write a simple expression in CSS to make this happen:

.testimonial { … }
.testimonial[expr="if @parent:width less than 200px"] { … }
.testimonial[expr="if @parent:width between 200px and 500px"] { … }

For the first ruleset, we would style .testimonial as usual. For the second ruleset, the expression could mean that, when the width of the parent element of .testimonial is less than or equal to 200 pixels, then apply the corresponding declarations to that DOM element (i.e. the parent element). The same goes for the third ruleset, whereby the declarations are applied when the parent element has a width of 201 pixels to 500 pixels.

Basically, CSS would merely provide guidance on what to do, while JavaScript would do the heavy lifting that CSS isn’t well suited for. Instead of writing the CSS rulesets for styles and then jumping over to JavaScript to activate them, we would simply do both via an expression in CSS. Because we’re working on the same DOM element, it makes sense for there to be some easy and intuitive way to both style and activate it (i.e. the DOM element) directly from CSS.

Any such TIE implementation should be robust enough to enable web designers to implement features at virtually the speed of their creativity. In other words, if they can imagine it, designers should be able to achieve it — or something close to it — almost instantaneously.

Putting It All Together

Let’s consider a scenario that shows how all three would fit together when building a website.

By the time you read this, the World Cup will be on, and football fans from around the world will have gathered in Brazil to experience the thrills of the Copa Mundial. Let’s assume you are one of those fans and are in Sao Paolo, having brought your smartphone and Google Glass with you.

A popular online sports destination that happens to be covering the event would usually blanket its website with World Cup features at the expense of other sports events going on elsewhere in the world. The website will employ the three methodologies explained earlier in order to deliver a very special user experience.

After building various content components, the website’s developers should be able to do a few things without much stress:

• Optimize the website exclusively for Google Glass, providing a simpler, slimmer interface for easier navigation. In addition, adapt the color contrast to the time of the day (i.e. switching to light text on a dark background at night), using the device-class parameters of HAT.
• Provide more content on local attractions in different cities in Brazil (for example sports bars, other viewing centers, etc.) only if the access device is a smartphone or tablet and happens to be in Brazil (using the location parameters of HAT).
• Lead with pre-game analysis, team and player profiles, and merchandise if the user visits the website within six hours of an upcoming match (using the time parameters of HAT in combination with TIE).
• Lead with match highlights and post-game analysis if the user visits the website within 12 hours after a match ends. Provide different layout designs for match highlights on smartphones and tablets using the same code base (using the device-class parameters in HAT).
• Lead with golf features in a more prominent location than football if we determine (via COAT) that the user likes the former more than the latter. But still display match highlights in a sidebar with a narrower pixel width (styled in a modular fashion using the TIE features in CSS).
• Default to the regular format of content if we can’t determine whether the user prefers football or another sport.

As you can see, the permutations and opportunities of a highly personalized and carefully weighted user experience are abundant and easily implementable if all three methodologies are considered. We wouldn’t necessarily have to use them all, but it’s nice knowing that they’re there if we wanted to.

The Polyfill Way

“You can’t always get what you want. But if you try sometimes, you just might find, you get what you need.”

– The Rolling Stones

Where would the web design community be without polyfills? Even the best-intentioned technology doesn’t always work as intended, and sometimes it has gaps in functionality. “Just chill and polyfill” would be the operative mantra in these situations, and the last few years have indeed been a veritable polyfill-palooza²⁴.

All of the features outlined so far in this article are merely ideas and are not earmarked in any upcoming draft specifications of CSS or media queries, so you couldn’t use them right now even if you wanted to. However, that doesn’t mean we can’t do something about it in the meantime.

Restive.JS

I mentioned earlier that I was using a plugin to build a website. Well, that would be Restive.JS²⁵, a jQuery plugin that I developed about a year ago that embraces and implements the HAT principle. Using built-in options of breakpoints, classes and a special feature named turbo_classes, Restive.JS populates your or tag class attributes with values that make it easy for you to adapt a web page’s layout via inline CSS to more natural design cues.

Once you get the basic idea, using it to build new responsive and adaptive websites is pretty easy, as is adding said features to existing websites. I recently wrote a tutorial on “How to Make Any Website Responsive²⁶,” which you can peruse at your leisure.

You can also learn more via Restive.JS’ documentation²⁷ and from the GitHub readme²⁸.

A Note on Tolerance

As creative and technical professionals, we need to be open to other people’s opinion. Often a crowd will move towards a position simply because of punditocratic consensus, without pausing to question the fundamental reasoning behind it.

Take device detection. Some say it’s a bad practice. My question is why? Is it because it is deemed unreliable? We can make it reliable. Is there a fear that it is not performant? Then we can cache data. Solving big problems should be an inclusive effort, and using the process of elimination to rule out methods could come back to bite us if someone is able to improve on that method.

Creativity is an insatiable hacker. As long as imagination continues to spur the industrious, then the best tools and methods will eventually give way to better ones. Maintaining a clear and tight focus on the task at hand — and its successful completion — shouldn’t prevent us from being robust with our toolset. As the great Abraham Maslow said, “If all you have is a hammer, everything looks like a nail.”

In Closing (But Moving Forward)

More of everything isn’t necessarily a good thing. But, when it comes to breakpoints, “the more the merrier” does ring true. As humans, we take actions based on specific triggers between specific thresholds. Defining more of these thresholds would open up opportunities to create websites that adapt in so many ways beyond screen size, and that exploration will turn out to be instructive.

However, as we open up new frontiers with new breakpoints, we should do so in a way that is both user-friendly and efficient for the web designer; the robustness of our methods shouldn’t make us less nimble. With the way web standards work, we’re probably going to have to polyfill our way to the promised land. But that shouldn’t stop us from building awesome websites that work on every device and in numerous user scenarios.

Front page image credits: Restive Blog²⁹.

(al, ml)

Footnotes

1. 1 http://www.merriam-webster.com/dictionary/threshold
2. 2 http://alistapart.com/article/designing-for-breakpoints
3. 3 http://blog.restive.io/posts/8460953/device-classes-as-breakpoints
4. 4 http://polarb.com/176083
5. 5 http://www.slideshare.net/nickf/contextual-web
6. 6 http://dev.w3.org/csswg/mediaqueries4/
7. 7 http://www.smashingmagazine.com/2013/06/25/media-queries-are-not-the-answer-element-query-polyfill/
8. 8 http://ejohn.org/blog/selectors-that-people-actually-use/
9. 9 http://en.wikipedia.org/wiki/List_of_time_zones_by_UTC_offset
10. 10 http://restivejs.com/sandbox/pricing-table.html
11. 11 http://www.smashingmagazine.com/wp-content/uploads/2014/06/01-pricing-table-opt.jpg
12. 12 http://restivejs.com/sandbox/pricing-table.html
13. 13 http://www.smashingmagazine.com/wp-content/uploads/2014/06/01-pricing-table-opt.jpg
14. 14 http://www.smashingmagazine.com/wp-content/uploads/2014/06/02-faq-content-opt.jpg
15. 15 http://restivejs.com/sandbox/pricing-table.html
16. 16 http://www.smashingmagazine.com/wp-content/uploads/2014/06/02-faq-content-opt.jpg
17. 17 http://www.smashingmagazine.com/wp-content/uploads/2014/06/03-testimonial-content-opt.jpg
18. 18 http://ianstormtaylor.com/posts/media-queries-are-a-hack/signup.jpg
19. 19 http://www.smashingmagazine.com/wp-content/uploads/2014/06/03-testimonial-content-opt.jpg
20. 20 http://www.smashingmagazine.com/wp-content/uploads/2014/06/04-testimonial-footer-opt.jpg
21. 21 http://ianstormtaylor.com/posts/media-queries-are-a-hack/pricing.jpg
22. 22 http://www.smashingmagazine.com/wp-content/uploads/2014/06/04-testimonial-footer-opt.jpg
23. 23 http://ianstormtaylor.com/media-queries-are-a-hack/
24. 24 https://github.com/Modernizr/Modernizr/wiki/HTML5-Cross-browser-Polyfills
25. 25 http://restivejs.com
26. 26 http://speckyboy.com/2014/04/24/make-any-website-responsive/
27. 27 http://docs.restivejs.com
28. 28 https://github.com/obihill/restive.js
29. 29 http://blog.restive.io/posts/8460953/device-classes-as-breakpoints

The post Breakpoints And The Future Of Websites appeared first on Smashing Magazine.

Web design resembles a tough survival course for designers. A single wrong step can lead to disaster. As a designer, you will be designing sites for extremely picky and impatient website visitors who will scream blue murder if the website doesn’t meet their expectations. This state of affairs puts web designers under tremendous pressure as they have to deal with demanding clients and discerning target users. In such a pressure cook situation, there is every chance of designers making errors and in certain cases these errors go unidentified and end up on live websites.

Are you a web designer or developer who dreams about creating a mobile game and bringing it to the app store? We have good news: Your road to the app store might be shorter than you think! And if you can recall your experience with ActionScript and the Flash platform from days of old, then you’ll even have a shortcut.

Building a native app with Flash might sound weird at first. In this article, we will share some insights on how we built a game for iOS that is written entirely in ActionScript.

First things first. Before getting to the technical aspects, let’s talk about general considerations that every game developer has to face, as well as some design decisions we were confronted with.

Developer’s Dilemmas

Android, iOS or Both?

Making a game sounds fun — and it really is! But a bunch of important decisions need to be made that do not directly relate to the game itself. Let’s start with the decision about which platform(s) to support. Even if most game ideas are not strictly bound to one platform (for example, due to hardware requirements), focusing on a single platform³ for launch is a good approach. This will reduce the time and expense of the initial development cycle.

From a developer’s perspective, iOS-first is definitely the preferable path. Just think of the fragmentation in the Android universe: a huge range of screen sizes, processors and OS versions to deal with. iOS users are easier to serve: just a handful of devices, standardized screen proportions, a user base that updates the OS very quickly, and the certainty that the next generation of devices won’t veer out of line dramatically. Development is certainly easier if all supported devices fit on your desk.

On top of this, research as of late 2012 shows that Apple’s App Store pulls in far more revenue than Google’s Play store, although Google is catching up. Our conclusion was to go with iOS first, but to be prepared to port to Android quickly. The ease of porting the app was an important factor when the time came to choose a framework.

If you’re interested in some figures on how the market evolved while we were working on the game, check out Distimo’s “2013 Year in Review⁴” and App Annie’s “Top Trends of 2013⁵.”

Which Business Model To Choose

We hear you saying, “What business model?! Games are fun, not business!” We’re with you. If making games is not fun, one should surely stay away from it. However, building a game is also a challenging and time-consuming adventure, and some sort of financial compensation should be involved. The question of how to make money from it will bring you to four common business models. Pick the right one early on, because this decision will determine how focused your design and development process is:

• paid apps
• freemium (i.e. free app that offers in-app purchases)
• paid apps with in-app purchases
• in-app advertising

We spoke with a few people who play games on iOS, and it turns out that most prefer the paid model because it is the most transparent deal up front. Sounds tempting to a developer because the paid model doesn’t require any extra effort, like implementing in-app purchases or advertising. But we were surprised to find that the freemium model makes up the biggest share in revenue by far (92% in November 2013, according to Distimo’s report mentioned above). So, we decided to give it a try.

A huge concern for us was scaring away players or even getting bad reviews for offering in-app purchases, which some players still think are a scam — probably because some publishers went too far with them. To prevent such a hassle, we aimed for customer-friendly in-app purchases and tried to avoid critical mistakes.

• Recurring payments (such as for consumables) can generate a continual stream of income, but they also risk annoying people if implemented aggressively.
• The moment at which a player decides to spend money is very personal. Paywalls will scare away some players if set too early. On the other hand, players might lose interest in the game before reaching the paywall if it is set too late.
• In-app purchases that give paying players unbeatable advantages over non-paying players could lead to frustration. This factor is especially important in multiplayer games in which players are in direct competition.
• An unclear description on what’s included in in-app purchases forces players to think instead of buy.
• Some games get bad reviews for excessive pricing. Sounds obvious, but what’s “excessive”? Mobile games have gotten really inexpensive, and players are used to getting great games for little money. For example, $10 feels expensive for a game that one will have fun with for hours, while the same person will easily spend $8 for a movie ticket (which is only 90 minutes of fun).

We’re new to the business and we’re still learning. At the moment, attracting as many people as possible and getting positive reviews is more important than squeezing every last penny out of the game. Hence, we might optimize the pricing model in future.

How to Introduce Players to the App?

When you visit a city you’ve never been to before, having someone introduce you to the neighbourhood and the people makes you feel welcome and confident. The same goes for jumping into a new game — welcoming new players with a guided tour is common. Such tours are often presented by a character in the game. Guess why?!

As nice as a guided tour of a city is, on the second day you’ll probably want a few hours to explore the city on your own, right? This applies to players, too. They want to explore a game at their own pace. They’ll just skip a lengthy introduction. We kept the mandatory tutorial as brief as possible. The goal was to introduce the main mechanics and end it with a clear but easy-to-complete mission. However, after working on the game for quite a while, deciding which mechanics needed to be introduced was difficult because we were just too deep into it.

User testing is a helpful way to find out where players need hints. Some early testers played the game without any introduction or help. It turned out that the level of assistance they wanted was very personal. As a result of the feedback, we split the in-game help into four levels:

• New players are given a brief tutorial at the beginning of the game.
• Progress-aware hints appear only if required by the game’s state (for example, if a player misses an important action). Players who get it right from the beginning aren’t ever interrupted by these.
• User are guided in complex panels. An animated dot indicates where to tap when the player is using a panel for the first time.
• Gestures are shadowed. Swipeable elements are slightly animated to prompt the user to perform a swiping gesture.
• An in-game help menu explains the meaning of icons in the game and clarifies the game’s mechanics and UI elements.
• The splash screen (during loading) offers general hints.

Verify that your hints work as intended! One way would be to ask questions of your testers. Keep in mind that testers usually won’t say things like, “I can’t find the turbo boost,” because in most cases they won’t even realize that there is turbo boost!

Ask your questions thoughtfully. A question like “Which button activates the turbo booster?” will force the tester to think, and you’ll get vague feedback. Ask for the player’s fastest lap time instead. Based on the answer, you’ll be able to determine whether they used the turbo boost, thus sparing them from frustration and the pressure to give the correct answer.

Of course, watching testers play is even better than asking questions. But from our experience, looking over their shoulder will make most testers feel uncomfortable and will influence their behaviour. In this case, ask to capture their sessions. If you’re on site, AirPlay mirroring is great for testing. We used Apple TV to mirror on a TV. You can also use a tool like Reflector⁶, which turns your PC into an AirPlay receiver. As a last resort, find gameplay videos published by players on YouTube and Twitch.

We optimized the in-game guidance based on feedback but did not accurately verify the result. After the first version was publicly released, some players still got stuck because they didn’t get enough assistance. A reviewer in the US App Store summarized his review as, “Great but needs help.” We addressed the issue in two updates, and the majority of players seem to feel comfortable now.

Design And Graphics

Combining Interface Styles

What’s the first thing that comes to mind when you’re thinking of making a game? The user interface, perhaps! Of course, the UI will not be the reason that people consciously choose to play your game, but depending on the type of game, the UI could be critical (perhaps the panels or settings are complex). A neat UI could also help your game stand out from competitors. And, hey, UI design is your domain as a screen designer, and you can bring your full experience from the web!

When designing for small touchscreens, avoid clutter. You might not rely on gestures for basic tasks on a mobile website, except if it’s a common gesture (such as pinch to zoom). In a game native to the OS, you have the opportunity to take things one step further because you can introduce the user to the game through a guided tour.

We drew the illustration layer in our game, which primarily defines the look, in a pixelated style. Adopting a pixelated style for the UI seemed obvious at first, but we quickly realized that this was not the best choice, particularly for the more complex panels. We ended up with a clean flat design and anti-aliased type for the UI, which gives the game a contemporary and app-like look. (The combination of pixelated art and flat anti-aliased design had a few consequences for how we handled textures. We’ll cover this in the technical section below.)

Multi-Resolution Design

Is there such a thing as responsive design for games? Yes… kind of. Mobile games are displayed in full screen on all devices. If you’re targeting iOS, then you’ll be dealing with three screen proportions: iPad (4:3), iPhone (3:2) and iPhone 5+ (16:9). Sounds like paradise for a web designer or developer, right? However, this calls for some important design decisions, and keeping Android’s more fragmented universe in mind could save you much trouble if you decide to port the game later.

For games with simple interfaces, scaling is a good option. But scaling alone won’t do because screen proportions vary. In addition to taking care of the additional space (for example, by repeating the background pattern), our team had to reposition various elements based on screen size (for example, the player’s score had to persist in the upper-right corner).

PixelMogul is displayed at the same scale on all devices. iPad users have a larger viewport and, thus, benefit from a better overall view and less scrolling.

⁹

The design process focused on the iPad, but we had “passe-partout” layers in our Photoshop files, which enabled us to quickly check whether the design works on smaller iPhone screens, too. This approach required us to fit key elements on the smallest screen (480 × 320 pixels). In some cases, we used the extra room on larger screens for design enhancements, and then “compressed” the design for smaller devices.

Usability of the City Map

We mentioned earlier what it feels like to visit a new city. Losing one’s orientation is quite easy. That’s exactly how our early testers felt when they arrived on the city map, one of the main elements of the game. The map is 37 × 37 blocks and almost 4 pixels in width and height. Getting lost on it is quite easy, especially on a small screen, which provides just a peek at a tiny portion of the enormous map.

Our first solution was to enable users to pinch to zoom out from the map. But around the same time, we were confronted by another problem: Players earned way too much money as soon as they owned around a dozen buildings. We analyzed the math model and discussed the issue with a real estate professional, who explained to us that this is just the way the business works. Good to know!

¹¹

We found a simple solution to both issues. At the very beginning of the game, all buildings on the map except the initial four are covered by clouds and cannot be accessed. The player is forced to focus on the four buildings, which helps to maintain their attention. Because removing clouds and expanding the accessible buildings requires in-game money, increased earnings are rewarded to a certain extent.

Technology

Choosing The Right Framework

Picking a game engine or framework has similarities to dating. In “The Game Engine Dating Guide: How to Pick Up an Engine for Single Developers¹³,” Steffen Itterheim covers important points on how to “date” frameworks. We followed some of the key recommendations, which helped a lot. The tips are not specific to games and could be applied when you have to pick a framework of any kind.

• Choose a familiar programming language.
  Learning the basics of a programming language might not be a big deal, but it takes experience to learn all of the nitty-gritty details that lead to better code, fewer bugs, faster performance and tighter security. Use your experience whenever possible!
• Match the framework to your needs, not to the project.
  Mastering the tools you have is more important than obtaining the perfect tools. And the only way to master a tool is to use it frequently. Choose a framework that’s flexible enough to serve a wide range of projects. Low-level frameworks are usually more versatile than full-blown engines. Don’t look for sophisticated built-in features — rather, look for frameworks that can be extended with custom features.
• Documentation, maintenance, community and support
  Before you shortlist a framework, drop by the documentation. Check the change logs, repositories and forums for activity. Make sure you get support that is adequate and that fits your needs and budget.

You will probably have additional requirements. In our case, we were looking for a framework that works with both iOS and Android.

Our Choice: Starling

The Starling¹⁴ framework seemed to be the perfect fit. It’s a pure ActionScript framework that mimics the DisplayList architecture of Flash, while rendering all content directly from the GPU. That’s great news for ActionScript veterans, who get to work with a familiar API and get wonderful rendering performance as a bonus.

GPU rendering is based on Stage3D, which became part of the Flash platform in 2011. It’s way faster than the classic DisplayObject rendering but uses Adobe’s Graphics Assembly Language (AGAL), a low-level cross-platform shader language, instead of the beloved DisplayList architecture. Like most ActionScript developers, we’re really into the DisplayList concept, and that’s one way Starling came in very handy.

Because Starling takes care of all things AGAL, it enabled us to take advantage of our ActionScript experience and to work with the DisplayList architecture that we’re used to, while enjoying the advantages of GPU rendering. Even better is that Starling is built on top of Adobe Flash and AIR and runs for iOS and Android (both wrapped in a native app) and in the browser (via a Flash plugin).

Convenience comes at a price, though. ActionScript does not provide the developer with access to all device-specific features and libraries as the native SDK would (for example, battery level or GameCenter on iOS). AIR native extensions (ANE) bridge that gap. An ANE is a package containing native code and an ActionScript API. Several commercial and open-source ANEs¹⁵ are available for common tasks¹⁶, but you can always write your own¹⁷.

Improving Performance

Optimizing the performance of Flash content often feels like looking for a needle in a haystack. Isolating and identifying problems can be particularly time-consuming and frustrating. Adobe Flash Builder (an ActionScript-flavoured version of Eclipse) has a profiling tool that provides insight into the layer of your own ActionScript code, but all of the internal operations of the Flash player are hidden.

Scout¹⁸, Adobe’s new profiling tool, comes in handy here. Scout gives complete insight into every detail of your app’s inner life: frame rate, GPU and CPU memory usage, a breakdown of ActionScript performance, rendering details (DisplayList and GPU), plus debugging output. All of the information is organized in a timeline, which gives a rough overview and allows you to focus on individual frames or sequences of frames.

¹⁹

In the timeline, every frame is visualized as a vertical bar. A horizontal red line marks the maximum execution time for a frame (for example, around 17 milliseconds for a frame rate of 60 frames per second). This enables you to quickly identify the most important performance issues (i.e. the highest spikes) and prioritize your efforts.

The GPU renders every frame step by step (similar to the layers in a Photoshop document). Fewer layers usually means faster rendering. Enabling Stage3D recording allows you to recreate every single frame and see how the GPU renders the frame by toggling through every step (i.e. layer) manually. Aside from performance optimization, this “replay” functionality comes in handy when you’re fine-tuning things like collision detection (“Did the bullet really hit that obstacle?”).

Scout comes with companion apps for iOS, Android and Kindle, enabling you to profile content running on devices in addition to the content on your local machine. Thibault Imbert’s article “Getting Started With Adobe Scout²¹” offers a complete introduction.

Multilingual Interface

The ability to offer apps in the native languages of users has been a major factor in the success of the global App Store. Aside from the obvious advantage of multi-language support, localization provides the infrastructure to separate content from logic.

Our team works with plain-text files, which is handy because we can simply email the files to our translators. When the translated files are returned, we just drop them in the project and register the new language in the program.

Localization is a common task, and the ActionScript API even offers a ResourceManager class that takes care of loading and parsing resources and delivering localized content. The first implementation took us less than a day, and it worked — most of the time. For some reason, the app sometimes picked a wrong locale and displayed the content in a random language. Other developers have had similar unsolved problems²² and have ended up writing their own ResourceManager.

We would have preferred to rely on the built-in class, but we couldn’t find the problem after debugging for almost three days. So, we ended up — you guessed it! — writing our own AS3-ResourceManager, available on GitHub²³.

Tabular Data

Technically speaking, our game is a complex UI that manages a simple database. Many user actions require data from the database or update that data, so we need a reliable and fast connection. ActionScript works hand in hand with local SQLite databases, which perform great if you follow some simple rules:

• Access asynchronously.
  Accessing the database synchronously might look tempting at first because it’s easier to implement (no listeners or callbacks required). But be aware that AIR runs single-threaded (workers are in development at time of writing). Thus, code will stop executing while accessing the database synchronously, and even the UI will be blocked. This is a deal-breaker for any app.
• Reuse statements.
  In AIR, SQL statements are prepared (i.e. compiled) before execution. As long as a statement’s text (i.e. the query) does not change, the compiled statement will be reused, which results in faster execution. Parameterized queries are reusable for different data sets, as shown in the sample code below:

  // Create the statement if not available
  if (addStmt == null) 
  {
  	addStmt = new SQLStatement(); 
  	addStmt.sqlConnection = conn; 
  
  	// query with parameters
  	addStmt.text = 
  		"INSERT INTO tenants (name, income)" + 
      	"VALUES (:name, :income)";
  }
       
  // set parameter values 
  addStmt.parameters[":name"]   = "Mark";
  addStmt.parameters[":income"] = "4000";
  
  addStmt.execute(); 
  

• Use transactions instead of single statements.
  Every time data is updated or added, the database file must be written to disk. This is usually the most time-intensive part of the whole operation. When you use transactions, all statements in the transaction are executed in memory before the database file is written — a major time-saver! Be sure to add a queuing system to your abstraction layer, because SQLite will throw an error if you start a new transaction while another is still executing. A simple vector or array will do fine.
• Do not omit database or column names.
  This is a minor enhancement, but explicitly specifying databases and column names minimizes runtime processing.

  // DON'T
  SELECT * FROM tenants; 
  
  // DO
  SELECT name, income FROM gameDB.tenants; 
  

• Retrieve large result sets in parts.
  When you need to present query results immediately to the user, it might be worth breaking apart large result sets and presenting the initial results while processing the rest. In the sample code below, we’re fetching the results in blocks of 10 rows at a time:

  // Create the statement if not available
  if (getTenants == null)
  {
  	getTenants = new SQLStatement(); 
  	getTenants.sqlConnection = conn; 
  	getTenants.text = "SELECT name, income FROM gameDB.tenants"; 
  }
       
  getTenants.addEventListener(SQLEvent.RESULT, buildTenants); 
  getTenants.execute(10); // returns 10 rows (or fewer)
  
  function buildTenants(event:SQLEvent):void 
  { 
     var result:SQLResult = getTenants
  
  .getResult(); 
     if (result.data != null) 
     { 
        // Loop through the result rows and process row by row
           
        if (!result.complete) 
        { 
           getTenants.next(10); // retrieve the next 10 rows 
        } 
        else 
        { 
           getTenants.removeEventListener(SQLEvent.RESULT, buildTenants); 
        } 
     } 
  } 
  

Non-Tabular Data

When developing a game, you typically have to deal with non-tabular data. When a user closes our game, we store the x and y position of the city map within the viewport, so that we can display the same clipping of the map view when they return.

In our first prototype, we stored all non-database data in text files, which were written whenever a given object was disposed or the app was deactivated. We thought this approach would provide the most flexibility. But it turned out not to be reliable enough. Sometimes when the app deactivated unexpectedly (for example, because of an incoming phone call), the task of writing the files was invoked but not successfully completed, with the result being corrupted data files.

We didn’t manage to reproduce the problem properly because it rarely occurred, and so we replaced the text files with local SharedObjects (LSO). When working with an LSO, keep in mind that it can hold only the primitive data types (such as string, array and date) and is limited to 100 KB in size. Do not store any objects (in our case, the tenants) — only store an object’s properties (for example, tenant.name and tenant.income), and recreate the object from those properties when needed.

Avoid Overhead With Texture Atlases

When dealing with GPU-based rendering, images (i.e. textures) are typically organized in texture atlases (or sprite sheets). Similar to how atlases in CSS reduce HTTP requests, atlases reduce the time used to upload images to the GPU and reduce draw calls (i.e. the number of layers the GPU has to draw in a frame).

Supporting high-resolution (i.e. Retina) screens is a piece of cake. Just load the texture atlas according to the device’s resolution. The AssetManager class, which is part of the Starling framework (represented as assets in the sample code below), offers a contentScale property that you can use for this purpose.

// Loading assets from "atlas1x/" or "atlas2x/" according to screen resolution
assets.enqueue(
   File.applicationDirectory.resolvePath(
      "assets/atlas" + assets.scaleFactor + "x/", 
   )
);

If your style of graphics is pixelated, then preparing high-resolution artwork for high-resolutions screens would not make sense, because the graphic would stay the same but at double the size (i.e. four times the surface area). It’s a waste of disk space and processing time.

To avoid overhead, we separated the pixelated textures from the UI textures, which contain anti-aliased graphics. A single set of pixelated textures is used for all resolutions but then is scaled up for high-resolution displays at runtime, while the UI textures are resolution-aware (i.e. separate textures for high-resolution devices).

By default, Starling uses bilinear filtering, which creates smooth transitions between pixels when textures are scaled. That’s perfect in most cases, but it looks blurry when applied to pixelated art. If you turn off smoothing in the Image class, you’ll end up with nearest-neighbor scaling for all images.

mSmoothing = TextureSmoothing.NONE;

Conclusion

PixelMogul is the first game that we created entirely in house. Adobe AIR and Starling made it possible for us to carry over our experience with ActionScript and the Flash platform and to focus on development. The fast-growing and active Starling community was a big plus, too. We would definitively go the same route for another project of comparable scope.

What do you think? We look forward to hearing your opinions!

Further Resources

• PixelMogul²⁴, iTunes App Store
• Starling Wiki²⁵
  This manual is the perfect starting point.
• Gamua²⁶
  This HTML5 framework in the making uses the same API as Starling.
• TexturePacker²⁷
  This is a versatile tool to create texture atlases. It can even be used to create CSS sprite sheets for the web, as explained in “Creating CSS Sprites With TexturePacker²⁸.”

(al, il, ml)

Footnotes

1. 1 http://www.smashingmagazine.com/wp-content/uploads/2014/06/PixelMogul-iPad-opt.jpg
2. 2 http://www.smashingmagazine.com/wp-content/uploads/2014/06/PixelMogul-iPad-opt.jpg
3. 3 http://www.everyinteraction.com/develop-ios-or-android-first/
4. 4 http://www.distimo.com/blog/2013_12_publication-2013-year-in-review/
5. 5 http://blog.appannie.com/app-annie-index-retrospective-2013/
6. 6 http://www.airsquirrels.com/reflector/
7. 7 http://www.smashingmagazine.com/wp-content/uploads/2014/06/help-menu-large-opt.jpg
8. 8 http://www.smashingmagazine.com/wp-content/uploads/2014/06/help-menu-large-opt.jpg
9. 9 http://www.smashingmagazine.com/wp-content/uploads/2014/06/multiresolution-large-opt.jpg
10. 10 http://www.smashingmagazine.com/wp-content/uploads/2014/06/multiresolution-large-opt.jpg
11. 11 http://www.smashingmagazine.com/wp-content/uploads/2014/06/map-unlock-large-opt.jpg
12. 12 http://www.smashingmagazine.com/wp-content/uploads/2014/06/map-unlock-large-opt.jpg
13. 13 http://www.learn-cocos2d.com/2012/05/the-game-engine-dating-guide-how-to-find-the-right-engine-for-your-game/
14. 14 http://gamua.com/starling/
15. 15 http://www.adobe.com/devnet/air/native-extensions-for-air.html
16. 16 http://distriqt.com/native-extensions
17. 17 http://www.adobe.com/devnet/air/articles/building-ane-ios-android-pt1.html
18. 18 http://gaming.adobe.com/technologies/scout/
19. 19 http://www.smashingmagazine.com/wp-content/uploads/2014/06/Adobe-Scout-large-opt.png
20. 20 http://www.smashingmagazine.com/wp-content/uploads/2014/06/Adobe-Scout-large-opt.png
21. 21 http://www.adobe.com/devnet/scout/articles/adobe-scout-getting-started.html
22. 22 https://forums.adobe.com/thread/1165882
23. 23 https://github.com/rekomat/AS3-LocaleManager
24. 24 https://itunes.apple.com/app/id711358248
25. 25 http://wiki.starling-framework.org
26. 26 http://gamua.com/blog/2013/05/a-bird-for-the-modern-web/
27. 27 http://www.codeandweb.com/texturepacker
28. 28 http://www.codeandweb.com/blog/2011/07/28/creating-css-sprites-with-texturepacker

The post Case Study: PixelMogul, A Simulation Game For iOS appeared first on Smashing Magazine.

Logo design is an art the average designer does not need to perform too often. Yet, every once in a while, even the designer around the corner will be asked to create one. Chances are, this will be giving him/her some sort of a hard time. Inspiration will be needed. In the following article we will deliver just that. But we will go further, and not only inspire, but also show you how logos evolve – from ideas to first sketches to production-ready. We hope you enjoy our little collection…

I’m dedicated to weird, so when a client complained the images I was using on business articles “looked like boring stock images” I decided that only those images that used metaphor and allegory would be used for his website. The weird and wonderful appeared in a simple Google Image search and my mission to find “not boring” stock images for my client was orgasmically realized! Some that I found are just too weird to ever be used on anything, which makes me all the more determined to find uses for them!

Textures are everywhere — the concrete of a sidewalk, the fabric on your chair, even the glass (or plastic) surface of the screen you’re staring at right now. It’s natural that textures appeal to us because we see and feel them every day. And it’s no surprise why textures have become such an important element in design — so important, in fact, that I want to share with you the tricks and tools to create your own textures using Photoshop.

Photoshop isn’t just for retouching images or manipulating photos. It can be used for so much more, such as creating your own textures — as long as you know where to look. In this article, I will present a foundation of techniques to help you build custom textures. I’ll go over three Photoshop features that I rely on to do most of my texturing — filters, layer styles and brushes. Before we jump in, I want to demonstrate the importance of textures. Consider the image below:

In the image above, we see a scene with no textures. (OK, there is one texture, flat gray. Without at least one texture, the image would not exist.) The second image (right) shows a scene fully textured (the wood on the frame, the dusty table top, the fabric on the chair, etc.). In fact, this entire image was created in Photoshop (without the use of external images), using many of the techniques outlined in this article. Note that this article explores how to create textures, but if you’re interested in learning more about using texture as an element in design, some additional reading is included at the end of this article.

Texturing With Filters

Filters are still viewed by many as cheap gimmicks that have no real applicable function in Photoshop. (I know, I used to be on that side of the fence.) On the contrary, Photoshop filters are extremely powerful effects that, when used properly, can produce some amazing results. If filters are not a part of your normal Photoshop workflow, I encourage you to take another look at these underappreciated effects and use the tips below to get started.

Apply a Filter to a Filter

No one ever said that you can apply only one filter. Instead, try adding a second or third or more. Experiment with multiple filters and see how they interact with each other to create new effects. The Filter Gallery panel (Filter ? Filter Gallery) even has a filter stack where you can preview how multiple filters work together. The image below demonstrates how the Craquelure filter becomes much more interesting simply by applying it to the Reticulation filter via the Filter Gallery.

Let’s take another look at how some filters work together to create custom textures. The image below shows a basic example of this.

⁵

The image below depicts the steps necessary to recreate this texture. The texture begins with a blank canvas (left). Adding the Noise filter (Filter ? Noise ? Add Noise) (middle) introduces randomness to the scene and sets up a good foundation for the next filter. Because filters work by manipulating the pixels on a layer, the order in which you apply filters is important. So, by applying the Emboss filter (Filter ? Stylize ? Emboss) on top of the Noise filter, a new texture is created (right).

⁷

Furthermore, some filters just produce better results when applied more than once. Consider the image below of the circled grid. Applying the Spherize filter (Filter ? Distort ? Spherize) produces only a mild result (middle). However, applying it a second time creates a more believable sphere (right).

⁹

Tip: Convert a layer to a Smart Object before applying a filter to enable Smart Filters. Smart Filters are non-destructive and can be edited on the fly.

Experiment with different combinations of filters to see how they interact with each other. Soon, you’ll be able to predict how a filter might work with another filter to create a particular effect. Lets move on to the next tip.

Some Filters Naturally Tile

Tiling textures, while desirable, often takes a lot of time and effort — why not let Photoshop do most of the work for you? Some filters (such as Clouds and Noise) will naturally tile when the document is sized in powers of 2 (for example, 256 × 256, 512 × 512, even 512 × 1024). If you start with one of these textures as a base and build on top of it, you’ll find that you can quickly create some complex textures that tile with little or no additional effort. The image below shows an example of a texture that was created by using the Clouds filter as a starting point.

¹¹

As stated, this texture starts with the Clouds filter (Filter ? Render ? Clouds) applied to a document that’s sized to 1024 × 1024 pixels. Similar to Noise, the Clouds filter provides some randomness that works nicely with other filters.

¹³

At this point, we are free to adjust the dimensions of the image without harming its ability to tile. Therefore, by adjusting the size via Image ? Image Size, we can squish the texture while keeping it tileable (left). Now, if we add the Posterize effect (Image ? Adjustment ? Posterize), we can break up the texture into a number of gray shades with more defined edges (middle). The Find Edges filter (Filter ? Stylize ? Find Edges) will isolate just those edges, producing the start of a wood grain pattern (right).

¹⁵

To learn the entire process of how this texture was created, check out my “Custom Wood Texture in Adobe Photoshop¹⁷” tutorial.

Texturing With Layer Styles

Layer styles are another way to introduce texture into a scene. They offer additional options to embellish the contents of a layer. Experimenting with each setting in the Layer Styles panel in order to learn how they work is always a good practice. Below are some tricks I use when working with layer styles.

Blending Modes

When building textures in Photoshop, blending modes do exactly what they say: blend. Multiple layers of textures can seamlessly blend into a single, complex texture, as seen below:

¹⁸

Tip: Working with grayscale textures when using blending modes makes blending much easier to control (color can always be added later).

When you’re trying to build complex textures, knocking it out in one attempt can be difficult. Instead, try to break down a complex texture into a set of simpler sub-textures. Consider the texture of the tabletop in the four images below. Each image represents a simple texture that was blended together with the others to create a more complex final texture.

²⁰

Advanced Blending and “Blend If” Options

Using layer styles might be an obvious choice, but many people often ignore the “Advanced Blending” section in the default Layer Styles panel. Hidden in plain sight are some of the more powerful blending options. Here, you can decide how a layer mask will affect a style: Will it hide a layer style or just confine it to the visible portion of the layer? Towards the bottom of the menu are the “Blend If” sliders. These sliders can easily produce complex blending effects.

²²

Take the image below. The glossy texture on the paint was created with minimal effort using the “Blend If” sliders.

²⁴

The “Blend If” sliders control how a layer is blended into the layers beneath it, as illustrated in the images below. The initial layer of paint (left) appears too flat but has just enough variation to allow the “Blend If” sliders to work. Next, broad areas of white are painted onto a new layer (right) to define where the blending will take place. Adjusting the “Blend If” sliders of the white layer will produce that glossy effect in the image above.

²⁶

Tip: When using the “Blend If” sliders, hold Option or Alt while adjusting the sliders to separate them, making for a smoother blend.

²⁸

To learn more about how this image was created, check out my “Create a Paint Brush in Photoshop²⁹” tutorial.

Duplicate Layer Styles

Sometimes a layer will benefit from having two of the same layer styles with different settings. In past versions of Photoshop, accomplishing this without using destructive techniques was difficult. With the introduction of Smart Objects in CS2 — and now with the ability to add layer styles to layer groups in CS6 — Photoshop makes it easy to use and reuse multiple layer styles on the same layer. This technique was used to create the liquid and the glass bottle in the scene below.

³⁰

Examining just the liquid from the scene, it starts with a generic shape on its own layer (left). The Inner Shadow and Gradient Overlay layer styles were assigned to the layer (middle). The layer was converted to a Smart Object, which allows you to edit the layer styles in future. Next, the same two layer styles (Inner Shadow and Gradient Overlay) were reapplied to the Smart Object (right) using different settings to achieve a more complex effect.

³²

Examining the image above, you can see how creative we can get with layer styles. For example, in the middle image, the Gradient Overlay layer style was applied as a large, soft gradient that acts almost as a vignette around the top and bottom of the shape. In the last panel, the Gradient Overlay was treated much differently. It’s applied as a small, tight gradient that becomes the traditional bulb shape on the bottom of a wine bottle.

To learn more about how this was created, check out my “Create a Wine Bottle and Glass With Smart Objects³⁴” tutorial.

Texturing With Brushes

Using brushes is a great way to apply textures manually. If you’re into digital painting, then you probably know of several techniques using the Brush tool. However, being talented at digital painting is not required to effectively use the Brush tool. The following tips will reveal some more advanced methods of using this tool.

Learn the Brushes Panel

This might sound pretty basic, but many people only stick to the “Hardness” and “Size” settings. Adjusting the settings in the Brushes panel (Window ? Brush) can quickly extend the use of any brush. It gives you the options to fine-tune the behavior of a brush, making it more random and, thus, more natural. This is how I created some of the elements in the image below (such as the pencil’s highlights).

³⁵

To create the realistic highlights, I adjusted the “Shape Dynamics” and the “Scattering” settings in the Brushes panel (left). By changing the settings and size, I was able to produce a number of brush strokes that look more fragmented and more natural (right). Each brush stroke represents a different highlight that went into the pencil.

³⁷

Tip: Another great feature of the Brushes panel is that it allows you to test the brush while editing it, which makes quick work of setting up the right brush for the job.

To learn more about how this scene was created, check out my “Create a Realistic Pencil Illustration in Adobe Photoshop³⁹” tutorial.

Consider Custom Brush Shapes

Sometimes, just tweaking the settings of an existing brush isn’t enough. Creating a new brush shape (via Edit ? Define Brush Preset) opens up more possibilities for achieving natural-looking textures. Brush shapes don’t have to be complex to be effective — I typically work with simple shapes and adjust the settings to fit my needs. A good example of this is the scratches that appear on the paintbrush’s wooden handle in the image below.

⁴⁰

The scratches were created by drawing a simple shape, just like the one in the image below (left). Selecting Edit ? Define Brush Preset will add the brush shape to your brushes library. Using the technique from the previous step and adjusting the “Shape Dynamics” and “Scattering” settings in the Brushes panel, we can create a brush that shows scratches (middle). The image on the right shows the brush in use.

⁴²

Use the Brush Tool to Paint With Layer Styles

This next technique allows you to literally paint with texture. It combines the Brush tool and layer styles to easily create some complex texturing effects. The trick is to set the layer’s “Fill” setting to 0% in order to hide the brush strokes and focus on the layer style. The image below demonstrates the technique. In this case, I used the technique to paint dents onto the metal frame.

⁴⁴

The technique works best when you use a brush shape that already has some variation. This could be a custom brush or one of Photoshop’s several preset brushes, such as the “Charcoal 59 px” brush seen in the image below.

⁴⁶

Following one of the previous techniques, I’ve used the Brushes panel to adjust the “Shape Dynamics” and “Scattering” settings to produce more variation in the brush’s actual stroke, as seen in the image below (left). Before using the brush, just create a new layer with a Bevel and Emboss layer style, and then set the “Fill” setting to 0% (which will hide the stroke color but keep the layer style visible). Now, when painting on this layer, you can literally paint with texture (right).

⁴⁸

To learn more about how the metal sign was created, check out my “Create a Retro Sign from Scratch Using Advanced Techniques in Photoshop⁵⁰” tutorial.

Texturing With Images

While these textures technically weren’t created from scratch, I thought this was important enough to address. Using textures from existing photos or scans can be a quick and effective way to work. However, the most common pitfalls are using the textures in the wrong perspective, using them with incorrect lighting or making them appear flat. Fortunately, these are easy to avoid and some great articles address this.

Conclusion

As we have seen, creating high-quality textures for art or design doesn’t require the talent of an artisan painter. All it takes is a little understanding of Photoshop and knowledge of the tools and how to manipulate them to get the effect you desire. Hopefully, you’ve learned some new tricks and techniques that will help you in your next project.

Additional Reading

• “How to Create a Beautiful Mixed Media Illustration⁵¹,” Andreas Preis, Tuts+
• “Playing With the Displace Filter in Photoshop⁵²,” Abduzeedo
• “The Whys and the Hows of Texture Design⁵³,” Jon Savage and Simon Birky Hartmann, Smashing Magazine
• “Using Texture to Get the Most Out of Design⁵⁴,” Abduzeedo

(al, ml)

Footnotes

1. 1 http://www.smashingmagazine.com/wp-content/uploads/2014/06/01-texture-comparison-opt.jpg
2. 2 http://www.smashingmagazine.com/wp-content/uploads/2014/06/01-texture-comparison-opt.jpg
3. 3 http://www.smashingmagazine.com/wp-content/uploads/2014/06/02-filter-gallery-panel-opt.jpg
4. 4 http://www.smashingmagazine.com/wp-content/uploads/2014/06/02-filter-gallery-panel-opt.jpg
5. 5 http://www.smashingmagazine.com/wp-content/uploads/2014/06/03-coarse-texture-opt.jpg
6. 6 http://www.smashingmagazine.com/wp-content/uploads/2014/06/03-coarse-texture-opt.jpg
7. 7 http://www.smashingmagazine.com/wp-content/uploads/2014/06/04-three-steps-opt.jpg
8. 8 http://www.smashingmagazine.com/wp-content/uploads/2014/06/04-three-steps-opt.jpg
9. 9 http://www.smashingmagazine.com/wp-content/uploads/2014/06/05-filters-opt.jpg
10. 10 http://www.smashingmagazine.com/wp-content/uploads/2014/06/05-filters-opt.jpg
11. 11 http://www.smashingmagazine.com/wp-content/uploads/2014/06/06-wood-texture-opt.jpg
12. 12 http://www.smashingmagazine.com/wp-content/uploads/2014/06/06-wood-texture-opt.jpg
13. 13 http://www.smashingmagazine.com/wp-content/uploads/2014/06/07-clouds-filter-opt.jpg
14. 14 http://www.smashingmagazine.com/wp-content/uploads/2014/06/07-clouds-filter-opt.jpg
15. 15 http://www.smashingmagazine.com/wp-content/uploads/2014/06/08-streched-clouds-filter-opt.jpg
16. 16 http://www.smashingmagazine.com/wp-content/uploads/2014/06/08-streched-clouds-filter-opt.jpg
17. 17 http://www.tutorial9.net/tutorials/photoshop-tutorials/custom-wood-texture-in-adobe-photoshop/
18. 18 http://www.smashingmagazine.com/wp-content/uploads/2014/06/09-blending-opt.jpg
19. 19 http://www.smashingmagazine.com/wp-content/uploads/2014/06/09-blending-opt.jpg
20. 20 http://www.smashingmagazine.com/wp-content/uploads/2014/06/10-blending-opt.jpg
21. 21 http://www.smashingmagazine.com/wp-content/uploads/2014/06/10-blending-opt.jpg
22. 22 http://www.smashingmagazine.com/wp-content/uploads/2014/06/11-blending-options-opt.jpg
23. 23 http://www.smashingmagazine.com/wp-content/uploads/2014/06/11-blending-options-opt.jpg
24. 24 http://www.smashingmagazine.com/wp-content/uploads/2014/06/12-paintbrush-opt.jpg
25. 25 http://www.smashingmagazine.com/wp-content/uploads/2014/06/12-paintbrush-opt.jpg
26. 26 http://www.smashingmagazine.com/wp-content/uploads/2014/06/13-glossy-paintbrush-opt.jpg
27. 27 http://www.smashingmagazine.com/wp-content/uploads/2014/06/13-glossy-paintbrush-opt.jpg
28. 28 http://www.smashingmagazine.com/wp-content/uploads/2014/06/14-blend-sliders-opt.jpg
29. 29 http://design.tutsplus.com/tutorials/paintbrush-photoshop–psd-12182
30. 30 http://www.smashingmagazine.com/wp-content/uploads/2014/06/15-wine-opt.jpg
31. 31 http://www.smashingmagazine.com/wp-content/uploads/2014/06/15-wine-opt.jpg
32. 32 http://www.smashingmagazine.com/wp-content/uploads/2014/06/16-wine-opt.jpg
33. 33 http://www.smashingmagazine.com/wp-content/uploads/2014/06/16-wine-opt.jpg
34. 34 http://design.tutsplus.com/tutorials/create-a-wine-bottle-and-glass-with-smart-objects–psd-13329
35. 35 http://www.smashingmagazine.com/wp-content/uploads/2014/06/17-pencil-paper-opt.jpg
36. 36 http://www.smashingmagazine.com/wp-content/uploads/2014/06/17-pencil-paper-opt.jpg
37. 37 http://www.smashingmagazine.com/wp-content/uploads/2014/06/18-brush-panel-opt.jpg
38. 38 http://www.smashingmagazine.com/wp-content/uploads/2014/06/18-brush-panel-opt.jpg
39. 39 http://www.tutorial9.net/tutorials/photoshop-tutorials/create-a-realistic-pencil-illustration-in-adobe-photoshop/
40. 40 http://www.smashingmagazine.com/wp-content/uploads/2014/06/19-paintbrush-opt.jpg
41. 41 http://www.smashingmagazine.com/wp-content/uploads/2014/06/19-paintbrush-opt.jpg
42. 42 http://www.smashingmagazine.com/wp-content/uploads/2014/06/20-custom-brush-shape-opt.jpg
43. 43 http://www.smashingmagazine.com/wp-content/uploads/2014/06/20-custom-brush-shape-opt.jpg
44. 44 http://www.smashingmagazine.com/wp-content/uploads/2014/06/21-worn-out-sign-opt.jpg
45. 45 http://www.smashingmagazine.com/wp-content/uploads/2014/06/21-worn-out-sign-opt.jpg
46. 46 http://www.smashingmagazine.com/wp-content/uploads/2014/06/22-charcoal-preset-brush-opt.jpg
47. 47 http://www.smashingmagazine.com/wp-content/uploads/2014/06/22-charcoal-preset-brush-opt.jpg
48. 48 http://www.smashingmagazine.com/wp-content/uploads/2014/06/23-paint-with-texture-opt.jpg
49. 49 http://www.smashingmagazine.com/wp-content/uploads/2014/06/23-paint-with-texture-opt.jpg
50. 50 http://design.tutsplus.com/tutorials/retro-neon-sign–psd-23903
51. 51 http://design.tutsplus.com/tutorials/how-to-create-a-beautiful-mixed-media-illustration–psd-25250
52. 52 http://abduzeedo.com/playing-displace-filter-photoshop
53. 53 http://www.smashingmagazine.com/2011/10/03/whys-hows-textures-web-design/
54. 54 http://abduzeedo.com/using-texture-get-most-out-design

The post Techniques For Creating Custom Textures In Photoshop appeared first on Smashing Magazine.